Highload-projekti koormuse optimeerimine ElasticSearch'i abil

Tere, Habr! Minu nimi on Maksim Vasiljev, töötan analüütiku ja projektijuhina FINCHis. Täna tahan rääkida, kuidas me ElasticSearch'i abil suutsime töödelda 15 miljonit päringut kuue minutiga ja optimeerida iga päev koormust meie kliendi veebisaidil. Kahjuks peame hakkama ilma nimedeta, kuna meil on NDA, loodan, et artikli sisu sellest ei kannata. alustame.

Kuidas projekt on korraldatud

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

Töötamise käigus töötleme suurt hulka tehinguid: oste, väljamakseid, kasutajate saldooperatsioone, mille kohta säilitame palju logisid, samuti impordime ja ekspordime neid andmeid välistesse süsteemidesse.

Samuti toimuvad tagasiprotsessid, kui saame andmeid kliendilt ja edastame need kasutajatele. Lisaks on veel maksete ja boonuste programmidega seonduvad protsessid.

Lühikene eelajaloo

Alguses kasutasime ainulaadse andmete salvestusena PostgreSQLi. Selle standardseid andmebaaside eeliseid: tehingud, arenenud andmete päringukeel, lai integreerimise tööriistade kogum; koos hea jõudlusega rahuldas meie vajadusi piisavalt kaua.

Säilitasime Postgresis absoluutselt kõik andmed: tehingutest kuni uudisteni. Kuid kasutajate arv kasvas ja koos sellega ka päringute arv.

Arusaamiseks, aastane seansside arv 2017. aastal ainult lauaarvutite veebisaidil - 131 miljonit. 2018 - 125 miljonit. 2019, jälle 130 miljonit. Lisage sinna veel 100-200 miljonit mobiiliversiooni ja mobiilirakenduse päringutest ning saate tohutu hulga päringuid.

Kuna projekt kasvas, ei suutnud Postgres koormusega enam toime tulla, me jäime maha - ilmus suur hulk erinevaid päringuid, mille jaoks ei suutnud me piisavalt indekseid luua.

Mõistsime, et on vajadus teiste andmete salvestamise lahenduste järele, mis tagaksid meie vajadused ja leevendaksid PostgreSQL-i koormust. Võimalike variantidena kaalume Elasticsearch'i ja MongoDB-d. Viimane kaotas järgmistes punktides:

1. Andmete indekseerimise aeglustumine koos indeksi mahu kasvuga. Elasticis kiirus ei sõltu andmete mahust.
2. Puudub täisteksti otsing

Nii valisime endale Elasticu ja valmistusime üleminekuks.

Üleminek Elasticule

1. Alustasime üleminekut müügikohtade otsinguteenusele. Meie kliendil on kokku umbes 70 000 müügikohta ja samas on veebilehe ja rakenduse jaoks vajalikud mitmed otsingu tüübid:

• Tekstiotsing asula nime järgi
• Geotsing määratud raadiuses mõnest punktist. Näiteks, kui kasutaja soovib näha, millised müügikohad on tema kodule kõige lähemal.
• Otsing määratud ruudu järgi – kasutaja joonistab kaardile ruudu ja talle näidatakse kõiki punkte selle raadiuse sees.
• Otsing täiendavate filtrite järgi. Müügikohad erinevad omavahel tootevaliku poolest.

Kui rääkida organiseerimisest, siis Postgresis on meil andmeallikas nii kaardi kui ka uudiste jaoks, ja Elasticis tehakse Snapshoot originaalandmetest. Asi on selles, et algselt Postgres ei suudnud kõigi kriteeriumide järgi otsingut teha. Küll oli palju indekseid, mis võisid ka üksteisega kattuda, seetõttu kadus Postgresi planeerija ära ja ei saanud aru, millist indeksit kasutada.

2. Järgmine oli uudiste rubriik. Veebilehel ilmuvad iga päev publikatsioonid, et kasutaja ei eksiks informatsiooni tulvas, tuleb andmed enne esitlust sorteerida. Selleks ongi vaja otsingut: veebilehel saab otsida tekstiühenduse järgi ning samal ajal aktiveerida täiendavad filtrid, kuna need on samuti tehtud läbi Elasticu.

3. Siis viisime üle tehingute töötlemise. Kasutajad saavad veebilehe kaudu osta teatud kaupu ja osaleda auhindade loosimises. Pärast selliseid oste töötleme me suurt hulka andmeid, eriti nädalavahetustel ja pühal. Kui võrrelda, siis tavapäevadel on ostude arv umbes 1,5-2 miljonit, siis pühal võib number ulatuda 53 miljoni juurde.

Samuti tuleb andmeid töödelda minimaalse aja jooksul - kasutajad ei tunne oodatud tulemusi mitu päeva. Postgresi kaudu selliseid tähtaegu kuidagi ei saavutada - me saime tihti lukustusi ja kuni me töötlesime kõiki päringuid, ei saanud kasutajad kontrollida, kas nad said auhindu või mitte. See ei ole äri jaoks mugav, seetõttu viisime töötlemise Elasticsearchi.

