Հե՜յ Հաբր։ Ես Մաքսիմ Վասիլիևն եմ, աշխատում եմ որպես վերլուծաբան և ծրագրի ղեկավար FINCH-ում: Այսօր ես կցանկանայի ձեզ պատմել, թե ինչպես, օգտագործելով ElasticSearch-ը, մենք կարողացանք 15 րոպեում մշակել 6 միլիոն հարցում և օպտիմալացնել ամենօրյա բեռները մեր հաճախորդներից մեկի կայքում: Ցավոք, մենք ստիպված կլինենք անել առանց անունների, քանի որ ունենք ԱԺԴ, հուսով ենք, որ հոդվածի բովանդակությունը դրանից չի տուժի։ Գնացինք.
Ինչպես է աշխատում նախագիծը
Մեր հետին պլանում մենք ստեղծում ենք ծառայություններ, որոնք ապահովում են մեր հաճախորդի կայքերի և բջջային հավելվածների աշխատանքը: Ընդհանուր կառուցվածքը կարելի է տեսնել դիագրամում.
Աշխատանքի ընթացքում մենք մշակում ենք մեծ թվով գործարքներ՝ գնումներ, վճարումներ, գործառնություններ օգտատերերի մնացորդներով, որոնց համար մենք պահում ենք բազմաթիվ տեղեկամատյաններ, ինչպես նաև ներմուծում և արտահանում ենք այդ տվյալները արտաքին համակարգեր:
Կան նաև հակադարձ գործընթացներ, երբ մենք տվյալներ ենք ստանում հաճախորդից և փոխանցում օգտվողին: Բացի այդ, դեռևս կան վճարումների և բոնուսային ծրագրերի հետ աշխատելու գործընթացներ։
Համառոտ նախապատմություն
Սկզբում մենք օգտագործում էինք PostgreSQL որպես տվյալների միակ պահեստ: DBMS-ի համար դրա ստանդարտ առավելությունները. գործարքների առկայություն, տվյալների նմուշառման մշակված լեզու, ինտեգրման գործիքների լայն շրջանակ. լավ կատարողականի հետ միասին բավական երկար ժամանակ բավարարեց մեր կարիքները:
Մենք Պոստգրեսում պահում էինք բացարձակապես բոլոր տվյալները՝ գործարքներից մինչև նորություններ: Բայց օգտատերերի թիվն աճեց, և դրա հետ մեկտեղ՝ հարցումների թիվը։
Հասկանալու համար, 2017 թվականին միայն աշխատասեղանի կայքում սեանսների տարեկան թիվը կազմում է 131 միլիոն, 2018 թվականին՝ 125 միլիոն, 2019 թվականին կրկին 130 միլիոն: Ավելացրեք ևս 100-200 միլիոն կայքի բջջային տարբերակից և բջջային հավելվածից, և դուք կստանան մեծ թվով հարցումներ:
Նախագծի աճով Postgres-ը դադարեց հաղթահարել բեռը, մենք ժամանակ չունեինք՝ հայտնվեցին մեծ թվով տարբեր հարցումներ, որոնց համար չկարողացանք ստեղծել բավարար թվով ինդեքսներ։
Մենք հասկացանք, որ կարիք կա տվյալների այլ պահեստների, որոնք կապահովեն մեր կարիքները և կհանեն PostgreSQL-ի բեռը: Որպես հնարավոր տարբերակներ դիտարկվել են Elasticsearch-ը և MongoDB-ն: Վերջինս պարտվել է հետևյալ միավորներով.
- Ինդեքսավորման դանդաղ արագություն, քանի որ ինդեքսներում տվյալների քանակն աճում է: Elastic-ի դեպքում արագությունը կախված չէ տվյալների քանակից:
- Ամբողջական տեքստի որոնում չկա
Այսպիսով, մենք ընտրեցինք Elastic-ը մեզ համար և պատրաստվեցինք անցմանը:
Անցում դեպի էլաստիկ
1. Մենք անցում կատարեցինք վաճառքի կետի որոնման ծառայությունից։ Մեր հաճախորդն ունի ընդհանուր առմամբ մոտ 70 վաճառքի կետ, և դա պահանջում է մի քանի տեսակի որոնումներ կայքում և հավելվածում.
- Տեքստի որոնում ըստ քաղաքի անունով
- Երկրագնդի որոնում տվյալ շառավղով ինչ-որ կետից: Օրինակ, եթե օգտատերը ցանկանում է տեսնել, թե վաճառքի որ կետերն են առավել մոտ իր տանը:
- Որոնել ըստ տրված քառակուսու - օգտատերը քարտեզի վրա նկարում է քառակուսի, և այս շառավղով բոլոր կետերը ցույց են տրվում նրան:
- Որոնել լրացուցիչ զտիչներով: Վաճառքի կետերը տարբերվում են միմյանցից տեսականիով
Եթե խոսում ենք կազմակերպության մասին, ապա Postgres-ում մենք ունենք տվյալների աղբյուր ինչպես քարտեզի, այնպես էլ նորությունների համար, իսկ Elastic Snapshots-ը վերցված է սկզբնական տվյալներից։ Փաստն այն է, որ ի սկզբանե Postgres-ը չկարողացավ հաղթահարել որոնումները բոլոր չափանիշներով։ Ոչ միայն շատ ինդեքսներ կային, դրանք կարող էին նաև համընկնել, ուստի Postgres-ի ժամանակացույցը կորավ և չհասկացավ, թե որ ինդեքսն օգտագործել:
2. Հաջորդը նորությունների բաժինն էր: Կայքում հրապարակումներ են հայտնվում ամեն օր, որպեսզի օգտատերը չկորչի տեղեկատվական հոսքի մեջ, տվյալները պետք է տեսակավորվեն մինչև թողարկումը։ Որոնումը հենց դրա համար է. կարող եք որոնել կայքը ըստ տեքստային համընկնման, և միևնույն ժամանակ միացնել լրացուցիչ զտիչներ, քանի որ դրանք նույնպես արվում են Elastic-ի միջոցով:
3. Հետո տեղափոխեցինք գործարքի մշակումը: Օգտագործողները կարող են կայքում գնել որոշակի ապրանք և մասնակցել մրցանակային խաղարկությանը: Նման գնումներից հետո մենք մշակում ենք մեծ քանակությամբ տվյալներ, հատկապես հանգստյան օրերին և տոն օրերին: Համեմատության համար նշենք, որ եթե սովորական օրերին գնումների թիվը հասնում է 1,5-2 միլիոնի, ապա տոն օրերին այդ թիվը կարող է հասնել 53 միլիոնի։
Միևնույն ժամանակ, տվյալները պետք է մշակվեն հնարավորինս կարճ ժամկետում՝ օգտատերերը չեն սիրում արդյունքի սպասել մի քանի օր։ Postgres-ի միջոցով նման ժամկետների հասնելու միջոց չկա. մենք հաճախ կողպեքներ էինք ստանում, և մինչ մենք մշակում էինք բոլոր հարցումները, օգտատերերը չէին կարողանում ստուգել՝ ստացել են մրցանակներ, թե ոչ: Սա այնքան էլ հաճելի չէ բիզնեսի համար, ուստի վերամշակումը տեղափոխեցինք Elasticsearch:
Պարբերականություն
Այժմ թարմացումները կազմաձևվում են իրադարձությունների վրա հիմնված՝ հետևյալ պայմանների համաձայն.
- Վաճառքի կետեր. Արտաքին աղբյուրից տվյալներ ստանալուն պես անմիջապես սկսում ենք թարմացումը։
- Նորություններ. Կայքում որևէ նորություն խմբագրելուն պես այն ավտոմատ կերպով ուղարկվում է Էլաստիկ։
Այստեղ կրկին հարկ է նշել Elastic-ի առավելությունները. Postgres-ում հարցում ուղարկելիս պետք է սպասել, մինչև այն ազնվորեն մշակի բոլոր գրառումները։ Դուք կարող եք ուղարկել 10 ձայնագրություն Elastic-ին և անմիջապես սկսել աշխատել՝ չսպասելով, որ գրառումները տարածվեն բոլոր Shards-ում: Իհարկե, որոշ Shard կամ Replica կարող են անմիջապես չտեսնել տվյալները, բայց ամեն ինչ հասանելի կլինի շատ շուտով:
Ինտեգրման մեթոդներ
Elastic-ի հետ ինտեգրվելու 2 եղանակ կա.
- TCP-ի միջոցով հայրենի հաճախորդի միջոցով: Մայրենի դրայվերը աստիճանաբար մարում է. այն այլևս չի աջակցվում, ունի շատ անհարմար շարահյուսություն։ Ուստի մենք գործնականում չենք օգտագործում այն և փորձում ենք ամբողջությամբ հրաժարվել դրանից։
- HTTP ինտերֆեյսի միջոցով, որը կարող է օգտագործել և՛ JSON հարցումները, և՛ Lucene-ի շարահյուսությունը: Վերջինը տեքստային շարժիչ է, որն օգտագործում է Elastic: Այս տարբերակում մենք հնարավորություն ենք ստանում փաթեթավորել JSON հարցումների միջոցով HTTP-ի միջոցով: Սա այն տարբերակն է, որը մենք փորձում ենք օգտագործել:
HTTP ինտերֆեյսի շնորհիվ մենք կարող ենք օգտագործել գրադարաններ, որոնք ապահովում են HTTP հաճախորդի ասինխրոն իրականացում: Մենք կարող ենք օգտվել Batch-ից և ասինխրոն API-ից, ինչը հանգեցնում է բարձր կատարողականության, ինչը շատ օգնեց մեծ առաջխաղացման օրերին (դրա մասին ավելին ստորև)
Համեմատության համար որոշ թվեր.
- Պահպանելով Postgres-ի օգտատերերին 20 թեմայում՝ առանց խմբավորման. 460713 գրառում 42 վայրկյանում
- Էլաստիկ + ռեակտիվ հաճախորդ 10 թելերի համար + խմբաքանակ 1000 տարրի համար. 596749 գրառում 11 վայրկյանում
- Էլաստիկ + ռեակտիվ հաճախորդ 10 թելերի համար + խմբաքանակ 1000 տարրի համար. 23801684 գրառում 4 րոպեում
Այժմ մենք գրել ենք HTTP հարցումների կառավարիչ, որը կառուցում է JSON որպես Batch/not Batch և ուղարկում այն ցանկացած HTTP հաճախորդի միջոցով՝ անկախ գրադարանից: Կարող եք նաև ընտրել հարցումներ ուղարկել համաժամանակյա կամ ասինխրոն:
Որոշ ինտեգրացիաներում մենք դեռ օգտագործում ենք պաշտոնական տրանսպորտի հաճախորդը, բայց սա ընդամենը հաջորդ վերամշակման հարց է: Այս դեպքում մշակման համար օգտագործվում է «Spring WebClient»-ի հիման վրա կառուցված մաքսային հաճախորդ:
մեծ առաջխաղացում
Տարին մեկ անգամ նախագիծը հյուրընկալում է օգտատերերի համար մեծ առաջխաղացում՝ սա նույն Highload-ն է, քանի որ այս պահին մենք միաժամանակ աշխատում ենք տասնյակ միլիոնավոր օգտատերերի հետ:
Սովորաբար տոնական օրերին ծանրաբեռնվածության գագաթնակետը տեղի է ունենում, բայց այս ակցիան բոլորովին այլ մակարդակի վրա է: Նախորդ տարի՝ ակցիայի օրը, վաճառել ենք 27 580 890 միավոր ապրանք։ Տվյալները մշակվել են ավելի քան կես ժամ, ինչը անհարմարություններ է առաջացրել օգտատերերի համար։ Մասնակցության համար օգտատերերը մրցանակներ ստացան, սակայն պարզ դարձավ, որ գործընթացը պետք է արագացնել։
2019 թվականի սկզբին մենք որոշեցինք, որ մեզ անհրաժեշտ է ElasticSearch: Մի ամբողջ տարի կազմակերպել ենք ստացված տվյալների մշակումը Elastic-ում և դրանց թողարկումը բջջային հավելվածի և կայքի api-ում։ Արդյունքում հաջորդ տարի քարոզարշավի ընթացքում մշակեցինք 15 գրառում 131 րոպեում։
Քանի որ մենք ունենք շատ մարդիկ, ովքեր ցանկանում են ապրանքներ գնել և մասնակցել ակցիաների մրցանակների խաղարկությանը, սա ժամանակավոր միջոց է։ Այժմ մենք թարմ տեղեկություններ ենք ուղարկում Elastic-ին, սակայն ապագայում նախատեսում ենք վերջին ամիսների արխիվացված տեղեկությունները փոխանցել Postgres-ին՝ որպես մշտական պահեստ: Որպեսզի չխցանվի Էլաստիկ ինդեքսը, որն ունի նաև իր սահմանափակումները։
Եզրակացություն/Եզրակացություններ
Այս պահին մենք Elastic-ին ենք փոխանցել բոլոր այն ծառայությունները, որոնք ցանկանում էինք և առայժմ դադարեցրել ենք դրա վրա։ Այժմ մենք կառուցում ենք ինդեքս Elastic-ում Postgres-ի հիմնական մշտական պահեստի վերևում, որը վերցնում է օգտվողի բեռը:
Ապագայում մենք նախատեսում ենք ծառայություններ փոխանցել, եթե հասկանանք, որ տվյալների հարցումը դառնում է չափազանց բազմազան և որոնվում է անսահմանափակ թվով սյունակներ: Պոստգրեսի համար սա այլևս խնդիր չէ:
Եթե մեզ անհրաժեշտ է ամբողջական տեքստի որոնում ֆունկցիոնալության մեջ, կամ եթե մենք ունենք որոնման շատ տարբեր չափանիշներ, ապա մենք արդեն գիտենք, որ դա պետք է թարգմանվի Elastic:
⌘⌘⌘
Շնորհակալություն կարդալու համար: Եթե ձեր ընկերությունը նույնպես օգտագործում է ElasticSearch-ը և ունի իր իրականացման դեպքերը, ապա ասեք մեզ: Հետաքրքիր կլինի իմանալ, թե ինչպես են մյուսները 🙂
Source: www.habr.com