Elasticsearch

01Գաղափարը՝ inverted index

Գրքի ցուցիչը թվարկում է բառերը և այն էջերը, որտեղ դրանք հանդիպում են։ Inverted index-ը նույնն է անում փաստաթղթերի համար․ յուրաքանչյուր term-ի համար պահում է այն պարունակող փաստաթղթերի ID-ների ցուցակը՝ գումարած դիրքերն ու հաճախականությունները։ «red running shoes» որոնելու համար Elasticsearch-ը նայում է երեք կարճ ցուցակ և հատում կամ միավորում դրանք՝ յուրաքանչյուր փաստաթուղթ կարդալու փոխարեն։ Relevance-ը լռելյայն հաշվվում է BM25-ով․ term-ն ավելի շատ է կշռում, եթե այն հազվադեպ է ամբողջ ինդեքսում և հաճախ է հանդիպում փաստաթղթում, և ավելի քիչ՝ շատ երկար դաշտերում։ Elasticsearch-ը near real-time է․ նոր փաստաթղթերը որոնելի են դառնում refresh-ից հետո, որը լռելյայն տեղի է ունենում ամեն վայրկյան։

• Index՝ փաստաթղթերի տրամաբանական հավաքածու մեկ mapping-ով, աղյուսակի նման։
• Document՝ JSON օբյեկտ, միավորը, որը ինդեքսավորում և որոնում եք։
• Term՝ analyzer-ի կողմից ստեղծված նորմալացված token, օրինակ՝ «running»-ը դառնում է «run»։

02Mapping-ներ և analyzer-ներ

Mapping-ը սահմանում է յուրաքանչյուր դաշտի տիպը։ Ամենակարևոր տարբերությունը text-ի և keyword-ի միջև է։ Text դաշտը վերլուծվում է՝ բաժանվում է token-ների, փոքրատառվում, գուցե stemming է անցնում, այնպես որ այն լավ է full-text որոնման համար, բայց ոչ դասավորման կամ ճշգրիտ ֆիլտրերի համար։ Keyword դաշտը պահվում է որպես մեկ ճշգրիտ արժեք՝ լավ ֆիլտրերի, դասավորման և ագրեգացիաների համար (brand, status, SKU)։ Հաճախ դաշտը mapping եք անում երկու ձևով՝ sub-field-ով։ Analyzer-ը pipeline է՝ character filter-ներ, tokenizer և token filter-ներ (lowercase, stop words, stemming, հոմանիշներ)։ Յուրաքանչյուր դաշտի համար ընտրեք լեզվական analyzer-ներ (english, german, russian…)։ Սահմանեք mapping-ները բացահայտ․ dynamic mapping-ը գուշակում է տիպերը և հաճախ սխալ է գուշակում։

1PUT /products
2{
3  "settings": { "number_of_shards": 1, "number_of_replicas": 1 },
4  "mappings": {
5    "dynamic": "strict",
6    "properties": {
7      "name":       { "type": "text", "analyzer": "english",
8                      "fields": { "raw": { "type": "keyword" } } },
9      "brand":      { "type": "keyword" },
10      "price":      { "type": "scaled_float", "scaling_factor": 100 },
11      "in_stock":   { "type": "boolean" },
12      "created_at": { "type": "date" }
13    }
14  }
15}

03Հարցումներ՝ query context և filter context

Որոնումն օգտագործում է Query DSL՝ JSON լեզու։ Bool query-ն համադրում է clause-ներ․ must-ը և should-ը ներդրում են relevance score-ում, filter-ը և must_not-ը միայն ներառում կամ բացառում են։ Filter-ները cache են արվում և score չեն հաշվում, այնպես որ յուրաքանչյուր այո/ոչ պայման (առկա է պահեստում, brand, գնի միջակայք) դրեք filter-ում, իսկ must-ը պահեք այն բանի համար, ինչ օգտատերը մուտքագրել է։ multi_match-ը որոնում է մի քանի դաշտում և թույլ է տալիս boost անել դրանցից մեկը, օրինակ՝ name-ը description-ից բարձր։ fuzziness: "AUTO"-ն հանդուրժում է տառասխալները։ Ագրեգացիաներն աշխատում են նույն request-ում՝ facet-ներ կառուցելու համար, օրինակ՝ քանակներ ըստ brand-ի, այնպես որ մեկ կանչը վերադարձնում է և՛ արդյունքները, և՛ sidebar-ի ֆիլտրերը։

1GET /products/_search
2{
3  "query": {
4    "bool": {
5      "must":   { "multi_match": { "query": "red runing shoes",
6                  "fields": ["name^3", "description"], "fuzziness": "AUTO" } },
7      "filter": [
8        { "term":  { "in_stock": true } },
9        { "range": { "price": { "lte": 120 } } }
10      ]
11    }
12  },
13  "aggs": { "brands": { "terms": { "field": "brand", "size": 10 } } },
14  "size": 20
15}

04Կլաստեր, shard-եր և replica-ներ

