Hoi Habr! Myn namme is Maxim Vasiliev, ik wurkje as analist en projektmanager by FINCH. Hjoed wol ik jo fertelle hoe't wy mei ElasticSearch 15 miljoen oanfragen yn 6 minuten koene ferwurkje en de deistige ladingen op 'e side fan ien fan ús kliïnten optimalisearje. Spitigernôch sille wy sûnder nammen moatte dwaan, om't wy in NDA hawwe, hoopje wy dat de ynhâld fan it artikel hjir gjin lêst fan sil hawwe. Litte wy gean.
Hoe't it projekt wurket
Op ús backend meitsje wy tsjinsten dy't de prestaasjes fan 'e websiden en mobile applikaasje fan ús kliïnt garandearje. De algemiene struktuer kin sjoen wurde yn it diagram:
Yn it wurkproses ferwurkje wy in grut oantal transaksjes: oankeapen, betellingen, operaasjes mei brûkerssaldo, wêrfoar wy in protte logs opslaan, en ek dizze gegevens ymportearje en eksportearje nei eksterne systemen.
D'r binne ek omkearde prosessen as wy gegevens ûntfange fan 'e kliïnt en oerdrage oan de brûker. Dêrneist binne der noch prosessen foar it wurkjen mei betellingen en bonusprogramma's.
Koarte eftergrûn
Yn it earstoan brûkten wy PostgreSQL as de ienige gegevenswinkel. Syn standert foardielen foar in DBMS: de oanwêzigens fan transaksjes, in ûntwikkele data sampling taal, in breed skala oan ark foar yntegraasje; kombinearre mei goede prestaasje tefreden ús behoeften foar in hiel lange tiid.
Wy hawwe absolút alle gegevens opslein yn Postgres: fan transaksjes oant nijs. Mar it tal brûkers groeide, en dêrmei it tal oanfragen.
Foar it begripen is it jierlikse oantal sesjes yn 2017 allinich op 'e buroblêdside 131 miljoen. Yn 2018 - 125 miljoen 2019 wer 130 miljoen. Foegje nochris 100-200 miljoen ta fan 'e mobile ferzje fan' e side en de mobile applikaasje, en jo sil in grut oantal oanfragen krije.
Mei de groei fan it projekt stopte Postgres om te gean mei de lading, wy hiene gjin tiid - in grut oantal ferskate fragen ferskynden, wêrfoar't wy net in foldwaande oantal yndeksen koenen meitsje.
Wy begrepen dat d'r ferlet wie foar oare gegevenswinkels dy't ús behoeften soene leverje en de lading fan PostgreSQL ôfnimme. Elasticsearch en MongoDB waarden beskôge as mooglike opsjes. De lêste ferlear op de folgjende punten:
- Stadige yndeksearring snelheid as de hoemannichte gegevens yn yndeksen groeit. Mei Elastic is de snelheid net ôfhinklik fan 'e hoemannichte gegevens.
- Gjin folsleine tekst sykjen
Sa hawwe wy foar ússels Elastic keazen en taret op de oergong.
Oergong nei elastysk
1. Wy begûn de oergong fan it punt fan ferkeap sykje tsjinst. Us klant hat yn totaal sawat 70 ferkeappunten, en dit fereasket ferskate soarten sykopdrachten op 'e side en yn' e applikaasje:
- Tekst sykje op stêdnamme
- Geosearch binnen in opjûne straal fan in bepaald punt. As de brûker bygelyks wol sjen wol hokker ferkeappunten it tichtst by syn hûs lizze.
- Sykje op in bepaald plein - de brûker tekent in plein op 'e kaart, en alle punten yn dizze straal wurde oan him toand.
- Sykje troch ekstra filters. Ferkeappunten ferskille fan elkoar yn assortiment
As wy prate oer de organisaasje, dan hawwe wy yn Postgres in gegevensboarne foar sawol de kaart as it nijs, en yn Elastic Snapshots wurde nommen fan 'e orizjinele gegevens. It feit is dat Postgres yn earste ynstânsje net koe omgean mei it sykjen troch alle kritearia. Net allinich wiene d'r in protte yndeksen, se koene ek oerlappe, sadat de Postgres-planner ferlern gien en net begriep hokker yndeks te brûken.
2. Folgjende yn rige wie de nijs seksje. Publikaasjes ferskine op 'e side alle dagen sadat de brûker net ferdwale yn' e stream fan ynformaasje, de gegevens moatte wurde sorteare foardat se útjûn wurde. Dit is wêr't sykjen foar is: jo kinne de side sykje op tekstmatch, en tagelyk ekstra filters ferbine, om't se ek makke wurde fia Elastic.
3. Doe ferhuze wy de transaksje ferwurking. Brûkers kinne keapje in bepaald produkt op 'e side en meidwaan oan in priisfraach. Nei sokke oankeapen ferwurkje wy in grutte hoemannichte gegevens, benammen yn it wykein en op feestdagen. Foar fergeliking, as op gewoane dagen it oantal oankeapen earne tusken 1,5-2 miljoen is, dan op feestdagen kin it figuer 53 miljoen berikke.
Tagelyk moatte de gegevens yn 'e koartst mooglike tiid ferwurke wurde - brûkers wolle net in pear dagen wachtsje op it resultaat. D'r is gjin manier om sokke deadlines te berikken fia Postgres - wy krigen faak slûzen, en wylst wy alle oanfragen ferwurke, koene brûkers net kontrolearje oft se prizen krigen of net. Dit is net heul noflik foar bedriuw, dat wy hawwe de ferwurking ferpleatst nei Elasticsearch.
Periodisiteit
No binne de fernijings konfigureare op evenemint-basearre, neffens de folgjende betingsten:
- Ferkeap punten. Sadree't wy gegevens ûntfange fan in eksterne boarne, begjinne wy fuortendaliks de fernijing.
- Nijs. Sadree't der nijs op 'e side wurdt bewurke, wurdt it automatysk nei Elastic stjoerd.
Hjir wer is it wurdich te neamen de foardielen fan Elastic. Yn Postgres, as jo in fersyk ferstjoere, moatte jo wachtsje oant it alle records earlik ferwurket. Jo kinne stjoere 10 records nei Elastic en begjinne te wurkjen fuortendaliks, sûnder te wachtsjen foar de records wurde ferdield oer alle Shards. Fansels kinne guon Shard of Replica de gegevens net direkt sjen, mar alles sil heul gau beskikber wêze.
Yntegraasje metoaden
D'r binne 2 manieren om te yntegrearjen mei Elastic:
- Troch in lânseigen klant oer TCP. De lânseigen bestjoerder stjert stadichoan út: it wurdt net mear stipe, it hat in heul ûngemaklike syntaksis. Dêrom brûke wy it praktysk net en besykje it folslein te ferlitten.
- Troch in HTTP-ynterface dy't sawol JSON-oanfragen as Lucene-syntaksis kin brûke. De lêste is in tekstmotor dy't Elastic brûkt. Yn dizze ferzje krije wy de mooglikheid om te batchjen fia JSON-oanfragen oer HTTP. Dit is de opsje dy't wy besykje te brûken.
Mei tank oan de HTTP-ynterface kinne wy biblioteken brûke dy't in asynchrone ymplemintaasje fan 'e HTTP-kliïnt leverje. Wy kinne profitearje fan Batch en de asynchrone API, wat resulteart yn hege prestaasjes, dy't in protte holpen yn 'e dagen fan' e grutte promoasje (mear oer dat hjirûnder)
Guon sifers foar fergeliking:
- Bewarje Postgres-bounty-brûkers yn 20 diskusjes sûnder groepearring: 460713 records yn 42 sekonden
- Elastysk + reaktive kliïnt foar 10 threads + batch foar 1000 eleminten: 596749 records yn 11 sekonden
- Elastysk + reaktive kliïnt foar 10 threads + batch foar 1000 eleminten: 23801684 ynstjoerings yn 4 minuten
No hawwe wy in HTTP-fersykbehearder skreaun dy't JSON bouwt as Batch / net Batch en stjoert it fia elke HTTP-kliïnt, nettsjinsteande de bibleteek. Jo kinne ek kieze om fersiken syngroan of asynchronysk te ferstjoeren.
Yn guon yntegraasjes brûke wy noch de offisjele ferfierklant, mar dit is gewoan in kwestje fan 'e folgjende refactoring. Yn dit gefal wurdt in oanpaste klant boud op basis fan Spring WebClient brûkt foar ferwurking.
grutte promoasje
Ien kear yn 't jier hâldt it projekt in grutte promoasje foar brûkers - dit is deselde Highload, om't wy op dit stuit wurkje mei tsientallen miljoenen brûkers tagelyk.
Meastal komme pieken fan loads yn 'e fakânsje, mar dizze promoasje is op in folslein oar nivo. It jier foar it lêste, op 'e dei fan' e promoasje, ferkochten wy 27 ienheden fan guod. De gegevens waarden mear as in healoere ferwurke, wat soarge foar oerlêst foar brûkers. Brûkers krigen prizen foar dielname, mar it waard dúdlik dat it proses fersneld wurde moast.
Oan it begjin fan 2019 hawwe wy besletten dat wy ElasticSearch nedich wiene. Foar in hiel jier organisearre wy de ferwurking fan 'e ûntfongen gegevens yn Elastic en har útjefte yn' e api fan 'e mobile applikaasje en webside. As gefolch, it folgjende jier tidens de kampanje, wy ferwurke 15 ynstjoerings yn 131 minuten.
Om't wy in protte minsken hawwe dy't guod keapje wolle en meidwaan wolle oan it lotsjen fan prizen yn promoasjes, is dit in tydlike maatregel. No stjoere wy aktuele ynformaasje nei Elastic, mar yn 'e takomst binne wy fan plan om argivearre ynformaasje foar de ôfrûne moannen oer te bringen nei Postgres as permaninte opslach. Om de elastyske yndeks net te blokkearjen, dy't ek syn beheiningen hat.
Konklúzje / Konklúzjes
Op it stuit hawwe wy alle tsjinsten dy't wy woenen oerbrocht nei Elastic en hawwe dit foar no ûnderbrutsen. No bouwe wy in yndeks yn Elastic boppe op 'e wichtichste persistente opslach yn Postgres, dy't de brûkerslading oernimt.
Yn 'e takomst binne wy fan plan om tsjinsten oer te dragen as wy begripe dat it gegevensfersyk te ferskaat wurdt en wurdt socht nei in ûnbeheind oantal kolommen. Dit is gjin taak mear foar Postgres.
As wy folsleine-tekst sykje yn funksjonaliteit nedich hawwe of as wy in protte ferskillende sykkritearia hawwe, dan witte wy al dat dit oerset wurde moat yn Elastic.
⌘⌘⌘
Tank foar it lêzen. As jo bedriuw ek ElasticSearch brûkt en syn eigen ymplemintaasjegefallen hat, fertel it ús dan. It sil nijsgjirrich wêze om te witten hoe't oaren binne 🙂
Boarne: www.habr.com