Cơ sở dữ liệu

Đề tài: Search in Depth

 Finding exact
values

Combining
Structured Search
Filter

Finding Multiple
Exact Values

Search in depth Inverted Index Ranges

Dealing with null

values

Relevance Term Requency

Inverse document
frequency
I – Structured Search
1. Finding exact values
 Khi muốn tìm kiếm chính xác theo keywork thì ta nên dùng các filter
trong ES, và hãy dùng các filter nhiều nhất có thể bởi các filter sẽ không
phải tính relevance, tính score giữa input đầu vào và kết quả trả về. Các
kết quả filter trả về được cache dễ dàng trên server do đó performance
tìm kiếm sẽ tốt hơn nếu dùng full-text search.
 Filter quan trọng vì chúng rất nhanh. Filter không tính toán mức độ liên
quan (tránh toàn bộ giai đoạn tính điểm) và dễ dàng lưu vào bộ nhớ
cache.
 Các kết quả filter trả về được cache dễ dàng trên server do đó
performance tìm kiếm sẽ tốt hơn nếu dùng full-text search.
I – Structured Search
 Term Filter (bộ lọc thuật ngữ): là filter được sử dụng thường xuyên, nó có khả năng
xử lý numbers, Booleans, dates và text.
 Term Filter with Numbers (Bộ lọc thuật ngữ với số):
Ví dụ: giả sử có một loạt các products được index trong ES:
POST /my_store/products/_bulk
{"index": {"_id": 1}}
{"price": 10, "productID": "XHDK-A-1293-#fJ3"}
{"index": {"_id": 2}}
{"price": 20, "productID": "KDKE-B-9947-#kL5"}
{"index": {"_id": 3}}
{"price": 30, "productID": "JODL-X-1937-#pV7"}
{"index": {"_id": 4}}
{"price": 30, "productID": "QQPX-R-3956-#aD8"}
 I – Structured Search
 Tìm kiếm chính xác các products có giá price = 20 sử dụng SQL:

 Dùng filter trong ES:

 I – Structured Search
 Term Filter with Numbers (Bộ lọc thuật ngữ với số):
 Tìm kiếm sản phẩm có productID = XHDK-A-1293-#fJ3 sử dụng SQL:

 Dùng filter trong ES:

 I – Structured Search
 Kết quả không như mong muốn do productID đã bị analyze (chuyển đổi từ dạng text sang dạng
tokens of terms) bởi standard analyzer (phân tích tiêu chuẩn), ta cần phải config (đặt cấu hình)
không sử dụng analyzer cho field(trường) này.
 Thay đổi mapping type cho productID để field này không được đánh index, khi đó ta có thể dung
filter:
 I – Structured Search
 Internal Filter Operation (Sự hoạt động bên trong của bộ lọc)
 Find matching docs (Tìm tài liệu phù hợp)
 Build a bitset (Xây dựng tập hợp bit)
 Cache the bitset (Lưu vào bộ nhớ cache tập hợp các bit)

Khi thực hiện một truy vấn được lọc, bộ lọc được thực thi trước truy vấn. Tập hợp bit kết quả
được đưa cho truy vấn, sử dụng nó để đơn giản bỏ qua bất kỳ tài liệu nào đã bị bộ lọc loại trừ.
Đây là 1 trong những cách mà bộ lọc có thể cải thiện hiệu suất. Ít tài liệu hơn được đánh giá bởi
truy vấn có nghĩa là thời gian phản hồi nhanh hơn.
I – Structured Search
2. Combining Filters
 Để tìm kiếm nhiều field trên một query, có thể kết hợp nhiều filter với nhau.
 Hai ví dụ trước cho thấy một bộ lọc duy nhất đang được sử dụng. Trong thực tế,
ta có thể sẽ cần phải lọc trên nhiều giá trị hoặc trường. Ví dụ, trong SQL:

 Trong những tình huống này, ta sẽ cần bộ lọc bool. Đây là bộ lọc phức hợp chấp
nhận các bộ lọc khác làm đối số, kết hợp chúng theo nhiều kiểu kết hợp Boolean
khác nhau. Để viết câu truy vấn trên bằng DSL, cần dùng Boolean filter.
I – Structured Search
 Bool Filter: gồm 3 phần:
{
"bool": {
"must": [],
"should": [],
"must_not": [],
}
}
 must: tất cả các mệnh đề này phải phù hợp. Tương đương của AND.
 must_not: tất cả các mệnh đề này không được phù hợp. Tương đương của NOT.
 should: Ít nhất một trong các mệnh đề này phải khớp. Tương đương của OR.
