Čau Habr! Volám sa Maxim Vasiliev, pracujem ako analytik a projektový manažér v spoločnosti FINCH. Dnes by som vám rád povedal, ako sme pomocou ElasticSearch dokázali spracovať 15 miliónov požiadaviek za 6 minút a optimalizovať denné zaťaženie stránky jedného z našich klientov. Bohužiaľ sa budeme musieť zaobísť bez mien, keďže máme NDA, dúfame, že tým neutrpí obsah článku. Poďme.
Ako projekt funguje
Na našom backende vytvárame služby, ktoré zabezpečujú funkčnosť webových stránok a mobilnej aplikácie nášho klienta. Všeobecnú štruktúru je možné vidieť na obrázku:
V procese práce spracovávame veľké množstvo transakcií: nákupy, platby, transakcie so zostatkami používateľov, pre ktoré ukladáme veľa protokolov, a tiež importujeme a exportujeme tieto údaje do externých systémov.
Existujú aj spätné procesy, keď prijímame údaje od klienta a prenášame ich používateľovi. Okrem toho existujú aj procesy pre prácu s platbami a bonusové programy.
Krátke pozadie
Spočiatku sme ako jediné úložisko údajov používali PostgreSQL. Jeho výhody sú štandardné pre DBMS: prítomnosť transakcií, vyvinutý jazyk na vyhľadávanie údajov, široká škála nástrojov na integráciu; v kombinácii s dobrým výkonom uspokojovali naše potreby pomerne dlho.
V Postgres sme uložili úplne všetky údaje: od transakcií až po správy. Počet používateľov však rástol a s ním aj počet žiadostí.
Pre pochopenie, ročný počet relácií v roku 2017 len na desktopovej stránke je 131 miliónov. V roku 2018 - 125 miliónov. 2019 opäť 130 miliónov. Pridajte ďalších 100-200 miliónov z mobilnej verzie stránky a mobilnej aplikácie a budete dostane obrovské množstvo žiadostí.
Ako projekt rástol, Postgres už nezvládal záťaž, nestíhali sme – objavilo sa veľké množstvo rôznych dopytov, pre ktoré sa nám nepodarilo vytvoriť dostatočný počet indexov.
Uvedomili sme si, že sú potrebné ďalšie dátové úložiská, ktoré by vyhovovali našim potrebám a odbremenili PostgreSQL. Elasticsearch a MongoDB sa považovali za možné možnosti. Ten prehral v týchto bodoch:
- Pomalá rýchlosť indexovania s rastúcim množstvom údajov v indexoch. Pri Elastic rýchlosť nezávisí od množstva dát.
- Žiadne fulltextové vyhľadávanie
Tak sme si vybrali Elastic pre seba a pripravili sme sa na prechod.
Prechod na elastický
1. Začali sme prechod zo služby vyhľadávania miesta predaja. Náš klient má celkovo cca 70 000 predajných miest a zároveň je potrebných niekoľko typov vyhľadávania na webe a v aplikácii:
- Textové vyhľadávanie podľa názvu mesta
- Geosearch v rámci daného okruhu z určitého bodu. Napríklad, ak chce používateľ vidieť, ktoré predajné miesta sú najbližšie k jeho bydlisku.
- Vyhľadávanie podľa zadaného štvorca – používateľ načrtne štvorec na mape a zobrazia sa mu všetky body v tomto polomere.
- Vyhľadávajte podľa ďalších filtrov. Predajné miesta sa od seba líšia sortimentom
Ak hovoríme o organizácii, tak v Postgres máme dátový zdroj pre mapu aj spravodajstvo a v Elastic Snapshots sú prevzaté z pôvodných dát. Faktom je, že Postgres sa spočiatku nedokázal vyrovnať s vyhľadávaním podľa všetkých kritérií. Nielenže bolo veľa indexov, mohli sa aj prekrývať, takže plánovač Postgresu sa stratil a nerozumel, ktorý index použiť.
2. Ďalšia v poradí bola sekcia noviniek. Publikácie sa na stránke objavujú každý deň, aby sa používateľ nestratil v toku informácií, údaje je potrebné pred vydaním roztriediť. Na to slúži vyhľadávanie: na stránke môžete vyhľadávať podľa zhody textu a zároveň pripájať ďalšie filtre, pretože sú tiež vytvorené cez Elastic.
3. Potom sme presunuli spracovanie transakcie. Používatelia si môžu na stránke zakúpiť konkrétny produkt a zúčastniť sa žrebovania o ceny. Po takýchto nákupoch spracovávame veľké množstvo dát najmä cez víkendy a sviatky. Pre porovnanie, ak v bežné dni je počet nákupov niekde okolo 1,5-2 miliónov, tak cez sviatky môže toto číslo dosiahnuť 53 miliónov.
Údaje musia byť zároveň spracované v čo najkratšom čase – používatelia neradi čakajú na výsledok niekoľko dní. Neexistuje spôsob, ako dosiahnuť takéto termíny prostredníctvom Postgres - často sme dostali zámky a kým sme spracovávali všetky požiadavky, používatelia nemohli skontrolovať, či dostali ceny alebo nie. To nie je pre biznis veľmi príjemné, preto sme spracovanie presunuli na Elasticsearch.
periodicita
Teraz sú aktualizácie konfigurované na základe udalostí podľa nasledujúcich podmienok:
- Predajné miesta. Akonáhle dostaneme dáta z externého zdroja, okamžite spustíme aktualizáciu.
- Správy. Akonáhle sa na stránke upraví nejaká novinka, automaticky sa odošle do Elastic.
Tu opäť stojí za zmienku výhody Elastic. V Postgrese treba pri odosielaní požiadavky počkať, kým poctivo spracuje všetky záznamy. Do Elasticu môžete poslať 10 XNUMX záznamov a začať pracovať okamžite, bez čakania na distribúciu záznamov do všetkých Shard. Samozrejme, niektoré Shard alebo Replica nemusia vidieť údaje hneď, ale čoskoro bude všetko dostupné.
Integračné metódy
Existujú 2 spôsoby integrácie s Elastic:
- Cez natívneho klienta cez TCP. Natívny ovládač postupne vymiera: už nie je podporovaný a jeho syntax je veľmi nepohodlná. Preto ho prakticky nepoužívame a snažíme sa ho úplne opustiť.
- Cez rozhranie HTTP, v ktorom môžete použiť požiadavky JSON aj syntax Lucene. Posledným je textový nástroj, ktorý používa Elastic. V tejto verzii získame možnosť dávkovať cez požiadavky JSON cez HTTP. Toto je možnosť, ktorú sa snažíme využiť.
Vďaka HTTP rozhraniu môžeme využívať knižnice, ktoré poskytujú asynchrónnu implementáciu HTTP klienta. Môžeme využiť Batch a asynchrónne API, ktoré v konečnom dôsledku dáva vysoký výkon, čo veľmi pomohlo počas dní veľkej propagácie (viac o tom nižšie)
Pár čísel na porovnanie:
- Ukladanie používateľov, ktorí získali ceny v Postgrese v 20 vláknach bez zoskupení: 460713 záznamov za 42 sekúnd
- Elastický + reaktívny klient pre 10 vlákien + dávka pre 1000 prvkov: 596749 záznamov za 11 sekúnd
- Elastický + reaktívny klient pre 10 vlákien + dávka pre 1000 prvkov: 23801684 záznamov za 4 minúty
Teraz sme napísali správcu požiadaviek HTTP, ktorý zostavuje JSON ako Batch/non-Batch a odosiela ho cez ľubovoľného HTTP klienta bez ohľadu na knižnicu. Môžete sa tiež rozhodnúť odosielať požiadavky synchrónne alebo asynchrónne.
V niektorých integráciách stále používame oficiálneho dopravného klienta, ale ide len o okamžitú refaktorizáciu. V tomto prípade sa na spracovanie používa jeho vlastný klient, postavený na báze Spring WebClient.
veľká propagácia
Raz ročne sa v projekte koná veľká promo akcia pre používateľov - to je ten istý Highload, pretože v súčasnosti pracujeme s desiatkami miliónov používateľov súčasne.
Špičkový odber sa zvyčajne vyskytuje počas sviatkov, ale táto akcia je na úplne inej úrovni. Predvlani sme v deň akcie predali 27 580 890 kusov tovaru. Spracovanie údajov trvalo viac ako pol hodiny, čo spôsobilo používateľom nepríjemnosti. Používatelia dostali ceny za účasť, ale ukázalo sa, že tento proces je potrebné urýchliť.
Začiatkom roka 2019 sme sa rozhodli, že potrebujeme ElasticSearch. Celý rok sme organizovali spracovanie prijatých dát v Elastic a ich výstup do API mobilnej aplikácie a webu. V dôsledku toho sme ďalší rok počas kampane spracovali 15 131 783 záznamov za 6 minút.
Keďže máme veľa ľudí, ktorí chcú nakupovať tovar a podieľať sa na žrebovaní cien v akciách, ide o dočasné opatrenie. Teraz posielame aktuálne informácie do Elastic, no v budúcnosti plánujeme preniesť archivované informácie za posledné mesiace do Postgresu ako trvalého úložiska. Aby sa nezanášal Elastic index, ktorý má tiež svoje obmedzenia.
Záver / závery
Momentálne sme všetky služby, ktoré sme chceli, preniesli do Elastic a nateraz sme ich pozastavili. Teraz budujeme index v Elastic na vrchole hlavného trvalého úložiska v Postgrese, ktorý preberá zaťaženie používateľa.
V budúcnosti plánujeme preniesť služby, ak pochopíme, že požiadavka na údaje bude príliš rôznorodá a bude sa vyhľadávať pre neobmedzený počet stĺpcov. Toto už nie je úloha pre Postgres.
Ak potrebujeme fulltextové vyhľadávanie vo funkcionalite alebo ak máme veľa rôznych vyhľadávacích kritérií, tak už vieme, že to treba preložiť do Elastic.
⌘⌘⌘
Vďaka za prečítanie. Ak aj vaša spoločnosť používa ElasticSearch a má vlastné prípady implementácie, povedzte nám to. Bude zaujímavé vedieť, ako sú na tom ostatní 🙂
Zdroj: hab.com