Čau Habr! Jmenuji se Maxim Vasiliev a pracuji jako analytik a projektový manažer ve společnosti FINCH. Dnes bych vám rád řekl, jak jsme pomocí ElasticSearch dokázali zpracovat 15 milionů požadavků za 6 minut a optimalizovat denní zatížení na webu jednoho z našich klientů. Bohužel se budeme muset obejít bez jmen, jelikož máme NDA, doufáme, že tím obsah článku neutrpí. Pojďme.
Jak projekt funguje
Na našem backendu vytváříme služby, které zajišťují výkon webů a mobilních aplikací našich klientů. Obecnou strukturu lze vidět na obrázku:
V procesu práce zpracováváme velké množství transakcí: nákupy, platby, operace s uživatelskými zůstatky, ke kterým uchováváme spoustu protokolů, stejně jako import a export těchto dat do externích systémů.
Existují také zpětné procesy, kdy přijímáme data od klienta a předáváme je uživateli. Kromě toho stále existují procesy pro práci s platbami a bonusové programy.
Krátké pozadí
Zpočátku jsme jako jediné úložiště dat používali PostgreSQL. Jeho standardní výhody pro DBMS: přítomnost transakcí, vyvinutý jazyk vzorkování dat, široká škála nástrojů pro integraci; v kombinaci s dobrým výkonem uspokojoval naše potřeby na poměrně dlouhou dobu.
V Postgresu jsme uložili naprosto všechna data: od transakcí po zprávy. Počet uživatelů ale rostl a s ním i počet žádostí.
Pro pochopení, roční počet relací v roce 2017 pouze na desktopovém webu je 131 milionů. V roce 2018 - 125 milionů. 2019 opět 130 milionů. Přidejte dalších 100-200 milionů z mobilní verze webu a mobilní aplikace a budete dostane obrovské množství žádostí.
S růstem projektu Postgres přestal zvládat zátěž, neměli jsme čas – objevilo se velké množství různých dotazů, pro které jsme nedokázali vytvořit dostatečné množství indexů.
Pochopili jsme, že jsou potřeba další datová úložiště, která by uspokojila naše potřeby a odstranila zátěž PostgreSQL. Elasticsearch a MongoDB byly zvažovány jako možné možnosti. Ten prohrál v následujících bodech:
- Pomalá rychlost indexování s rostoucím množstvím dat v indexech. U Elastic není rychlost závislá na množství dat.
- Žádné fulltextové vyhledávání
Vybrali jsme si tedy pro sebe Elastic a připravili se na přechod.
Přechod na elastické
1. Zahájili jsme přechod ze služby vyhledávání místa prodeje. Náš klient má celkem asi 70 000 prodejních míst, což vyžaduje několik typů vyhledávání na webu a v aplikaci:
- Textové vyhledávání podle názvu města
- Geosearch v daném okruhu z určitého bodu. Například pokud chce uživatel vidět, která prodejní místa jsou nejblíže jeho domovu.
- Vyhledávání podle daného čtverce – uživatel nakreslí čtverec na mapu a zobrazí se mu všechny body v tomto poloměru.
- Vyhledávání podle dalších filtrů. Prodejní místa se od sebe liší sortimentem
Pokud se budeme bavit o organizaci, tak v Postgres máme zdroj dat pro mapu i zprávy a v Elastic Snapshots jsou převzaty z původních dat. Faktem je, že zpočátku Postgres nemohl zvládnout vyhledávání podle všech kritérií. Nejen, že bylo mnoho indexů, mohly se také překrývat, takže plánovač Postgresu se ztratil a nechápal, který index použít.
2. Další na řadě byla sekce novinek. Publikace se na stránkách objevují každý den, aby se uživatel neztratil v toku informací, data je nutné před vydáním roztřídit. K tomu slouží vyhledávání: na webu můžete vyhledávat podle shody textu a zároveň připojit další filtry, protože jsou také vytvořeny přes Elastic.
3. Poté jsme přesunuli zpracování transakcí. Uživatelé si mohou na webu zakoupit určitý produkt a zúčastnit se slosování o ceny. Po takových nákupech zpracováváme velké množství dat, zejména o víkendech a svátcích. Pro srovnání, pokud v běžné dny je počet nákupů někde mezi 1,5-2 miliony, pak o svátcích může toto číslo dosáhnout 53 milionů.
Data musí být zároveň zpracována v co nejkratším čase – uživatelé neradi čekají na výsledek několik dní. Neexistuje způsob, jak dosáhnout takových termínů prostřednictvím Postgres - často jsme obdrželi zámky, a zatímco jsme zpracovávali všechny požadavky, uživatelé nemohli zkontrolovat, zda obdrželi ceny nebo ne. To není pro obchod příliš příjemné, proto jsme zpracování přesunuli do Elasticsearch.
Periodicita
Nyní jsou aktualizace konfigurovány na základě událostí podle následujících podmínek:
- Prodejní místa. Jakmile obdržíme data z externího zdroje, okamžitě spustíme aktualizaci.
- Zprávy. Jakmile je nějaká novinka na webu upravena, je automaticky odeslána do Elastic.
Zde opět stojí za zmínku výhody Elastic. V Postgresu si při odesílání požadavku musíte počkat, až poctivě zpracuje všechny záznamy. Do Elastic můžete poslat 10 XNUMX záznamů a začít pracovat okamžitě, aniž byste museli čekat na distribuci záznamů do všech Shard. Samozřejmě, že některý Shard nebo Replica nemusí vidět data hned, ale vše bude k dispozici velmi brzy.
Integrační metody
Existují 2 způsoby integrace s Elastic:
- Prostřednictvím nativního klienta přes TCP. Nativní ovladač postupně vymírá: již není podporován, má velmi nepohodlnou syntaxi. Proto ji prakticky nepoužíváme a snažíme se ji úplně opustit.
- Prostřednictvím rozhraní HTTP, které může používat požadavky JSON i syntaxi Lucene. Poslední je textový engine, který využívá Elastic. V této verzi získáváme možnost dávkovat prostřednictvím požadavků JSON přes HTTP. Toto je možnost, kterou se snažíme využít.
Díky HTTP rozhraní můžeme využívat knihovny, které poskytují asynchronní implementaci HTTP klienta. Můžeme využít Batch a asynchronní API, což má za následek vysoký výkon, což hodně pomohlo ve dnech velké propagace (více o tom níže)
Pár čísel pro srovnání:
- Ukládání uživatelů Bounty Postgres ve 20 vláknech bez seskupování: 460713 záznamů za 42 sekund
- Elastický + reaktivní klient pro 10 vláken + dávka pro 1000 prvků: 596749 záznamů za 11 sekund
- Elastický + reaktivní klient pro 10 vláken + dávka pro 1000 prvků: 23801684 záznamů za 4 minuty
Nyní jsme napsali správce požadavků HTTP, který sestaví JSON jako Batch/not Batch a odešle jej přes libovolného HTTP klienta bez ohledu na knihovnu. Můžete si také vybrat, zda chcete odesílat požadavky synchronně nebo asynchronně.
V některých integracích stále používáme oficiálního transportního klienta, ale to je jen otázka dalšího refaktoringu. V tomto případě je pro zpracování použit klient na míru postavený na bázi Spring WebClient.
velká propagace
Jednou ročně projekt pořádá velkou propagaci pro uživatele - to je stejný Highload, protože v tuto chvíli pracujeme s desítkami milionů uživatelů současně.
O prázdninách obvykle dochází k vrcholům zátěže, ale tato akce je na úplně jiné úrovni. Předloni jsme v den akce prodali 27 580 890 kusů zboží. Data byla zpracovávána déle než půl hodiny, což uživatelům způsobilo nepříjemnosti. Uživatelé obdrželi ceny za účast, ale bylo jasné, že je třeba proces urychlit.
Na začátku roku 2019 jsme se rozhodli, že potřebujeme ElasticSearch. Celý rok jsme organizovali zpracování přijatých dat v Elastic a jejich výdej v api mobilní aplikace a webu. Ve výsledku jsme další rok v průběhu kampaně zpracovali 15 131 783 záznamů za 6 minut.
Vzhledem k tomu, že máme spoustu lidí, kteří chtějí nakupovat zboží a podílet se na losování cen v akcích, jedná se o dočasné opatření. Nyní posíláme aktuální informace do Elastic, ale v budoucnu plánujeme přenést archivované informace za poslední měsíce do Postgresu jako trvalé úložiště. Aby se nezanášel Elastic index, který má také svá omezení.
Závěr / závěry
V tuto chvíli jsme převedli všechny služby, které jsme chtěli, na Elastic a prozatím jsme se nad tím pozastavili. Nyní budujeme index v Elastic nad hlavním trvalým úložištěm v Postgresu, který přebírá zatížení uživatele.
V budoucnu plánujeme převod služeb, pokud pochopíme, že požadavek na data bude příliš různorodý a bude prohledáván neomezený počet sloupců. To už není úkol pro Postgres.
Pokud potřebujeme fulltextové vyhledávání ve funkcionalitě nebo pokud máme mnoho různých vyhledávacích kritérií, pak již víme, že je třeba to převést do elastického.
⌘⌘⌘
Děkuji za přečtení. Pokud vaše společnost také používá ElasticSearch a má vlastní případy implementace, řekněte nám to. Bude zajímavé vědět, jak jsou na tom ostatní 🙂
Zdroj: www.habr.com