Hej Habr! Moje ime je Maxim Vasiliev, delam kot analitik in vodja projektov pri FINCH. Danes bi vam rad povedal, kako nam je z ElasticSearch uspelo obdelati 15 milijonov zahtevkov v 6 minutah in optimizirati dnevno obremenitev spletnega mesta ene od naših strank. Na žalost bomo morali brez imen, ker imamo NDA, upamo, da zaradi tega ne bo trpela vsebina članka. Pojdimo.
Kako projekt deluje
Na našem zaledju ustvarjamo storitve, ki zagotavljajo delovanje spletnih mest in mobilnih aplikacij naših strank. Splošno strukturo lahko vidite na diagramu:
V procesu dela obdelamo veliko število transakcij: nakupe, plačila, operacije z uporabniškimi stanji, za katere hranimo veliko dnevnikov, ter uvoz in izvoz teh podatkov v zunanje sisteme.
Obstajajo tudi obratni procesi, ko prejmemo podatke od naročnika in jih prenesemo uporabniku. Poleg tega še vedno obstajajo postopki za delo s plačili in bonus programi.
Kratko ozadje
Na začetku smo kot edino shrambo podatkov uporabljali PostgreSQL. Njegove standardne prednosti za DBMS: prisotnost transakcij, razvit jezik vzorčenja podatkov, širok nabor orodij za integracijo; v kombinaciji z dobro zmogljivostjo je zadovoljil naše potrebe za precej dolgo časa.
V Postgres smo hranili čisto vse podatke: od transakcij do novic. Toda število uporabnikov je raslo, s tem pa tudi število povpraševanj.
Za razumevanje je letno število sej v letu 2017 samo na namiznem spletnem mestu 131 milijonov Leta 2018 - 125 milijonov Leta 2019 spet 130 milijonov Dodajte še 100-200 milijonov iz mobilne različice spletnega mesta in mobilne aplikacije in bo dobil ogromno prošenj.
Z rastjo projekta se je Postgres prenehal spopadati z obremenitvijo, nismo imeli časa - pojavilo se je veliko število različnih poizvedb, za katere nismo mogli ustvariti zadostnega števila indeksov.
Razumeli smo, da obstaja potreba po drugih shrambah podatkov, ki bi zadovoljile naše potrebe in razbremenile PostgreSQL. Elasticsearch in MongoDB sta bila obravnavana kot možni možnosti. Slednji je izgubil po naslednjih točkah:
- Počasna hitrost indeksiranja, ko se količina podatkov v indeksih povečuje. Pri Elastic hitrost ni odvisna od količine podatkov.
- Ni iskanja po celotnem besedilu
Tako smo izbrali Elastic zase in se pripravili na prehod.
Prehod na elastiko
1. Začeli smo prehod s storitve iskanja prodajnih mest. Naša stranka ima skupaj približno 70 prodajnih mest, kar zahteva več vrst iskanj na strani in v aplikaciji:
- Iskanje besedila po imenu mesta
- Geografsko iskanje v danem radiju od neke točke. Na primer, če želi uporabnik videti, katera prodajna mesta so najbližje njegovemu domu.
- Iskanje po danem kvadratu - uporabnik na zemljevidu nariše kvadrat in prikažejo se mu vse točke v tem radiju.
- Iskanje po dodatnih filtrih. Prodajna mesta se med seboj razlikujejo po asortimanu
Če govorimo o organizaciji, potem imamo v Postgresu vir podatkov tako za zemljevid kot za novice, v Elastic pa so posnetki vzeti iz izvirnih podatkov. Dejstvo je, da Postgres na začetku ni bil kos iskanju po vseh kriterijih. Ne samo, da je bilo veliko indeksov, lahko so se tudi prekrivali, zato se je razporejevalnik Postgres izgubil in ni razumel, kateri indeks naj uporabi.
2. Naslednja na vrsti je bila novica. Publikacije se na strani pojavljajo vsak dan, da se uporabnik ne izgubi v toku informacij, podatke je treba pred izdajo urediti. Temu je namenjeno iskanje: po strani lahko iščete po besedilnem ujemanju, hkrati pa priključite dodatne filtre, saj so tudi ti narejeni preko Elastic-a.
3. Nato smo prestavili obdelavo transakcij. Uporabniki lahko na strani kupijo določen izdelek in sodelujejo v nagradni igri. Po tovrstnih nakupih obdelamo veliko količino podatkov, predvsem ob vikendih in praznikih. Za primerjavo, če je ob običajnih dneh število nakupov nekje med 1,5-2 milijona, potem lahko ob praznikih številka doseže 53 milijonov.
Hkrati morajo biti podatki obdelani v najkrajšem možnem času - uporabniki ne marajo čakati na rezultat več dni. Preko Postgresa takšnih rokov ni mogoče doseči – pogosto smo prejemali zaklepe in med obdelavo vseh zahtevkov uporabniki niso mogli preveriti, ali so prejeli nagrade ali ne. To za posel ni preveč prijetno, zato smo obdelavo prestavili v Elasticsearch.
Periodičnost
Zdaj so posodobitve konfigurirane na podlagi dogodkov v skladu z naslednjimi pogoji:
- Prodajna mesta. Takoj ko prejmemo podatke iz zunanjega vira, takoj začnemo s posodobitvijo.
- Novice. Takoj, ko je katera koli novica urejena na spletnem mestu, se samodejno pošlje v Elastic.
Tudi tukaj je vredno omeniti prednosti Elastic. V Postgresu je treba pri pošiljanju zahteve počakati, da pošteno obdela vse zapise. V Elastic lahko pošljete 10 zapisov in takoj začnete delati, ne da bi čakali, da se zapisi porazdelijo po vseh Shardih. Seveda nekateri Shard ali Replica morda ne bodo videli podatkov takoj, vendar bo vse na voljo zelo kmalu.
Metode integracije
Obstajata dva načina za integracijo z Elastic:
- Prek izvornega odjemalca preko TCP. Domači gonilnik postopoma izumira: ni več podprt, ima zelo neprijetno sintakso. Zato ga praktično ne uporabljamo in ga poskušamo popolnoma opustiti.
- Prek vmesnika HTTP, ki lahko uporablja zahteve JSON in sintakso Lucene. Zadnji je besedilni mehanizem, ki uporablja Elastic. V tej različici imamo možnost paketnega pošiljanja zahtev JSON prek HTTP. To je možnost, ki jo poskušamo uporabiti.
Zahvaljujoč vmesniku HTTP lahko uporabljamo knjižnice, ki zagotavljajo asinhrono izvedbo odjemalca HTTP. Izkoristimo lahko Batch in asinhroni API, kar ima za posledico visoko zmogljivost, kar je zelo pomagalo v dneh velike promocije (več o tem spodaj)
Nekaj številk za primerjavo:
- Shranjevanje uporabnikov nagrade Postgres v 20 nitih brez združevanja: 460713 zapisov v 42 sekundah
- Elastični + reaktivni odjemalec za 10 niti + paket za 1000 elementov: 596749 zapisov v 11 sekundah
- Elastični + reaktivni odjemalec za 10 niti + serija za 1000 elementov: 23801684 vnosov v 4 minutah
Zdaj smo napisali upravitelja zahtev HTTP, ki gradi JSON kot paket/ne paket in ga pošlje prek katerega koli odjemalca HTTP, ne glede na knjižnico. Izberete lahko tudi sinhrono ali asinhrono pošiljanje zahtev.
Pri nekaterih integracijah še vedno uporabljamo uradnega transportnega odjemalca, vendar je to le stvar naslednjega refactoringa. V tem primeru se za obdelavo uporablja odjemalec po meri, zgrajen na podlagi Spring WebClient.
velika promocija
Enkrat letno projekt gosti veliko promocijo za uporabnike - to je isti Highload, saj v tem času delamo z več deset milijoni uporabnikov hkrati.
Običajno so največje obremenitve med prazniki, vendar je ta promocija na povsem drugi ravni. Predlani smo na dan promocije prodali 27 enot blaga. Podatke so obdelovali več kot pol ure, kar je uporabnikom povzročalo nevšečnosti. Uporabniki so prejeli nagrade za sodelovanje, vendar je postalo jasno, da je treba proces pospešiti.
V začetku leta 2019 smo se odločili, da potrebujemo ElasticSearch. Celo leto smo organizirali obdelavo prejetih podatkov v Elastic in njihovo izdajo v api mobilne aplikacije in spletne strani. Posledično smo naslednje leto med akcijo obdelali 15 vnosov v 131 minutah.
Ker imamo veliko ljudi, ki želijo kupiti blago in sodelovati pri žrebanju nagrad v akcijah, je to začasen ukrep. Zdaj pošiljamo ažurne podatke na Elastic, v prihodnosti pa načrtujemo prenos arhiviranih informacij za pretekle mesece na Postgres kot trajno shrambo. Da ne bi zamašili elastičnega indeksa, ki ima tudi svoje omejitve.
Zaključek/Sklepi
Trenutno smo vse storitve, ki smo jih želeli, prenesli na Elastic in smo pri tem zaenkrat zastali. Zdaj gradimo indeks v Elastic na vrhu glavnega trajnega pomnilnika v Postgresu, ki prevzame obremenitev uporabnika.
V prihodnosti načrtujemo prenos storitev, če razumemo, da zahteva za podatke postane preveč raznolika in se išče po neomejenem številu stolpcev. To ni več naloga za Postgres.
Če potrebujemo iskanje po celotnem besedilu v funkcionalnosti ali če imamo veliko različnih iskalnih kriterijev, potem že vemo, da je to treba prevesti v Elastic.
⌘⌘⌘
Hvala za branje. Če tudi vaše podjetje uporablja ElasticSearch in ima lastne primere implementacije, nam to povejte. Zanimivo bo izvedeti, kako so drugi 🙂
Vir: www.habr.com