Sagedus

Praegu on värskendused seadistatud sündmuspõhiselt järgmiste tingimuste alusel:

1. Müügikohad. Niikaua kui me saame andmeid välistest allikatest, käivitame me kohe värskenduse.
2. Uudised. Kui veebisaidil redigeeritakse mõnda uudist, saadetakse see automaatselt Elasticusse.

Siin tasub veel kord mainida Elasticu eeliseid. Postgres'i puhul tuleb päringu esitamisel oodata, kuni see kõiki kirjeid õiglaselt töötleb. Elasticus saab saata 10 tuhat kirjet ja alustada kohe töötamist, oodates, kuni kirjed kõikide shardide vahel jaotuvad. Muidugi võib mõni shardi või koopiamoodul andmeid kohe mitte näha, kuid väga varsti on kõik saadaval.

Integratsiooni viisid

Elasticusse integreerimiseks on kaks võimalust:

1. Kasutades natiivset kliendi TCP kaudu. Natiivne draiver on järk-järgult kadumas: seda ei toetata enam, selle süntaks on väga ebamugav. Seetõttu ei kasuta me seda praktiliselt ja püüame sellest täielikult loobuda.
2. HTTP liidese kaudu, kus saab kasutada nii JSON päringuid kui ka Lucene süntaksit. Viimane on tekstimootor, mida Elastic kasutab. Sellisel juhul saame Batch võimaluse kaudu HTTP kaudu JSON-päringute abil. Just seda varianti püüame kasutada.

Tänu HTTP liidesele saame kasutada teeke, mis pakuvad asünkroonset HTTP kliendi teostust. Me saame kasutada Batch ja asünkroonse API eelist, mis lõpuks annab kõrge tootlikkuse, mis aitas oluliselt suure aktsiooni päevadel (sellest allpool)

Veidi numbreid võrdlemiseks:

• Postgres'is kasutajate, kes said auhindu, salvestamine 20 lõimes ilma grupeerimisteta: 460713 kirjet 42 sekundi jooksul
• Elastic + reaktiivne klient 10 lõime + batch 1000 elementi: 596749 kirjet 11 sekundiga
• Elastic + reaktiivne klient 10 lõime + batch 1000 elementi: 23801684 kirjet 4 minuti jooksul

Praegu oleme kirjutanud HTTP päringute halduri, mis koostab JSON-i, olgu tegemist Batch'i/ne Batche'iga ja saadab selle igasuguse HTTP kliendi kaudu sõltumata teegist. Samuti saab valida, kas saata päringud sünkroonselt või asünkroonselt.

Mõnedes integreerimistes kasutame endiselt ametlikku transport klienti, kuid see on vaid küsimus lähituleviku refaktorimisest. Samuti kasutatakse töötlemiseks enda klienti, mis on üles ehitatud Spring WebClienti baasil.

Suur aktsioon

Kord iga aastas toimub projektis suur kampaania kasutajatele — see on see tõeline Highload, kuna sel ajal töötame korraga kümnete miljonite kasutajatega.

Tavaliselt on koormuse tipud pühade päevadel, kuid see kampaania on hoopis teise taseme. Eelmise aasta kampaaniapäeval müüsime 27 580 890 toodet. Andmed töötleti üle poole tunni, mis tekitas kasutajatele ebamugavust. Kasutajad said osalemise eest auhindu, kuid oli selge, et protsessi tuleb kiirendada.

2019. aasta alguses otsustasime, et vajame ElasticSearchi. Kogu aasta korraldasime saadud andmete töötlemist Elasticus ja nende väljastamist mobiilirakenduse ja veebisaidi API kaudu. Lõpuks järgmise aasta kampaania ajal töötlesime 15 131 783 kirjeid 6 minuti jooksul.

Kuna soovijaid osta tooteid ja osaleda auhindade loosimistes on meil väga palju, on see ajutine lahendus. Praegu saadame asjakohast teavet Elasticusse, kuid tulevikus plaanime arhiiviandmed eelmiste kuude kohta viia Postgresse, kui püsivat ladustamist. Et mitte ummistada Elasticu indeksit, millel on samuti oma piirangud.

Järeldus/ülevaated

Praeguseks oleme viinud Elasticusse kõik teenused, mida soovisime, ja oleme sellel hetkel teinud pausi. Praegu ehitame põhjaliku püsiva ladustamise kohal Postgress Elasticus indeksi, mis talub kasutaja koormust.

Tulevikus plaanime teenuste üleviimist, kui saame aru, et andmepäringud muutuvad liiga mitmekesisteks ja otsitakse piiramatul hulgal veerge. See on juba ülesanne mitte Postgrese jaoks.

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

⌘⌘⌘

Aitäh, et lugesite. Kui teie ettevõttes kasutatakse samuti ElasticSearchi ja teil on oma rakenduse juhtumeid, siis jagage seda. Huvitav oleks teada, kuidas teised seda teevad 🙂

Allikas: habr.com