Ինդեքսը բաժանվում է primary shard-երի, որոնցից յուրաքանչյուրն ինքնուրույն Lucene ինդեքս է, և յուրաքանչյուր primary կարող է այլ node-երում replica պատճեններ ունենալ։ Shard-երն այն միջոցն են, որով Elasticsearch-ը բաշխում է տվյալները և զուգահեռացնում հարցումները․ replica-ները ապահովում են failover և լրացուցիչ ընթերցման հզորություն։ Հարցումը տարածվում է յուրաքանչյուր shard-ի մեկ պատճենի վրա, յուրաքանչյուրը վերադարձնում է իր top hit-երը, և coordinating node-ը միավորում է դրանք։ Primary shard-երի քանակը ֆիքսվում է ինդեքսի ստեղծման ժամանակ (փոխելու համար պետք է split, shrink կամ reindex), այնպես որ չափը որոշեք սպասվող տվյալներից․ Elastic-ի ուղեցույցը մոտավորապես 10–50 GB է յուրաքանչյուր shard-ի համար և ոչ ավելի, քան մոտ 200 միլիոն փաստաթուղթ։ Չափազանց շատ փոքր shard-երը հիշողություն են վատնում, իսկ մի քանի հսկայականները դանդաղ են վերականգնվում։

• Կլաստերի health green՝ բոլոր shard-երը նշանակված են․ yellow՝ replica-ներ են բացակայում․ red՝ primary է բացակայում։
• Node-երի դերեր՝ master-eligible, data (hot, warm, cold, frozen), ingest, coordinating, ml։
• Պրոդակշն կլաստերի համար օգտագործեք երեք master-eligible node՝ split որոշումներից խուսափելու համար։

05Ինդեքսավորում հավելվածից՝ անվտանգ

Ձեր հիմնական բազան մնում է ճշմարտության աղբյուրը․ Elasticsearch-ը ածանցյալ, որոնելի պատճեն է։ Ինդեքսավորեք փաստաթղթերը batch-երով _bulk API-ով, ոչ թե մեկ request յուրաքանչյուր փաստաթղթի համար։ Օգտագործեք ձեր բազայի ID-ն որպես Elasticsearch-ի _id, որպեսզի վերաինդեքսավորումը idempotent լինի։ Փոփոխությունների համար կամ յուրաքանչյուր գրառումից հետո հերթագրեք ինդեքսավորման job (outbox-ը կամ հերթը դա հուսալի են պահում), կամ օգտագործեք change data capture։ Միշտ կարդացեք և գրեք alias-ի միջոցով, ոչ թե իրական ինդեքսի անունով․ երբ mapping-ը պետք է փոխվի, կառուցեք նոր ինդեքս, reindex արեք դրա մեջ և alias-ը ատոմար փոխարկեք։ Անվտանգությունը լռելյայն միացված է 8.0-ից (TLS և authentication), այնպես որ օգտագործեք API key՝ միայն այն արտոնություններով, որոնք հավելվածին պետք են։

1POST /_bulk
2{ "index": { "_index": "products", "_id": "1001" } }
3{ "name": "Trail running shoe", "brand": "acme", "price": 89.9, "in_stock": true }
4{ "index": { "_index": "products", "_id": "1002" } }
5{ "name": "Road running shoe", "brand": "acme", "price": 99.0, "in_stock": false }
6 
7POST /_aliases
8{ "actions": [
9  { "remove": { "index": "products_v1", "alias": "products_live" } },
10  { "add":    { "index": "products_v2", "alias": "products_live" } }
11] }

06Լիցենզիաներ, OpenSearch և կառավարվող տարբերակներ

2021-ին Elastic-ը Apache 2.0-ից անցավ SSPL-ի և Elastic License-ի, և AWS-ը վերջին բաց տարբերակը fork արեց OpenSearch-ի, որն այժմ կառավարվում է OpenSearch Software Foundation-ի կողմից Linux Foundation-ի ներքո։ 2024-ին Elastic-ը սկզբնական կոդի համար ավելացրեց AGPLv3-ը որպես լիցենզիայի տարբերակ։ Երկու նախագծերն ունեն ընդհանուր արմատներ և Query DSL-ի մեծ մասը, բայց տարբերվել են ֆունկցիաներով, plugin-ներով և client գրադարաններով, այնպես որ ընտրեք մեկը և օգտագործեք նրա սեփական client-ը։ Հոսթինգի տարբերակներն են Elastic Cloud-ը (ներառյալ serverless առաջարկը), Amazon OpenSearch Service-ը կամ սեփական կլաստերներ VM-ների կամ Kubernetes-ի վրա (Elasticsearch-ի համար՝ ECK operator-ով)։

07Segment-ներ, refresh, flush և merge-եր

