Ապրանքների որոնում

01Երեք մակարդակ՝ LIKE, full-text, որոնման շարժիչ

Առաջին մակարդակը տվյալների բազայի LIKE query-ն է՝ WHERE name LIKE '%dog food%'։ Այն հեշտ է, բայց սկզբի wildcard-ը չի կարող օգտագործել սովորական ինդեքս, ուստի scan է անում աղյուսակը, և ոչ մի պատկերացում չունի տառասխալների, բառերի հերթականության կամ համապատասխանության մասին։ Երկրորդ մակարդակը տվյալների բազայի full-text որոնումն է՝ MySQL FULLTEXT ինդեքսներ կամ PostgreSQL tsvector՝ GIN ինդեքսներով։ Դրանք տեքստը բաժանում են բառերի, կատարում stemming («running»-ը համընկնում է «run»-ի հետ) և դասավորում ըստ համապատասխանության․ բավական լավ է բլոգների և փոքր կատալոգների համար՝ առանց լրացուցիչ ծառայության։ PostgreSQL-ի pg_trgm ընդլայնումն ավելացնում է fuzzy համընկնում։ Երրորդ մակարդակը առանձին որոնման շարժիչն է, որը կառուցում է inverted index՝ օպտիմալացված ակնթարթային, տառասխալներ հանդուրժող, facet-ներով որոնման համար՝ կարգավորելի ranking-ով։ Մակարդակով բարձրացեք միայն այն ժամանակ, երբ նախորդն այլևս չի սպասարկում օգտատերերին։

1-- PostgreSQL full-text search with ranking
2ALTER TABLE products ADD COLUMN search tsvector
3  GENERATED ALWAYS AS (
4    setweight(to_tsvector('english', coalesce(name, '')), 'A') ||
5    setweight(to_tsvector('english', coalesce(description, '')), 'B')
6  ) STORED;
7 
8CREATE INDEX products_search_idx ON products USING GIN (search);
9 
10SELECT id, name, ts_rank(search, query) AS rank
11FROM products, websearch_to_tsquery('english', 'dry dog food') AS query
12WHERE search @@ query
13ORDER BY rank DESC
14LIMIT 20;

02Ինչպես է աշխատում որոնման շարժիչը

Որոնման շարժիչը պահում է inverted index․ գրքի վերջում գտնվող ցուցիչի պես այն յուրաքանչյուր բառ կապում է այն փաստաթղթերի ցուցակի հետ, որոնք պարունակում են այն։ Երբ ապրանք եք ինդեքսավորում, շարժիչը տեքստը tokenise է անում (բաժանում բառերի), normalise անում (փոքրատառ, հեռացնում շեշտանշանները) և կարող է կիրառել stemming կամ լեզվական կանոններ։ Query-ի պահին այն որոնում է յուրաքանչյուր բառը, թույլ է տալիս փոքր քանակությամբ տառասխալներ՝ սովորաբար մեկը կարճ բառերի և երկուսը ավելի երկարների համար, չափված որպես edit distance, համընկեցնում է prefix-ները, որպեսզի արդյունքները հայտնվեն մուտքագրելու ընթացքում, և դասավորում է արդյունքները։ Ranking-ը սովորաբար համակցում է տեքստային համապատասխանությունը (քանի բառ է համընկնում, որքան մոտ, որ դաշտում) ձեր կարգավորած բիզնես ազդանշանների հետ, օրինակ՝ հայտնիություն, մնացորդ կամ մարժա։ Facet-ները քանակներ են ըստ ֆիլտրի արժեքի («Բրենդ՝ 12, Չափս՝ 5»), որոնք հաշվարկվում են արդյունքների հետ միասին։

03Շարժիչի ընտրություն

Algolia-ն hosted ծառայություն է՝ հիանալի արագությամբ, տառասխալների հանդուրժմամբ, merchandising գործիքներով և analytics-ով․ վճարում եք ըստ որոնման հարցումների և գրառումների, ինչը կարող է թանկանալ։ Meilisearch-ը և Typesense-ը open-source շարժիչներ են, որոնք կարող եք self-host անել փոքր սերվերի վրա կամ օգտագործել որպես cloud ծառայություններ․ երկուսն էլ արագ են, տառասխալներ հանդուրժող և պարզ կարգավորվող, իդեալական խանութների մեծ մասի համար։ Elasticsearch-ը և OpenSearch-ը հզոր ընդհանուր նշանակության շարժիչներ են հսկա կատալոգների, բարդ query-ների, ագրեգացիաների և log-երի համար, բայց պահանջում են ավելի շատ հիշողություն և շահագործման փորձ։ Laravel-ում Scout-ը տալիս է մեկ API Algolia-ի, Meilisearch-ի, Typesense-ի և database driver-ի վրա, այնպես որ կարող եք սկսել պարզից և հետագայում փոխել շարժիչը։

