Hey Habr! Mäin Numm ass Maxim Vasiliev, ech schaffen als Analyst a Projektmanager bei FINCH. Haut wëll ech Iech soen wéi mir mat ElasticSearch 15 Milliounen Ufroen a 6 Minutten konnten veraarbecht an déi deeglech Lasten op der Säit vun engem vun eise Clienten optimiséieren. Leider musse mir ouni Nimm maachen, well mir eng NDA hunn, hoffen mir datt den Inhalt vum Artikel net dovunner wäert leiden. A lass.
Wéi de Projet funktionnéiert
Op eisem Backend kreéiere mir Servicer déi d'Performance vun eise Client Websäiten a mobil Applikatioun garantéieren. Déi allgemeng Struktur kann am Diagramm gesi ginn:
Am Prozess vun der Aarbecht veraarbechte mir eng grouss Unzuel vun Transaktiounen: Akeef, Bezuelen, Operatiounen mat Benotzersaldo, fir déi mir vill Logbicher späicheren, wéi och dës Donnéeën an extern Systemer importéieren an exportéieren.
Et ginn och ëmgedréint Prozesser wa mir Daten vum Client kréien an se un de Benotzer transferéieren. Zousätzlech ginn et nach Prozesser fir mat Bezuelungen a Bonusprogrammer ze schaffen.
Kuerz Hannergrond
Am Ufank hu mir PostgreSQL als eenzegen Dategeschäft benotzt. Seng Standardvirdeeler fir e DBMS: d'Präsenz vun Transaktiounen, eng entwéckelt Dateprobesprooch, eng breet Palette vun Tools fir Integratioun; kombinéiert mat gudder Leeschtung eis Bedierfnesser fir eng zimlech laang Zäit zefridden.
Mir hunn absolut all Daten am Postgres gespäichert: vun Transaktiounen bis Neiegkeeten. Awer d'Zuel vun de Benotzer ass gewuess, an domat d'Zuel vun den Ufroen.
Fir Versteesdemech, d'Joreszuel vun Sessiounen am Joer 2017 nëmmen op der Desktop Site ass 131 Millioune 2018 - 125 Millioune 2019 erëm 130 Millioune. wäert eng grouss Zuel vun Demanden kréien.
Mam Wuesstum vum Projet huet Postgres opgehalen mat der Belaaschtung ze këmmeren, mir haten keng Zäit - eng grouss Zuel vu verschiddene Ufroen erschéngen, fir déi mir net genuch Zuel vun Indexen erstellen konnten.
Mir hunn verstanen datt et e Bedierfnes fir aner Dategeschäfter war déi eis Bedierfnesser ubidden an d'Laascht vun PostgreSQL huelen. Elasticsearch a MongoDB goufen als méiglech Optiounen ugesinn. Déi lescht huet op folgende Punkten verluer:
- Lues Indexéierungsgeschwindegkeet wéi d'Quantitéit vun Daten an Indexen wiisst. Mat Elastic hänkt d'Geschwindegkeet net vun der Quantitéit un Daten of.
- Keng Volltext Sich
Also hu mir Elastic fir eis selwer gewielt a fir den Iwwergang virbereet.
Iwwergank zu Elastik
1. Mir hunn den Iwwergank vum Punkt vum Verkaf Sich Service ugefaangen. Eise Client huet am Ganzen ongeféier 70 Verkafspunkten, an dëst erfuerdert verschidden Aarte vu Sichen um Site an an der Applikatioun:
- Text Sich no Stad Numm
- Geosearch bannent engem bestëmmte Radius vun engem Punkt. Zum Beispill, wann de Benotzer wëll kucken wéi eng Verkaafspunkten am nootste bei sengem Heem sinn.
- Sich no engem bestëmmte Quadrat - de Benotzer zitt e Quadrat op der Kaart, an all Punkten an dësem Radius ginn him gewisen.
- Sich no zousätzlech Filteren. Verkafspunkte ënnerscheede sech vuneneen am Sortiment
Wa mir iwwer d'Organisatioun schwätzen, dann an Postgres hu mir eng Datenquell fir d'Kaart an d'Noriichten, an an Elastesche Snapshots ginn aus den ursprénglechen Donnéeën geholl. D'Tatsaach ass datt am Ufank Postgres d'Sich no all Critèren net eens konnt. Net nëmme waren et vill Indexen, si konnten och iwwerlappen, sou datt de Postgres Scheduler verluer ass an net verstanen huet wéi en Index ze benotzen.
2. Als nächst war d'Noriichtenabschnitt. Publikatiounen erschéngen all Dag um Site fir datt de Benotzer net am Informatiounsfloss verluer geet, d'Donnéeën musse sortéiert ginn ier se erausginn. Dëst ass wat d'Sich ass: Dir kënnt de Site no Textmatch sichen, a gläichzäiteg zousätzlech Filtere verbannen, well se och duerch Elastic gemaach ginn.
3. Da geplënnert mir d'Transaktioun Veraarbechtung. D'Benotzer kënnen e bestëmmte Produit um Site kafen an un engem Präisaustausch deelhuelen. No esou Akeef veraarbechte mir eng grouss Quantitéit un Donnéeën, besonnesch op Weekend a Feierdeeg. Zum Verglach, wann op gewéinlech Deeg d'Zuel vun Akeef iergendwou tëscht 1,5-2 Milliounen ass, dann op Feierdeeg d'Figur kann 53 Milliounen erreechen.
Zur selwechter Zäit mussen d'Donnéeën a kuerzer Zäit veraarbecht ginn - d'Benotzer waarden net gär op d'Resultat fir e puer Deeg. Et gëtt kee Wee fir sou Terminë duerch Postgres z'erreechen - mir kruten dacks Spären, a wärend mir all Ufroe veraarbecht hunn, konnten d'Benotzer net kontrolléieren ob se Präisser kréien oder net. Dëst ass net ganz agreabel fir d'Geschäft, also hu mir d'Veraarbechtung op Elasticsearch geplënnert.
Periodizitéit
Elo sinn d'Aktualiséierungen Event-baséiert konfiguréiert, no de folgende Konditiounen:
- Ofsaz Punkten. Soubal mir Daten vun enger externer Quell kréien, starten mir direkt den Update.
- Neiegkeeten. Soubal Neiegkeeten um Site geännert ginn, ginn se automatesch un Elastic geschéckt.
Hei nach eng Kéier ass et derwäert d'Virdeeler vun Elastic ze ernimmen. Am Postgres, wann Dir eng Ufro schéckt, musst Dir waarden bis et éierlech all Rekorder veraarbecht. Dir kënnt 10 Opzeechnungen op Elastic schécken an direkt ufänken ze schaffen, ouni ze waarden op d'Opzeechnungen iwwer all Shards verdeelt ginn. Natierlech kënnen e puer Shard oder Replica d'Donnéeën net direkt gesinn, awer alles wäert ganz séier verfügbar sinn.
Integratioun Methoden
Et ginn 2 Weeër fir mat Elastic z'integréieren:
- Duerch en gebiertege Client iwwer TCP. Den gebiertege Chauffer stierft lues a lues aus: et gëtt net méi ënnerstëtzt, et huet eng ganz onbequem Syntax. Dofir benotze mir et praktesch net a probéieren et komplett opzeginn.
- Duerch eng HTTP-Interface déi souwuel JSON Ufroen wéi och Lucene Syntax benotze kann. Déi lescht ass en Textmotor deen Elastic benotzt. An dëser Versioun kréie mir d'Fäegkeet fir duerch JSON Ufroen iwwer HTTP ze batch. Dëst ass d'Optioun déi mir probéieren ze benotzen.
Dank der HTTP-Interface kënne mir Bibliothéike benotzen, déi eng asynchron Ëmsetzung vum HTTP-Client ubidden. Mir kënne vu Batch an der asynchroner API profitéieren, wat zu héijer Leeschtung resultéiert, wat vill gehollef huet an den Deeg vun der grousser Promotioun (méi doriwwer hei ënnen)
E puer Zuelen zum Verglach:
- Spuert Postgres Bounty Benotzer an 20 Threads ouni Gruppéierung: 460713 records an 42 Sekonnen
- Elastesche + reaktive Client fir 10 Threads + Batch fir 1000 Elementer: 596749 records an 11 Sekonnen
- Elastesch + reaktiv Client fir 10 Threads + Batch fir 1000 Elementer: 23801684 Entréen a 4 Minutten
Elo hu mir en HTTP Ufro Manager geschriwwen deen JSON als Batch / net Batch baut an et iwwer all HTTP Client schéckt, onofhängeg vun der Bibliothéik. Dir kënnt och wielen Ufroe synchron oder asynchron ze schécken.
A verschiddenen Integratioune benotze mir nach ëmmer den offiziellen Transportclient, awer dëst ass just eng Fro vun der nächster Refactoring. An dësem Fall gëtt e personaliséierte Client gebaut op Basis vum Spring WebClient fir d'Veraarbechtung benotzt.
grouss Promotioun
Eemol am Joer organiséiert de Projet eng grouss Promotioun fir d'Benotzer - dat ass déiselwecht Highload, well mir zu dëser Zäit mat zéngdausende vu Millioune Benotzer zur selwechter Zäit schaffen.
Normalerweis komme Spëtze vu Lasten an de Feierdeeg, awer dës Promotioun ass op engem ganz aneren Niveau. D'Joer virdrun, um Dag vun der Promotioun, verkaf mir 27 Unitéiten vun Wueren. D'Date goufe fir méi wéi eng hallef Stonn veraarbecht, wat fir d'Benotzer Onbequemlechkeet verursaacht huet. D'Benotzer krute Präisser fir d'Participatioun, awer et gouf kloer datt de Prozess muss beschleunegt ginn.
Am Ufank vum 2019 hu mir decidéiert datt mir ElasticSearch brauchen. Fir e ganzt Joer hu mir d'Veraarbechtung vun den erhalenen Donnéeën an Elastic organiséiert an hir Emissioun am API vun der mobiler Applikatioun an der Websäit. Als Resultat hunn mir d'nächst Joer während der Campagne veraarbecht 15 Entréen a 131 Minutten.
Well mir vill Leit hunn, déi Wueren kafen wëllen an un der Auslousung vu Präisser bei Promotiounen deelhuelen, ass dëst eng temporär Moossnam. Elo schécken mir aktuell Informatioun un Elastic, awer an Zukunft plangen mir archivéiert Informatioune fir déi lescht Méint op Postgres als permanent Lagerung ze transferéieren. Fir den Elastesche Index net ze verstoppen, deen och seng Aschränkungen huet.
Conclusioun / Conclusiounen
Am Moment hu mir all d'Servicer, déi mir wollten, op Elastic iwwerginn an hunn elo op dëser Paus gestoppt. Elo bauen mir en Index an Elastic uewen op der Haaptpersistent Lagerung am Postgres, déi d'Benotzerbelaaschtung iwwerhëlt.
An Zukunft plangen mir Servicer ze transferéieren wa mir verstinn datt d'Datenufro ze divers gëtt an no enger onlimitéierter Zuel vu Spalten gesicht gëtt. Dëst ass net méi eng Aufgab fir Postgres.
Wa mir Volltext Sich a Funktionalitéit brauchen oder wa mir vill verschidde Sichkriterien hunn, da wësse mer schonn datt dëst an Elastic muss iwwersat ginn.
⌘⌘⌘
Merci fir d'Liesen. Wann Är Firma och ElasticSearch benotzt an hir eegen Implementatiounsfäll huet, da sot eis. Et wäert interessant sinn ze wëssen wéi anerer sinn 🙂
Source: will.com