Tere, Habr! Minu nimi on Maxim Vasiliev, töötan FINCHis analüütiku ja projektijuhina. Täna tahaksin teile rääkida, kuidas saime ElasticSearchi abil töödelda 15 minutiga 6 miljonit päringut ja optimeerida ühe meie kliendi saidi igapäevast koormust. Kahjuks peame ilma nimedeta hakkama saama, kuna meil on NDA, siis loodame, et artikli sisu sellest ei kannata. Lähme.
Kuidas projekt töötab
Oma taustaprogrammis loome teenuseid, mis tagavad meie kliendi veebisaitide ja mobiilirakenduse funktsionaalsuse. Üldist struktuuri saab näha diagrammil:
Töö käigus töötleme suurel hulgal tehinguid: oste, makseid, tehinguid kasutajasaldodega, mille kohta salvestame palju logisid, samuti impordime ja ekspordime neid andmeid välistesse süsteemidesse.
On ka pöördprotsesse, kui saame kliendilt andmeid ja edastame need kasutajale. Lisaks on olemas ka protsessid maksete ja boonusprogrammidega töötamiseks.
Lühike taust
Algselt kasutasime PostgreSQL-i ainsa andmesalvestusena. Selle eelised on DBMS-i jaoks standardsed: tehingute olemasolu, välja töötatud andmeotsingu keel, lai valik tööriistu integreerimiseks; koos hea jõudlusega rahuldas meie vajadusi üsna pikka aega.
Postgresse salvestasime absoluutselt kõik andmed: tehingutest uudisteni. Kuid kasutajate arv kasvas ja koos sellega ka päringute arv.
Et aru saada, oli 2017. aastal aastane seansside arv ainuüksi lauaarvutisaidil 131 miljonit. 2018. aastal - 125 miljonit. 2019. aastal jälle 130 miljonit. Lisage saidi ja mobiilirakenduse mobiiliversioonist veel 100-200 miljonit ning teie saab tohutult palju taotlusi.
Projekti kasvades ei suutnud Postgres enam koormusega toime tulla, me ei suutnud sammu pidada – ilmus suur hulk erinevaid päringuid, mille jaoks ei õnnestunud piisaval hulgal indekseid luua.
Mõistsime, et on vaja teisi andmesalve, mis vastaksid meie vajadustele ja võtaksid PostgreSQL-i koormuse maha. Võimalikeks valikuteks peeti Elasticsearchi ja MongoDB-d. Viimane kaotas järgmiste punktidega:
- Aeglane indekseerimiskiirus, kuna indeksites sisalduvate andmete maht kasvab. Elasticu puhul ei sõltu kiirus andmemahust.
- Täistekstiotsing puudub
Seega valisime endale Elasticu ja valmistusime üleminekuks.
Lülituge elastsele
1. Alustasime üleminekut müügikoha otsinguteenusega. Meie kliendil on kokku umbes 70 000 müügikohta ning samal ajal on veebilehel ja rakenduses vaja mitut tüüpi otsingut:
- Tekstiotsing paikkonna nime järgi
- Geootsing antud raadiuses teatud punktist. Näiteks kui kasutaja soovib näha, millised müügikohad on tema kodule kõige lähemal.
- Otsige etteantud ruudu järgi – kasutaja joonistab kaardil välja ruudu ja talle näidatakse kõiki punkte selles raadiuses.
- Otsige lisafiltrite järgi. Müügikohad erinevad üksteisest sortimendi poolest
Organisatsioonist rääkides on meil Postgresis olemas andmeallikas nii kaardi kui ka uudiste jaoks ning Elasticus teeme Snapshotsi algandmetest. Fakt on see, et esialgu ei tulnud Postgres kõigi kriteeriumide otsimisega toime. Indekseid polnud mitte ainult palju, vaid need võisid ka kattuda, nii et Postgresi ajakava läks kaduma ega saanud aru, millist indeksit kasutada.
2. Järjekorras oli uudiste rubriik. Väljaanded ilmuvad saidile iga päev, et kasutaja ei eksiks infovoogudesse, andmed tuleb enne väljastamist sorteerida. See on see, mille jaoks otsing on mõeldud: saidil saate otsida teksti vaste järgi ja samal ajal ühendada täiendavaid filtreid, kuna need tehakse ka Elasticu kaudu.
3. Seejärel teisaldasime tehingute töötlemise. Kasutajad saavad saidilt osta konkreetse toote ja osaleda auhinnaloosis. Pärast selliseid oste töötleme suurt hulka andmeid, eriti nädalavahetustel ja pühadel. Võrdluseks, kui tavapäevadel on ostude arv kuskil 1,5-2 miljonit, siis pühadel võib see näitaja küündida 53 miljonini.
Samas tuleb andmeid töödelda minimaalse aja jooksul – kasutajatele ei meeldi tulemusi mitu päeva oodata. Postgresi kaudu pole selliseid tähtaegu võimalik saavutada – saime sageli blokeeringuid ja kõigi taotluste töötlemise ajal ei saanud kasutajad kontrollida, kas nad said auhindu või mitte. See ei ole äri jaoks eriti meeldiv, nii et kolisime töötlemise Elasticsearchi.
Perioodilisus
Nüüd on värskendused konfigureeritud sündmustepõhiselt vastavalt järgmistele tingimustele.
- Müügikohad. Niipea, kui saame andmeid välisest allikast, käivitame kohe värskenduse.
- Uudised. Niipea, kui saidil uudiseid muudetakse, saadetakse see automaatselt Elasticule.
Siinkohal tasub taas mainida Elasticu eeliseid. Postgresis peate päringu saatmisel ootama, kuni see kõiki kirjeid ausalt töötleb. Saate saata Elasticule 10 tuhat plaati ja asuda kohe tööle, ootamata, kuni plaadid kõigile Shardidele jaotatakse. Muidugi ei pruugi mõni Shard või Replica andmeid kohe näha, kuid varsti on kõik saadaval.
Integratsioonimeetodid
Elasticuga integreerimiseks on kaks võimalust:
- Native kliendi kaudu TCP kaudu. Omadraiver sureb järk-järgult välja: seda enam ei toetata ja selle süntaks on väga ebamugav. Seetõttu me seda praktiliselt ei kasuta ja proovime sellest täielikult loobuda.
- HTTP-liidese kaudu, milles saate kasutada nii JSON-i päringuid kui ka Lucene'i süntaksit. Viimane on tekstimootor, mida Elastic kasutab. Selle valiku korral saame HTTP kaudu JSON-päringuid pakkida. Seda võimalust püüame kasutada.
Tänu HTTP-liidesele saame kasutada teeke, mis pakuvad HTTP-kliendi asünkroonset rakendamist. Saame ära kasutada Batchi ja asünkroonse API eeliseid, mis lõppkokkuvõttes annab suure jõudluse, mis aitas suure kampaania päevadel palju (sellest lähemalt allpool)
Mõned numbrid võrdluseks:
- Kasutajate salvestamine, kes said Postgresis auhindu 20 lõimes ilma rühmitusteta: 460713 kirjet 42 sekundiga
- Elastne + reaktiivne klient 10 lõime jaoks + partii 1000 elemendi jaoks: 596749 kirjet 11 sekundiga
- Elastne + reaktiivne klient 10 lõime jaoks + partii 1000 elemendi jaoks: 23801684 kirjet 4 minutiga
Nüüd oleme kirjutanud HTTP päringuhalduri, mis loob JSON-i partiidena/mittepartiina ja saadab selle mis tahes HTTP-kliendi kaudu, sõltumata teegist. Samuti saate valida, kas saata päringuid sünkroonselt või asünkroonselt.
Mõne integratsiooni puhul kasutame endiselt ametlikku transpordiklienti, kuid see on vaid kohese ümbertöötamise küsimus. Sel juhul kasutatakse töötlemiseks oma klienti, mis on ehitatud Spring WebClienti baasil.
Suur edutamine
Kord aastas korraldab projekt kasutajatele suure reklaami - see on sama Highload, kuna praegu töötame samaaegselt kümnete miljonite kasutajatega.
Tavaliselt toimuvad tippkoormused pühade ajal, kuid see pakkumine on hoopis teisel tasemel. Üle-eelmisel aastal müüsime kampaania päeval 27 580 890 ühikut kaupa. Andmete töötlemine võttis aega üle poole tunni, mis tekitas kasutajatele ebamugavusi. Kasutajad said osalemise eest auhindu, kuid selgus, et protsessi tuleb kiirendada.
2019. aasta alguses otsustasime, et ElasticSearchi on vaja. Terve aasta korraldasime Elasticus saadud andmete töötlemist ja väljastamist mobiilirakenduse ja veebilehe API-sse. Selle tulemusena töötlesime järgmisel aastal reklaamimise ajal 15 131 783 kirjet 6 minutiga.
Kuna meil on palju inimesi, kes soovivad meie kampaaniates toodet osta ja loosimises osaleda, on see ajutine meede. Nüüd saadame jooksva info Elasticule, kuid edaspidi plaanime viimaste kuude arhiveeritud info püsivalt Postgresse üle kanda. Et mitte ummistada Elastic indeksit, millel on ka omad piirangud.
Järeldus/järeldused
Hetkel oleme kõik teenused, mida soovisime, Elasticule üle andnud ja praeguseks peatanud. Nüüd loome Elasticus indeksi Postgresi peamise püsiva salvestusruumi peale, mis võtab enda peale kasutaja koormuse.
Edaspidi plaanime teenuseid üle kanda, kui saame aru, et andmepäring muutub liiga mitmekesiseks ja seda otsitakse piiramatul hulgal veerge. See pole enam Postgresi ülesanne.
Kui vajame funktsioonis täistekstiotsingut või kui meil on palju erinevaid otsingukriteeriume, siis teame juba, et see tuleb tõlkida Elasticusse.
⌘⌘⌘
Täname lugemise eest. Kui teie ettevõte kasutab ka ElasticSearchi ja tal on oma rakendusjuhtumid, andke meile teada. Oleks huvitav teada, kuidas teistel läheb :)
Allikas: www.habr.com