• Փոքր կատալոգ, ևս մեկ ծառայության բյուջե չկա՝ տվյալների բազայի full-text։
• Խանութների մեծ մասը՝ Meilisearch կամ Typesense, self-hosted կամ cloud։
• Merchandising և analytics առանց ops-ի՝ Algolia։
• Հսկա տվյալներ, բարդ ագրեգացիաներ կամ արդեն գոյություն ունեցող cluster՝ Elasticsearch / OpenSearch։

04Ինդեքսի նախագծում

Որոնման ինդեքսը ձեր տվյալների բազայի պատճենը չէ․ այն հարթեցված փաստաթուղթ է՝ նախագծված մեկ էկրանի համար։ Խանութի համար որոշեք, թե ինչ է արդյունքը՝ սովորաբար ապրանք, որի մեջ միաձուլված են տարբերակների ատրիբուտները (բոլոր գույներն ու չափսերը), որպեսզի ֆիլտրերն աշխատեն, և ամենացածր հասանելի գինը՝ դասավորման համար։ Ներառեք միայն այն, ինչ պետք է որոնմանը՝ անուն, բրենդ, կատեգորիայի ճանապարհ, ատրիբուտներ, բանալի բառեր, գին, մնացորդի դրոշակ, հայտնիություն և նկարի URL։ Հայտարարեք, թե որ դաշտերն են որոնելի (առաջնահերթության կարգով), որոնք՝ ֆիլտրելի (facet-ներ) և որոնք՝ դասավորելի։ Օգտագործեք հոմանիշներ այն բառերի համար, որոնք հաճախորդները տարբեր կերպ են օգտագործում («kitten» և «cat», «nail polish» և «lacquer»), և stop word-եր՝ աղմուկի համար։ Կատեգորիաների, բրենդների և հոդվածների առանձին ինդեքսները թույլ են տալիս առաջարկների հարուստ dropdown։

1// Laravel Scout: what goes into the search document
2class Product extends Model
3{
4    use \Laravel\Scout\Searchable;
5    public function toSearchableArray(): array
6    {
7        return [
8            'id'         => $this->id,
9            'name'       => $this->name,
10            'brand'      => $this->brand?->name,
11            'categories' => $this->categories->pluck('name')->all(),
12            'colours'    => $this->variants->pluck('colour')->filter()->unique()->values()->all(),
13            'price_min'  => $this->variants->min('price'),       // integer minor units
14            'in_stock'   => $this->variants->contains(fn ($v) => $v->available > 0),
15            'popularity' => $this->sales_last_30_days,
16        ];
17    }
18 
19    public function shouldBeSearchable(): bool { return $this->is_active; }
20}

05Ինդեքսի սինքրոնիզացիա

Ինդեքսը ձեր տվյալների երկրորդ պատճենն է, ուստի այն կարող է հնանալ։ Թարմացրեք այն, երբ տվյալները փոխվում են․ Scout-ը դա անում է ավտոմատ մոդելի save-ի և delete-ի ժամանակ, բայց աշխատանքն ուղարկեք queue, որպեսզի ապրանքը պահելը երբեք չսպասի որոնման ծառայությանը։ Զգույշ եղեք այն փոփոխությունների հետ, որոնք շրջանցում են մոդելի event-ները՝ զանգվածային SQL update-ներ, ERP import-ներ, մնացորդի փոփոխություններ այլ աղյուսակում կամ բրենդի վերանվանում, որն ազդում է հազարավոր ապրանքների վրա, և ազդված գրառումների համար բացահայտ գործարկեք reindex։ Պարբերաբար պլանավորեք ամբողջական reindex, իդեալում՝ նոր ինդեքսի մեջ, ապա փոխարինեք այն alias-ով, որպեսզի օգտատերերը երբեք կիսակառույց ինդեքս չտեսնեն։ Մնացորդն ու գինը հաճախ են փոխվում․ մտածեք միայն այդ դաշտերը batch-երով թարմացնելու մասին՝ ամբողջ փաստաթղթերի փոխարեն։