I – Structured Search
 Để sao chép ví dụ SQL trước, chúng ta sẽ lấy hai bộ lọc thuật ngữ mà chúng ta đã sử dụng
trước đó và đặt chúng bên trong mệnh đề should của bộ lọc bool và thêm một mệnh đề
khác để xử lý điều kiện NOT:
I – Structured Search
 Nesting boolean filter: Mặc dù bool là một bộ lọc phức hợp và chấp nhận các bộ lọc con,
nhưng điều quan trọng là phải hiểu rằng bool chỉ là một bộ lọc. Điều này có nghĩa là ta có
thể lồng các bộ lọc bool vào bên trong các bộ lọc bool khác, cho phép bạn tạo logic
Boolean phức tạp tùy ý.
 Sử dụng truy vấn SQL:
I – Structured Search
 Có thể dịch nó thành một cặp bộ lọc tool lồng nhau:
I – Structured Search
3. Finding Multiple Exact Values
 Contain but does not equal (chứa nhưng không bằng)
 Ví dụ nếu có bộ lọc cụm từ cho {“temp”: {“tags”: “search”}}, nó sẽ khớp với cả hai tài
liệu sau:
{“tags”: [“search”]}
{“tags”: [“search”, “open_source”]}
 Cách hoạt động của bộ lọc thuật ngữ: Nó kiểm tra inverted index cho tất cả các tài liệu có
chứa một thuật ngữ và sau đó xây dựng một tập hợp các bit. Trong ví dụ dưới đây, ta có
inverted index sau:
Token DocIDs
open_source 2
search 1,2
I – Structured Search

 Khi một bộ lọc cụm từ được thực thi để tìm kiếm token, nó sẽ chuyển thẳng
đến mục nhập tương ứng trong inverted index và trích xuất các ID tài liệu
được liên kết. Như vậy, cả tài liệu 1 và 2 đều chứa token trong inverted
index. Vì thế, cả hai kết quả đều được trả về.
 Để xác định một tài liệu cụ thể chỉ chứa yêu cầu của mình, ta sẽ phải tìm
thuật ngữ trong inverted index, trích xuất các ID tài liệu, sau đó quét mọi
hàng trong inverted index, sau đó tìm kiếm các ID đó để xem một tài liệu có
bất kỳ thuật ngữ nào khác hay không. Làm như vậy sẽ cực kỳ kém hiệu quả.
Do đó thuật ngữ phải chứa chứ không bằng.
I – Structured Search
 Equals Exactly (bằng chính xác)

 Sử dụng hai tài liệu bên trên, bây giờ ta bao gồm một trường duy trì
số lượng thẻ:
{ "tags" : ["search"], "tag_count" : 1 }
{ "tags" : ["search", "open_source"], "tag_count" : 2 }
 I – Structured Search
 Khi đã lập index thông tin về số lượng, ta có thể tạo bộ lọc bool thực thi số
lượng điều khoản thích hợp:
GET /my_index/my_type/_search
{
"query": {
"filtered" : {
"filter" : {
"bool" : {
"must" : [
{ "term" : { "tags" : "search" } },
{ "term" : { "tag_count" : 1 } }
]}}}}}
I – Structured Search
4. Ranges
 Trong SQL, một phạm vi được biểu thị như sau:
SELECT document
FROM products
WHERE price BETWEEN 20 AND 40

 Trong ES, một phạm vi biểu thị như sau:

"range" : {
"price" : {
"gt" : 20,
"lt" : 40
}
}
I – Structured Search
 Bộ lọc phạm vi hỗ trợ cả phạm vi bao gồm và phạm vi riêng, thông qua sự kết hợp của các
tùy chọn sau:
 gt: > lớn hơn
 lt: < nhỏ hơn
 gte: >= lớn hơn hoặc bằng
 lte: <= nhỏ hơn hoặc bằng
 Nếu bạn muốn một phạm vi không giới hạn, cần bỏ đi một ranh giới. Ví dụ >20:
"range" : {
"price" : {
"gt" : 20
}
}
 Bộ lọc phạm vi cũng có thể hoạt động trên các trường ngày và trường chuỗi.
I – Structured Search
5. Dealing with null values
 Nếu một trường không có giá trị, nó sẽ không được lưu trữ. Hãy xem