Յուրաքանչյուր shard-ի ներսում Lucene-ը տվյալները գրում է անփոփոխ segment-ներում։ Նոր փաստաթղթերը գնում են հիշողության buffer և translog (write-ahead log)։ Refresh-ը (լռելյայն ամեն 1 վայրկյան, միայն վերջերս որոնված ինդեքսներում) buffer-ը վերածում է նոր որոնելի segment-ի․ flush-ը segment-ները commit է անում սկավառակին և կրճատում translog-ը։ Քանի որ segment-ներն անփոփոխ են, update-ներն իրականում delete գումարած insert են, և ջնջված փաստաթղթերը հեռացվում են միայն այն ժամանակ, երբ ֆոնային merge-երը փոքր segment-ները միավորում են ավելի մեծերի։ Bulk բեռնումների համար refresh_interval-ը դրեք -1, replica-ները՝ 0, բեռնեք, ապա վերականգնեք երկուսն էլ․ դա կարող է բազմապատկել ինդեքսավորման արագությունը։ Խուսափեք նույն ID-ների վրա մեկական փաստաթղթի հաճախակի update-ներից, որոնք ստեղծում են բազմաթիվ փոքր segment-ներ և ջնջված փաստաթղթեր։

1PUT /products_v2/_settings
2{ "index": { "refresh_interval": "-1", "number_of_replicas": 0 } }
3 
4// ...run the bulk load, then:
5PUT /products_v2/_settings
6{ "index": { "refresh_interval": "1s", "number_of_replicas": 1 } }
7POST /products_v2/_refresh

08Vector, semantic և hybrid որոնում

Elasticsearch 8-ը և 9-ը աջակցում են dense_vector դաշտեր՝ մոտավոր kNN որոնմամբ HNSW գրաֆների միջոցով, quantization-ով (int8, int4 և BBQ՝ binary quantization)՝ հիշողությունը կրճատելու համար։ semantic_text դաշտի տիպը գնում է ավելի հեռու․ կցում եք inference endpoint, և Elasticsearch-ը ինդեքսավորման ժամանակ տեքստը բաժանում է chunk-երի և ստեղծում embedding-ներ։ Retriever-ները թույլ են տալիս ստանդարտ BM25 հարցումը համադրել kNN հարցման հետ reciprocal rank fusion-ով (RRF), որը երկու դասակարգված ցուցակները միավորում է ըստ դիրքի՝ raw score-ի փոխարեն։ Hybrid որոնումը սովորաբար գերազանցում է յուրաքանչյուր մեթոդին առանձին․ keyword-երը բռնում են ճշգրիտ SKU-ներն ու անունները, vector-ները՝ իմաստը։ Չափեք պիտակավորված հարցումների հավաքածուով՝ առաջ և հետո։

1GET /products/_search
2{
3  "retriever": { "rrf": { "retrievers": [
4    { "standard": { "query": { "match": { "name": "waterproof hiking boots" } } } },
5    { "knn": { "field": "name_vector", "k": 20, "num_candidates": 100,
6               "query_vector_builder": { "text_embedding": {
7                 "model_id": "my-embedding-endpoint", "model_text": "waterproof hiking boots" } } } }
8  ] } }
9}

09Խորը pagination և հետևողական scrolling

from + size pagination-ը ստիպում է յուրաքանչյուր shard-ին հավաքել from + size hit-եր, իսկ coordinator-ին՝ դասավորել դրանք բոլորը, այնպես որ 500-րդ էջը շատ թանկ է․ հենց այդ պատճառով լռելյայն սահմանը (index.max_result_window) 10,000 արդյունք է։ Օգտատիրոջ համար infinite scrolling-ի կամ export-ների համար օգտագործեք search_after՝ sort-ով, որն ավարտվում է եզակի tiebreaker-ով, point in time-ի (PIT) հետ համատեղ, որպեսզի տեսքը չտեղաշարժվի նոր փաստաթղթերի ժամանման ժամանակ։ Ավելի հին scroll API-ն դեռ հասանելի է, բայց այլևս խորհուրդ չի տրվում խորը pagination-ի համար։ Շատ մեծ արդյունքների հավաքածուների export-ի համար դիտարկեք զուգահեռ sliced PIT որոնումներ։

10Կլաստերի շահագործում՝ հիշողություն, tier-եր և snapshot-ներ

JVM heap-ին տվեք RAM-ի ոչ ավելի, քան մոտ կեսը և մնացեք compressed-pointer շեմից ցածր (մոտ 30 GB)․ մնացածն օգտագործվում է OS file cache-ի կողմից, որին Lucene-ը մեծապես ապավինում է։ Վերջին տարբերակները heap-ի չափը որոշում են ավտոմատ, ինչը սովորաբար ճիշտ է։ Ժամանակային տվյալների համար օգտագործեք hot, warm, cold և frozen data tier-եր ILM-ով, որպեսզի հին ինդեքսները տեղափոխվեն ավելի էժան պահոց և ի վերջո ջնջվեն։ Կանոնավոր snapshot արեք object storage-ում (S3, GCS, Azure) snapshot lifecycle management-ով․ snapshot-ները incremental են և ձեր իրական backup-ն են, քանի որ replica-ները չեն պաշտպանում ինդեքսի ջնջումից։ Upgrade արեք rolling restart-ներով մեկ major-ի ներսում և major upgrade-ներից առաջ ստուգեք deprecation API-ն։