• Ինդեքսի թարմացումները queue արեք․ զանգվածային import-ների համար batch արեք դրանք։
• Վերակառուցեք նոր ինդեքսի մեջ և ատոմար փոխարինեք։
• Alert ուղարկեք, երբ ինդեքսավորված փաստաթղթերի քանակը շատ է տարբերվում տվյալների բազայից։

06Ranking, analytics և production-ի խորհուրդներ

Լավ ranking-ը կարգավորվում է, ոչ թե գուշակվում։ Սկսեք շարժիչի default-ներից, որոնելի դաշտերը դրեք ըստ կարգի (անունը՝ նկարագրությունից առաջ) և ավելացրեք custom ranking ազդանշան, օրինակ՝ հայտնիություն կամ վաճառքներ։ Պահեստում չեղած ապրանքները իջեցրեք ներքև՝ թաքցնելու փոխարեն, եթե բիզնեսն այլ բան չի նախընտրում։ Log արեք որոնումները՝ query-ն, արդյունքների քանակը և click-երը։ Զրո արդյունքով որոնումների ցուցակը ցույց է տալիս բացակայող հոմանիշներ, ապրանքներ և ուղղագրական խնդիրներ, իսկ հայտնի որոնումները կարող են սնել առաջարկները։ Պաշտպանեք որոնման endpoint-ը rate limiting-ով և երբեք մի բացահայտեք admin API key-երը բրաուզերին․ օգտագործեք search-only key-եր, իդեալում՝ սահմանափակ scope-ով կամ ժամկետով։ Client-ում search-as-you-type-ը debounce արեք մոտ 150–300 ms-ով և cache արեք հայտնի query-ները։

07Relevance-ի ներքին կառուցվածքը. BM25 և ranking rule-եր

Ընդհանուր նշանակության engine-ները, ինչպիսիք են Elasticsearch-ը և OpenSearch-ը, default-ով document-ները գնահատում են BM25-ով։ Պարզ բառերով՝ document-ն ավելի բարձր score է ստանում, երբ հաճախ է պարունակում query-ի բառերը (նվազող արդյունավետությամբ, այնպես որ բառը քսան անգամ կրկնելը շատ չի օգնում), երբ բառերը հազվադեպ են ամբողջ index-ում («merino»-ն ավելի շատ է կշռում, քան «the»-ն), և երբ դաշտը կարճ է (հինգ բառանոց վերնագրում համընկնումը գերազանցում է երկար նկարագրության մեջ եղածին)։ Field boost-երը բազմապատկում են այդ score-ը։ Instant search-ի համար ստեղծված engine-ները, ինչպիսիք են Meilisearch-ը, Typesense-ը և Algolia-ն, փոխարենը օգտագործում են ranking rule-երի կամ tie-breaker-ների դասավորված ցուցակ. համընկած բառերի քանակ, typo-ներ, մոտիկություն, ատրիբուտների հերթականություն, ճշգրտություն, ապա ձեր custom ranking-ը։ Հասկանալը, թե որ մոդելն է օգտագործում ձեր engine-ը, ասում է, թե ինչ կարգավորել. boost-եր և ֆունկցիաներ BM25 engine-ներում, rule-երի հերթականություն և custom ատրիբուտներ մյուսներում։

08Zero-downtime reindexing alias-ներով և swap-երով

Index-ի կարգավորումների փոփոխությունը՝ նոր searchable ատրիբուտներ, այլ tokeniser, նոր լեզու, հաճախ պահանջում է ամբողջ index-ի վերակառուցում։ Երբեք դա տեղում մի արեք, այլապես օգտատերերը րոպեներով կտեսնեն կիսալցված արդյունքներ։ Կառուցեք նոր index live-ի կողքին, լցրեք այն batch-երով, ստուգեք document-ների քանակը և գործարկեք մի քանի smoke query, ապա traffic-ը փոխեք մեկ ատոմար քայլով։ Elasticsearch-ը և OpenSearch-ը դա անում են alias-ներով. application-ը միշտ query է անում «products» alias-ը, և alias-ի update-ը այն products_v1-ից տեղափոխում է products_v2։ Typesense-ն ունի collection alias-ներ, որոնք աշխատում են նույն կերպ։ Meilisearch-ն առաջարկում է index swap գործողություն, որը ատոմար կերպով փոխանակում է երկու index-ների բովանդակությունը։ Հին index-ը պահեք կարճ ժամանակ, որպեսզի կարողանաք ակնթարթորեն վերադառնալ, եթե ինչ-որ բան սխալ է թվում։