inverted index từ phần trước:
Token DocIDs
open_source 2
search 1,2

 Ta không thể lưu trữ một trường không tồn tại trong cấu trúc dữ liệu. Inverted
index chỉ đơn giản là một danh sách các token và các tài liệu chứa chúng. Nếu một
trường không tồn tại thì trường đó không chứa bất kỳ mã thông báo nào, điều đó
có nghĩa là nó sẽ không được thể hiện trong cấu trúc dữ liệu inverted index.
 Để xử lý vấn đề này, Elasticsearch có một số công cụ để làm việc với các giá trị
rỗng hoặc bị thiếu.
I – Structured Search
 Exists filter (bộ lọc tồn tại)
 Bộ lọc này sẽ trả về các tài liệu có bất kỳ giá trị nào trong trường được chỉ định. Hãy sử dụng ví dụ gắn
thẻ và lập index một số tài liệu mẫu:
POST /my_index/posts/_bulk
{"index": {"_id": "1"}}
{"tags": ["search"]}1
{"index": {"_id": "2"}}
{"tags": ["search", "open_source"]}2
{"index": {"_id": "3"}}
{"other_field": "some data"}3
{"index": {"_id": "4"}}
{"tags": null}4
{"index": {"_id": "5"}}
{"tags": ["search", null]}5
I – Structured Search
 Kết quả của inverted index cho trường thẻ sẽ giống như sau:
Token DocIDs
open_source 2
search 1,2,5

 Trong Elasticsearch, ta sử dụng bộ lọc tồn tại:

GET /my_index/posts/_search
{
"query" : {
"filtered" : {
"filter" : {
"exists" : { "field" : "tags" }
}
}
}
}
I – Structured Search
 Truy vấn trả về ba tài liệu:
"hits": [
{ "_id": "1",
"_score": 1,0,
"_source": {"tags": ["search"]}},
{ "_id": "5",
"_score": 1,0,
"_source": {"tags": ["search", null]}},
{ "_id": "2",
"_score": 1,0,
"_source": {"tags": ["search", "open source"]}}
]
I – Structured Search
 Missing Filter (bộ lọc thiếu)
 Bộ lọc thiếu về cơ bản là nghịch đảo của tồn tại: nó trả về các tài liệu không có giá trị cho
một trường cụ thể.
 Hoán đổi bộ lọc hiện có cho một bộ lọc thiếu từ ví dụ trước:
GET /my_index/posts/_search
{
"query" : {
"filtered" : {
"filter": {
"missing" : { "field" : "tags" }
}
}
}
}
I – Structured Search
 Ta lấy lại được hai tài liệu không có giá trị thực trong trường tags — tài liệu 3 và 4:
"hits": [
{ "_id": "3",
"_score": 1,0,
"_source": {"other_field": "một số dữ liệu"}},
{ "_id": "4",
"_score": 1,0,
"_source": {"tags": null}}
]
 Nó phù hợp với loại trường. Không thể sử dụng chuỗi null_value trong trường loại ngày
 Nó khác với các giá trị bình thường mà trường có thể chứa, để tránh nhầm lẫn
 giá trị thực với giá trị null.
II – Inverted Index
 Các kết quả trong quá trình phân tích được lưu trữ ở trong inverted index -
gọi là chỉ số đảo ngược.

 Một Inverted index chứa danh sách từng từ đơn duy nhất (unique work)
xuất hiện trong bất kỳ một document nào được bao phủ bởi index, ứng với
mỗi từ đó sẽ là một danh sách các document mà từ này xuất hiện (mapping)
được lưu trữ. Vì vậy, về cơ bản, một inverted index là một ánh xạ giữa các
điều khoản và tài liệu nào chứa các điều khoản đó. Vì một inverted index
hoạt động ở cấp trường tài liệu và lưu trữ các thuật ngữ cho một trường nhất
định, nên nó không cần phải xử lý các trường khác nhau.
II – Inverted Index
Ví dụ: Giả sử rằng chúng ta có hai công thức nấu ăn với các tiêu đề sau: “The
Best Pasta Recipe with Pesto” và “Delicious Pasta Carbonara Recipe”. Bảng
sau đây cho thấy inverted index sẽ như thế nào.
II – Inverted Index
 Bước đầu tiên của truy vấn tìm kiếm là tìm tài liệu khớp với truy vấn ở vị trí
