Sveiki, Habr! Mano vardas Maksimas Vasiljevas, dirbu FINCH analitiku ir projektų vadovu. Šiandien noriu papasakoti, kaip naudodamiesi ElasticSearch sugebėjome apdoroti 15 milijonų užklausų per 6 minutes ir optimizuoti dienos apkrovą vieno iš mūsų klientų svetainėje. Deja, teks apsieiti be pavardžių, kadangi turime NDA, tikimės, kad straipsnio turinys nuo to nenukentės. Eime.
Kaip veikia projektas
Savo foninėje sistemoje kuriame paslaugas, užtikrinančias mūsų klientų svetainių ir mobiliųjų aplikacijų veikimą. Bendrą struktūrą galima pamatyti diagramoje:
Darbo metu apdorojame daugybę operacijų: pirkimų, mokėjimų, operacijų su vartotojų likučiais, kurioms saugome daug žurnalų, taip pat importuojame ir eksportuojame šiuos duomenis į išorines sistemas.
Taip pat yra atvirkštiniai procesai, kai gauname duomenis iš kliento ir perduodame juos vartotojui. Be to, vis dar yra darbo su mokėjimais ir premijų programomis procesai.
Trumpas fonas
Iš pradžių naudojome PostgreSQL kaip vienintelę duomenų saugyklą. Standartiniai DBVS privalumai: operacijų buvimas, sukurta duomenų atrankos kalba, platus integravimo įrankių asortimentas; kartu su geru našumu gana ilgą laiką tenkino mūsų poreikius.
„Postgres“ saugojome absoliučiai visus duomenis: nuo operacijų iki naujienų. Tačiau vartotojų skaičius augo, o kartu ir užklausų skaičius.
Kad suprastume, 2017 metais metinis seansų skaičius tik darbalaukio svetainėje yra 131 mln. gaus daug užklausų.
Augant projektui, Postgres nustojo susidoroti su apkrova, neturėjome laiko – atsirado daugybė įvairių užklausų, kurioms negalėjome sukurti pakankamai indeksų.
Supratome, kad reikia kitų duomenų saugyklų, kurios patenkintų mūsų poreikius ir pašalintų „PostgreSQL“ apkrovą. Elasticsearch ir MongoDB buvo svarstomos kaip galimos galimybės. Pastarieji pralaimėjo šiais taškais:
- Lėtas indeksavimo greitis, nes didėja duomenų kiekis indeksuose. Naudojant Elastic greitis nepriklauso nuo duomenų kiekio.
- Nėra viso teksto paieškos
Taigi patys pasirinkome Elastic ir ruošėmės perėjimui.
Perėjimas prie elastinės
1. Pradėjome perėjimą nuo pardavimo vietų paieškos paslaugos. Mūsų klientas iš viso turi apie 70 000 pardavimo vietų, todėl svetainėje ir programoje reikia atlikti kelių tipų paieškas:
- Teksto paieška pagal miesto pavadinimą
- Geografinė paieška tam tikru spinduliu iš tam tikro taško. Pavyzdžiui, jei vartotojas nori pamatyti, kurios pardavimo vietos yra arčiausiai jo namų.
- Ieškokite pagal nurodytą kvadratą – vartotojas žemėlapyje nupiešia kvadratą ir jam rodomi visi šio spindulio taškai.
- Ieškokite pagal papildomus filtrus. Prekybos vietos skiriasi viena nuo kitos asortimentu
Jei mes kalbame apie organizaciją, tada „Postgres“ turime duomenų šaltinį ir žemėlapiui, ir naujienoms, o Elastic Snapshots imami iš pirminių duomenų. Faktas yra tas, kad iš pradžių Postgres negalėjo susidoroti su paieška pagal visus kriterijus. Indeksų buvo ne tik daug, jie taip pat galėjo sutapti, todėl Postgres planuotojas pasimetė ir nesuprato, kurį indeksą naudoti.
2. Kitas eilėje buvo naujienų skyrius. Leidiniai svetainėje pasirodo kiekvieną dieną, kad vartotojas nepasimestų informacijos sraute, prieš išduodant duomenis reikia surūšiuoti. Tai ir yra paieška: galite ieškoti svetainėje pagal teksto atitiktį ir tuo pačiu prijungti papildomus filtrus, nes jie taip pat atliekami per Elastic.
3. Tada perkėlėme operacijos apdorojimą. Vartotojai gali nusipirkti tam tikrą produktą svetainėje ir dalyvauti prizų traukime. Po tokių pirkinių apdorojame didelį duomenų kiekį, ypač savaitgaliais ir švenčių dienomis. Palyginimui, jei paprastomis dienomis pirkimų skaičius siekia 1,5–2 mln., tai švenčių dienomis šis skaičius gali siekti 53 mln.
Tuo pačiu metu duomenys turi būti apdorojami per trumpiausią įmanomą laiką – vartotojai nemėgsta laukti rezultato kelias dienas. Per „Postgres“ tokių terminų pasiekti nepavyksta – dažnai gaudavome užraktus, o kol apdorodavome visas užklausas, vartotojai negalėjo patikrinti, ar gavo prizų, ar ne. Tai nėra labai malonu verslui, todėl apdorojimą perkėlėme į Elasticsearch.
Periodiškumas
Dabar naujinimai sukonfigūruoti pagal įvykius, atsižvelgiant į šias sąlygas:
- Pardavimo vietos. Kai tik gauname duomenis iš išorinio šaltinio, iškart pradedame atnaujinimą.
- Žinios. Kai tik svetainėje redaguojamos naujienos, jos automatiškai siunčiamos į Elastic.
Čia dar kartą verta paminėti Elastic privalumus. „Postgres“ siųsdami užklausą turite palaukti, kol ji sąžiningai apdoros visus įrašus. Galite nusiųsti 10 XNUMX įrašų į Elastic ir pradėti dirbti iš karto, nelaukdami, kol įrašai bus paskirstyti visoms Shards. Žinoma, kai kurie „Shard“ ar „Replica“ gali nematyti duomenų iš karto, tačiau viskas bus prieinama labai greitai.
Integravimo metodai
Yra 2 būdai, kaip integruoti su Elastic:
- Per vietinį klientą per TCP. Vietinė tvarkyklė pamažu nyksta: ji nebepalaikoma, jos sintaksė labai nepatogi. Todėl praktiškai nenaudojame ir stengiamės visiškai jo atsisakyti.
- Per HTTP sąsają, kuri gali naudoti ir JSON užklausas, ir Lucene sintaksę. Paskutinis yra teksto variklis, kuriame naudojamas Elastic. Šioje versijoje gauname galimybę paketuoti JSON užklausas per HTTP. Tai yra ta parinktis, kurią bandome naudoti.
HTTP sąsajos dėka galime naudoti bibliotekas, kurios užtikrina asinchroninį HTTP kliento įgyvendinimą. Galime pasinaudoti „Batch“ ir asinchronine API, kuri užtikrina didelį našumą, o tai labai padėjo didžiosios reklamos dienomis (daugiau apie tai žemiau)
Kai kurie skaičiai palyginimui:
- „Postgres Bounty“ naudotojų išsaugojimas 20 gijų be grupavimo: 460713 įrašų per 42 sekundes
- Elastinis + reaktyvus klientas 10 gijų + paketas 1000 elementų: 596749 įrašai per 11 sekundžių
- Elastinis + reaktyvus klientas 10 gijų + paketas 1000 elementų: 23801684 įrašai per 4 minutes
Dabar sukūrėme HTTP užklausų tvarkyklę, kuri sukuria JSON kaip paketą / ne paketą ir siunčia jį per bet kurį HTTP klientą, neatsižvelgiant į biblioteką. Taip pat galite pasirinkti siųsti užklausas sinchroniškai arba asinchroniškai.
Kai kuriose integracijose vis dar naudojame oficialų transporto klientą, tačiau tai tik kito pertvarkymo reikalas. Šiuo atveju apdorojimui naudojamas pasirinktinis klientas, sukurtas „Spring WebClient“ pagrindu.
didelė reklama
Kartą per metus projektas surengia didelę reklamą vartotojams - tai yra ta pati „Highload“, nes šiuo metu dirbame su dešimtimis milijonų vartotojų tuo pačiu metu.
Dažniausiai krūvių pikas būna per šventes, tačiau ši akcija yra visai kito lygio. Užpernai, akcijos dieną, pardavėme 27 580 890 prekių vienetų. Duomenys buvo tvarkomi daugiau nei pusvalandį, o tai sukėlė nepatogumų vartotojams. Už dalyvavimą vartotojai gavo prizus, tačiau tapo aišku, kad procesą reikia paspartinti.
2019 m. pradžioje nusprendėme, kad mums reikia ElasticSearch. Ištisus metus organizavome gautų duomenų apdorojimą Elastic ir jų išdavimą mobiliosios aplikacijos ir svetainės API. Dėl to kitais metais kampanijos metu apdorojome 15 131 783 įrašai per 6 minutes.
Kadangi norinčių įsigyti prekių ir dalyvauti akcijose prizų traukime turime nemažai, tai laikina priemonė. Dabar mes siunčiame naujausią informaciją Elastic, tačiau ateityje planuojame perkelti pastarųjų mėnesių archyvuotą informaciją į Postgres kaip nuolatinę saugyklą. Kad neužsikimštų Elastic indeksas, kuris taip pat turi savo apribojimų.
Išvada/Išvados
Šiuo metu visas paslaugas, kurių norėjome, perdavėme į Elastic ir kol kas tai pristabdėme. Dabar kuriame Elastic indeksą ant pagrindinės nuolatinės saugyklos Postgres, kuri perima vartotojo apkrovą.
Ateityje planuojame perkelti paslaugas, jei suprasime, kad duomenų užklausa tampa per įvairi ir ieškoma neribotam stulpelių skaičiui. Tai nebėra „Postgres“ užduotis.
Jei mums reikia viso teksto paieškos funkcionalumo srityje arba jei turime daug skirtingų paieškos kriterijų, jau žinome, kad tai turi būti išversta į Elastic.
⌘⌘⌘
Ačiū, kad skaitėte. Jei jūsų įmonė taip pat naudoja ElasticSearch ir turi savo diegimo atvejus, pasakykite mums. Bus įdomu sužinoti, kaip sekasi kitiems 🙂
Šaltinis: www.habr.com