1# Meilisearch: swap the freshly built index with the live one
2curl -X POST 'http://localhost:7700/swap-indexes' \
3  -H 'Authorization: Bearer MEILI_ADMIN_KEY' \
4  -H 'Content-Type: application/json' \
5  --data '[{ "indexes": ["products", "products_new"] }]'
6 
7# Elasticsearch / OpenSearch: move an alias atomically
8curl -X POST 'http://localhost:9200/_aliases' -H 'Content-Type: application/json' -d '{
9  "actions": [
10    { "remove": { "index": "products_v1", "alias": "products" } },
11    { "add":    { "index": "products_v2", "alias": "products" } }
12  ]
13}'

09Անվտանգ search key-եր և ֆիլտրում ըստ օգտատիրոջ

Browser-ի կողմից որոնումը արագ է, որովհետև client-ը engine-ը կանչում է անմիջապես, բայց դա նշանակում է, որ key-ը տեսանելի է բոլորին։ Օգտագործեք search-only key, երբեք՝ admin key-ը։ Երբ արդյունքները պետք է տարբեր լինեն ըստ օգտատիրոջ՝ B2B գնացուցակներ, private կատալոգներ, tenant-ի սեփական տվյալներ, մի հենվեք client-ի վրա ֆիլտր ավելացնելու համար, որովհետև այն կարող է պարզապես հեռացնել այն։ Փոխարենը սերվերը գեներացնում է սահմանափակված key, որն իր մեջ պարունակում է ֆիլտրը և ժամկետը. Algolia-ն դրանք անվանում է secured API key-եր, Typesense-ը՝ scoped API key-եր, իսկ Meilisearch-ը՝ tenant token-ներ, որոնք ստորագրված JWT-ներ են։ Engine-ը ներդրված ֆիլտրը կիրառում է յուրաքանչյուր query-ի վրա։ Index արեք նաև միայն հանրային դաշտերը. index-ում եղած ամեն ինչ կարող է կարդալ համառ օգտատերը։ Rate limit դրեք ըստ key-ի կամ IP-ի և սահմանեք կարճ ժամկետ, որպեսզի արտահոսած key-երը արագ դադարեն աշխատել։

1// Meilisearch tenant token: the filter is enforced by the engine
2import { generateTenantToken } from "meilisearch/token";
3 
4export async function searchTokenFor(customer: { priceListId: number }) {
5  return generateTenantToken({
6    apiKey: process.env.MEILI_SEARCH_KEY!,       // a search-only key
7    apiKeyUid: process.env.MEILI_SEARCH_KEY_UID!,
8    searchRules: { products: { filter: `price_list = ${customer.priceListId}` } },
9    expiresAt: new Date(Date.now() + 60 * 60 * 1000), // 1 hour
10  });
11}

10Բազմալեզու որոնում և լեզվական եզրային դեպքեր

Որոնման որակը կախված է նրանից, թե ինչպես է տեքստը բաժանվում և normalize արվում, և դա կախված է լեզվից։ Անգլերենի stemming-ը «boots»-ը map է անում «boot»-ին, ռուսերենն ու հայերենը ունեն հարուստ վերջավորություններ, որոնք պահանջում են լեզվին համապատասխան մշակում կամ prefix matching, իսկ չինարենին և ճապոներենին պետք է segmentation, որովհետև բառերը բացատներով բաժանված չեն։ Հանդիպում են նաև խառը գրեր. հաճախորդները brand-երի անունները գրում են լատինատառ կամ տառադարձում են տեղական բառերը։ Գործնական մոտեցում. յուրաքանչյուր լեզու պահեք իր դաշտում կամ index-ում, engine-ի լեզվի կամ locale-ի կարգավորումները կարգավորեք բացահայտ՝ ավտոմատ հայտնաբերման վրա հենվելու փոխարեն, ավելացրեք synonym-ներ տառադարձությունների միջև («krem»-ը և cream բառի կիրիլյան գրությունը) և normalize արեք շեշտերը։ Թեստավորեք log-երից վերցված իրական query-ներով յուրաքանչյուր լեզվով, որովհետև կարգավորումը, որը լավ է աշխատում անգլերենով, կարող է լուռ ձախողվել մեկ այլ լեզվով։

• Մեկ searchable դաշտ յուրաքանչյուր լեզվի համար, օրինակ՝ name_en և name_ru։
• Նախ query արեք օգտատիրոջ interface-ի լեզվի index-ը։
• SKU-ները և barcode-ները դիտարկեք որպես exact-match դաշտեր՝ անջատված typo tolerance-ով։