🥇Highload-projekti koormuse optimeerimine ElasticSearch'i abil

Tere, Habr! Minu nimi on Maksim Vasiljev, olen analüütik ja projektijuht ettevõttes FINCH. Täna tahaksin rääkida, kuidas suudame ElasticSearchi abil töödelda 15 miljonit päringut kuue minutiga ning optimeerida igapäevase koormuse ühele meie kliendi veebilehtedest. Kahjuks peame olude tõttu jääma nimedeta, kuna meil on non-disclosure agreement (NDA), loodame, et artikli sisu sellest ei kannata. Alustame.

Kuidas projekt on korraldatud

Meie tagaplaanil loome teenuseid, mis tagavad meie kliendi veebisaitide ja mobiilirakenduse toimimise. Üldstruktuuri saab näha skeemilt:

Töö käigus töötleme suurt hulka tehinguid: ostud, väljamaksed, kasutajate saldooperatsioonid, mille kohta hoiame palju logisid, samuti impordime ja eksportime neid andmeid välistesse süsteemidesse.

Samuti toimuvad vastupidised protsessid, kus saame andmeid kliendilt ja edastame need kasutajatele. Lisaks on olemas ka maksete ja boonuste programmidega seotud protsessid.

Lühike taustalugu

Algul kasutati ainsana andmete salvestamiseks PostgreSQL-i. Selle standardsete andmebaaside eeliste hulka kuuluvad tehingute olemasolu, arendatud andmevaliku keel ja lai integreerimistööriistade komplekt; koos hea tootlikkusega rahuldasid need meie vajadusi pikemat aega.

Me hoidsime Postgresis absoluutselt kõiki andmeid: tehingutest kuni uudisteni. Kuid kasutajate arv kasvas, samas suurenenud ka päringute arv.

Kuna mõista, oli 2017. aastal ainult lauaveebisaidil aastane seansside arv 131 miljonit. 2018. aastal 125 miljonit. 2019. aastal taas 130 miljonit. Lisage sinna veel 100–200 miljonit mobiiliversiooni ja mobiilirakenduse seansse, ja te saate tohutu päringute arvu.

Projekti kasvu tõttu ei suudnud Postgres enam koormusega hakkama saada, me ei jõudnud järgi — ilmnes palju erinevaid päringute, mille jaoks me ei suutnud luua piisavalt indekseid.

Me mõistsime, et on vajadus teiste andmesalvestuslahenduste järele, mis suudaksid rahuldada meie vajadusi ja vähendada PostgreSQL-i koormust. Vaatasime võimalike variantidena Elasticsearchi ja MongoDB-d. Viimane jäi alla järgmistes punktides:

Aeglane indekseerimise kiirus andmemahu kasvades. Elasticu kiirus ei sõltu andmemahust.
Puudub täisteksti otsing

Nii valisime endale Elasticu ja valmistusime üleminekuks.

Üleminek Elasticule

1. Alustasime üleminekut müügipunktide otsinguteenusest. Meie kliendil on kokku umbes 70 000 müügikohta ning nende hulgas on vajalik mitu tüüpi otsingut veebilehel ja rakenduses:

Tekstipõhine otsing asula nime järgi
Geotöötlus antud raadiuses mingist punktist. Näiteks, kui kasutaja soovib näha, millised müügikohad on tema kodust lähimad.
Otsing antud ruudu piires – kasutaja joonistab kaardil ruudu ja talle näidatakse kõiki punkte selles raadiuses.
Otsing täiendavate filtrite põhjal. Müügikohad erinevad üksteisest oma tootevalikute poolest.

Organisatsiooni kontekstis asub meil Postgres'is andmeallikas nii kaardi kui uudiste jaoks ning Elasticis tehakse originaalsetest andmetest Snapshot'e. Alguses ei tule Postgres kõigi kriteeriumide otsinguga toime. Lisaks oli palju indekseid, mis võisid omavahel kattuda, mis tõttu jäi Postgres'i planeerija segadusse ja ei mõistnud, millist indeksit kasutada.

Järgmine oligi uudiste osa. Igal päeval ilmuvad veebilehele avaldused ning et kasutajad ei kaotaks teabevoos suunda, on oluline andmete sorteerimine enne esitamist. Selle jaoks on vajalik otsing: veebilehel saab otsida tekstipõhiste vasteid ja samas rakendada täiendavaid filtreid, kuna need on samuti tehtud läbi Elastic'i.

Seejärel korraldasime tehingute töötlemise ümber. Kasutajad saavad veebilehelt osta teatud kaupu ja osaleda auhindade loosimises. Pärast selliseid oste töötleme me suures mahus andmeid, eriti nädalavahetusel ja pühade ajal. Võrdluseks, kui tavapäevadel on ostude arv umbes 1,5-2 miljonit, siis pühade ajal võib see number ulatuda 53 miljoni juurde.

Kuna andmed tuleb töötada läbi võimalikult lühikese ajaga — kasutajad ei armasta tulemusi mitu päeva oodata. Postgres puhul ei ole selliseid tähtaegu võimalik saavutada — me saime sageli lukustusi, ja seni kuni me töötlesime kõiki päringuid, ei saanud kasutajad kontrollida, kas nad said auhindu või mitte. See ei ole äri jaoks hea, seega tõstsime töötluse Elasticsearchi.