đầu tiên. Vì vậy, nếu chúng ta tìm kiếm "pasta recipe", thì ta sẽ thấy rằng cả
hai tài liệu đều chứa cả hai thuật ngữ.
II – Inverted Index
 Nếu chúng ta tìm kiếm theo thuật ngữ “delicious recipe” thì kết quả sẽ như
sau:
II – Inverted Index
 Tóm lại: Một bộ phân tích được áp dụng cho các trường toàn văn bản và kết
quả của quá trình phân tích này được lưu trữ trong một inverted index.
Một inverted index bao gồm tất cả các điều khoản cho một trường nhất định
trên tất cả các tài liệu trong một index.

 Vì vậy, khi thực hiện một truy vấn tìm kiếm, ta không thực sự tự tìm kiếm
các tài liệu, mà là một inverted index. Điều này rất quan trọng để hiểu bởi vì
nếu không, có thể bị bối rối về lý do tại sao một số truy vấn không phù hợp
với những gì mong đợi.
III – Relevance
 Là thuật toán toán mà chúng ta sử dụng để tính toán mức độ tương tự nội
dung của một trường văn bản với một chuỗi truy vấn toàn văn bản (full –
text) .
 The relevance score của mỗi tài liệu được biểu diễn bởi một số thực dấu
phẩy động dương được gọi là the_score. The_score càng cao thì tại liệu
càng liên quan.
 The_score càng cao thì tại liệu càng liên quan (relevance).
 Một mệnh đề truy vấn tạo ra một the_score cho mỗi tài liệu. Do đó cách
tính score phụ thuộc vào loại mệnh đề truy vấn.
III – Relevance

 Thuật toán tương tự tiêu chuẩn được sử dụng trong Elasticsearch:

 Term frequency (TF)

 Inverse document frequency (IDF)
III – Relevance
 Term frequency
III – Relevance

 search với từ khoá "quick

{ "title": "The quick brown fox jumps over the quick dog" }
{ "title": "The quick brown fox" }
TF được tính theo công thức sau:
tf(t, d) = √frequency

 term frequency (tf) của t trong document d được tính bằng căn bậc hai của
số lần t xuất hiện trong d.
III – Relevance

Từ khoá ít xuất hiện hơn

(“lẩu") sẽ cho relevance cao
hơn là từ khoá xuất hiện
nhiều hơn (“lẩu hải sản tôm
hùm") trên toàn bộ index
Mặc dù vậy, kết quả trên
không có nghĩa là từ khoá ""
tốt hơn từ khoá “lẩu“.
III – Relevance
 Inverse document frequency (IDF)
 Inverse document frequency (idf) của t là logarit cơ số e (logarit tự
nhiên) của thương giữa tổng số documents trong index và số documents
xuất hiện t (giá trị công thêm 1 ở đây để tránh xảy ra lỗi Division by
zero).
 IDF được đánh giá theo công thức sau:
idf(t) = 1 + log (numDocs / (docFreq + 1))
 III – Relevance
 Công thức: norm(d) = 1 / √numTerms
 Giải thích: field-length norm (norm) là nghịch đảo của căn bậc hai số lượng term trong
field. (có thể hiểu là số lượng chữ của field đó)
 Các truy vấn đơn có thể kết hợp TF/IDF score với các yếu tố khác như sự xấp xỉ của
term trong phrase queries (truy vấn cụm từ ) , hoặc sự giống nhau về term trong truy
vấn mờ
 Relevance(độ liên quan) không chỉ là tìm kiếm toàn văn (full-text search) mà nó hoàn
toàn có thể áp dụng cho mệnh đề có hoặc không, càng nhiều mệnh đề chính xác
the_score càng cao .
 Khi nhiều mệnh đề truy vấn được kết hợp bằng cách sử dụng phép truy vấn ghép như
là bool query, the_score cho mỗi mệnh đề truy vấn được kết hợp được tính toán là
over_all_score ( tổng điểm ) cho tài liệu.
III – Relevance

 _score cuối cùng sẽ là tích của TF, IDF và Field-length norm giá trị trên:
IDF score * TF score * fieldNorms
hay
log(numDocs / (docFreq + 1)) * √frequency * (1 / √numTerms)
Cảm ơn thầy và các bạn đã chú ý lắng nghe!!!
 Thành viên:
 Vũ Thị Thùy Dung – MSV 19000403
 Công Anh Dũng – MSV 19000405
 Trần Tuấn Huy – MSV 19000436
 Hoàng Đức Trung – MSV 19000497
 Trần Minh Vũ – MSV 19000501