Perioodilisus

Praegu on uuenduste seadistus sündmustel põhinev, järgmiste tingimustega:

Müügikohtadega. Niipea kui saame andmeid välisest allikast, käivitame kohe uuenduse.
Uudised. Kui veebilehel muudetakse mõnda uudist, saadetakse see automaatselt Elastic'usse.

Siin tasub veel kord rääkida Elasticu eelistest. Postgres'is peab päringu saatmisel ootama, kuni see õiglaselt töötleb kõik kirjed. Elastic's saab saata 10 tuhat kirjet ja kohe alustada tööd, ootamata, kuni kirjed kõigile Shard'idele jaotatakse. Muidugi võib mõni Shard või Replica andmeid kohe mitte näha, kuid varsti on kõik saadaval.

Integreerimise viisid

Elastic'uga integreerimiseks on 2 võimalust:

TCP-natiivklienti kaudu. Natiivne draiver kaob järk-järgult: seda enam ei toetata ja selle süntaks on väga ebamugav. Seetõttu kasutame seda praktiliselt mitte ja püüame sellest täielikult loobuda.
HTTP-liidese kaudu, milles saab kasutada nii JSON-päringuid kui ka Lucene’i süntaksit. Viimane on tekstimootor, mida kasutab Elastic. Sellisel variandil saame Batch võimaluse läbi JSON-päringute HTTP kaudu. Just seda varianti püüame kasutada.

HTTP-liidese tõttu saame kasutada raamatukogusid, mis pakuvad asünkroonset HTTP-kliendi rakendust. Saame kasutada Batch'i ja asünkroonse API eeliseid, mis lõpuks annab kõrge jõudluse, mis aitas väga suurte kampaaniate päevadel (sellest allpool)

Mõned numbrid võrdlemiseks:

Kasutajate salvestamine, kes said auhindu Postgresis 20 voos ilma grupeerimise: 460713 kirjet 42 sekundi jooksul
Elastic + reaktiivne klient 10 voo + partiid 1000 elementi: 596749 kirjet 11 sekundi jooksul
Elastic + reaktiivne klient 10 voo + partiid 1000 elementi: 23801684 kirjet 4 minuti jooksul

Praegu oleme kirjutanud HTTP päringute halduri, mis koostab JSON-i, nagu Batch/Batch mitte, ja saadab selle läbi mistahes HTTP kliendi, sõltumata raamatukogust. Samuti on võimalik valida, kas saata päringud sünkroonselt või asünkroonselt.

Mõningates integratsioonides kasutame me endiselt ametlikku transportkliendi, kuid see on vaid lähitulevikus toimuva refaktoreerimise küsimus. Sellegipoolest kasutatakse töötlemiseks meie enda klienti, mis on üles ehitatud Spring WebClient'i baasil.

Suur kampaania

Kord aastas toimub projektis suur kampaania kasutajatele — see on see Hiilakoormus, kuna sel ajal töötame samaaegselt kümnete miljonite kasutajatega.

Tavaliselt esinevad koormuse tipud pühade ajal, kuid see kampaania on hoopis teisel tasemel. Eelmisel aastal, kampaania päeval, müüsime 27 580 890 kaupa. Andmete töötlemine kests viis üle poole tunni, mis tekitas kasutajate seas ebamugavust. Kasutajad said osalemise eest auhindu, kuid selgeks sai, et protsessi tuleb kiirendada.

2019. aasta alguses otsustasime, et vajame ElasticSearch'i. Kogu aasta korraldasime saadud andmete töötlemise Elasticus ja nende edastamise mobiilirakenduse ja veebisaidi API-le. Lõpuks järgmisel aastal kampaania ajal töötlesime 15 131 783 kirjet 6 minuti jooksul.

Kuna meil on palju soovijaid osta kaupu ja osaleda loosimistel, on see ajutine lahendus. Praegu saadame värsket teavet Elasticusse, kuid tulevikus plaanime arhiivida eelmiste kuude andmed Postgres'i, kui püsivasse salvestusse. Et mitte ummistada Elasticu indeksi, millel on samuti oma piirangud.

Kokkuvõtted/järeldused

Käesoleval hetkel oleme Elasticusse viinud kõik teenused, mida soovisime, ja nüüd oleme teinud pausi. Praegu ehitame põhikindla salvestuse peale Postgres'is indeksit Elasticus, mis võtab enda alla kasutajate koormuse.

Tulevikus plaanime teenuste üleviimist, kui mõistame, et andmete päringud muutuvad liiga mitmekesisteks ja otsitakse piiramatul hulgal veerge. See on juba ülesanne, mis ei sobi Postgres'ile.

Kui meil on vaja täisteksti otsingut või kui meil on palju erinevaid otsingukriteeriume, siis teame juba, et seda tuleb tõlkida Elasticusse.

⌘⌘⌘

Aitäh, et lugesite. Kui teie ettevõttes kasutatakse samuti ElasticSearch'i ja teil on oma rakenduste näiteid, siis jagage neid. Oleks huvitav teada, kuidas teised seda teevad 🙂

Allikas: habr.com