Haai Habr! My naam is Maxim Vasiliev, ek werk as 'n ontleder en projekbestuurder by FINCH. Vandag wil ek jou graag vertel hoe ons, deur gebruik te maak van ElasticSearch, in staat was om 15 miljoen versoeke in 6 minute te verwerk en die daaglikse vragte op die webwerf van een van ons kliënte te optimaliseer. Ongelukkig sal ons sonder name moet klaarkom, aangesien ons 'n NDA het, hoop ons dat die inhoud van die artikel nie hieronder sal ly nie. Kom ons gaan.
Hoe die projek werk
Op ons agterkant skep ons dienste wat die werkverrigting van ons kliënt se webwerwe en mobiele toepassing verseker. Die algemene struktuur kan in die diagram gesien word:
In die proses van werk verwerk ons 'n groot aantal transaksies: aankope, betalings, bedrywighede met gebruikerssaldo's, waarvoor ons baie logs stoor, sowel as die invoer en uitvoer van hierdie data na eksterne stelsels.
Daar is ook omgekeerde prosesse wanneer ons data van die kliënt ontvang en dit aan die gebruiker oordra. Boonop is daar nog prosesse om met betalings en bonusprogramme te werk.
Kort agtergrond
Aanvanklik het ons PostgreSQL as die enigste datawinkel gebruik. Sy standaardvoordele vir 'n DBBS: die teenwoordigheid van transaksies, 'n ontwikkelde datasteekproeftaal, 'n wye reeks instrumente vir integrasie; gekombineer met goeie prestasie het ons behoeftes vir 'n redelike lang tyd bevredig.
Ons het absoluut alle data in Postgres gestoor: van transaksies tot nuus. Maar die aantal gebruikers het gegroei, en daarmee saam die aantal versoeke.
Vir begrip, die jaarlikse aantal sessies in 2017 slegs op die rekenaarwebwerf is 131 miljoen. In 2018 - 125 miljoen. 2019 weer 130 miljoen. Voeg nog 100-200 miljoen by vanaf die mobiele weergawe van die webwerf en die mobiele toepassing, en jy sal 'n groot aantal versoeke kry.
Met die groei van die projek het Postgres opgehou om die las te hanteer, ons het nie tyd gehad nie - 'n groot aantal verskillende navrae het verskyn, waarvoor ons nie 'n voldoende aantal indekse kon skep nie.
Ons het verstaan dat daar 'n behoefte was aan ander datawinkels wat in ons behoeftes sou voorsien en die las van PostgreSQL sou afneem. Elasticsearch en MongoDB is as moontlike opsies beskou. Laasgenoemde het op die volgende punte verloor:
- Stadige indekseringspoed soos die hoeveelheid data in indekse groei. Met Elastic hang die spoed nie af van die hoeveelheid data nie.
- Geen voltekssoektog nie
So ons het Elastic vir onsself gekies en voorberei vir die oorgang.
Oorgang na Elasties
1. Ons het die oorgang vanaf die verkoopspunt-soekdiens begin. Ons kliënt het 'n totaal van ongeveer 70 000 verkoopspunte, en dit vereis verskeie tipes soektogte op die webwerf en in die toepassing:
- Tekssoektog volgens stadnaam
- Gesoek binne 'n gegewe radius vanaf 'n sekere punt. Byvoorbeeld, as die gebruiker wil sien watter verkoopspunte die naaste aan sy huis is.
- Soek volgens 'n gegewe vierkant - die gebruiker teken 'n vierkant op die kaart, en alle punte in hierdie radius word aan hom gewys.
- Soek deur bykomende filters. Verkooppunte verskil van mekaar in assortiment
As ons oor die organisasie praat, dan het ons in Postgres 'n databron vir beide die kaart en die nuus, en in Elastiese Snapshots word van die oorspronklike data geneem. Die feit is dat Postgres aanvanklik nie die soektog volgens alle kriteria kon hanteer nie. Daar was nie net baie indekse nie, hulle kon ook oorvleuel, sodat die Postgres-skeduleerder verlore geraak het en nie verstaan watter indeks om te gebruik nie.
2. Volgende aan die beurt was die nuusafdeling. Publikasies verskyn elke dag op die webwerf sodat die gebruiker nie verdwaal in die vloei van inligting nie, die data moet gesorteer word voor uitreiking. Dit is waarvoor soektog is: jy kan die werf deursoek volgens tekspassing, en terselfdertyd bykomende filters koppel, aangesien hulle ook deur Elastic gemaak word.
3. Toe het ons die transaksieverwerking geskuif. Gebruikers kan 'n sekere produk op die webwerf koop en aan 'n prystrekking deelneem. Na sulke aankope verwerk ons 'n groot hoeveelheid data, veral oor naweke en vakansiedae. Ter vergelyking, as die aantal aankope op gewone dae iewers tussen 1,5-2 miljoen is, kan die syfer op vakansiedae 53 miljoen bereik.
Terselfdertyd moet die data in die kortste moontlike tyd verwerk word - gebruikers hou nie daarvan om vir 'n paar dae op die uitslag te wag nie. Daar is geen manier om sulke spertye deur Postgres te bereik nie - ons het dikwels slotte ontvang, en terwyl ons alle versoeke verwerk het, kon gebruikers nie kyk of hulle pryse ontvang het of nie. Dit is nie baie aangenaam vir besigheid nie, daarom het ons die verwerking na Elasticsearch geskuif.
periodisiteit
Nou word opdaterings op gebeurtenisgebaseer gekonfigureer, volgens die volgende voorwaardes:
- Verkoopspunte. Sodra ons data van 'n eksterne bron ontvang, begin ons dadelik met die opdatering.
- Nuus. Sodra enige nuus op die webwerf geredigeer word, word dit outomaties na Elastic gestuur.
Hier is dit weer die moeite werd om die voordele van Elastic te noem. In Postgres, wanneer u 'n versoek stuur, moet u wag totdat dit al die rekords eerlik verwerk. Jy kan 10 XNUMX rekords na Elastic stuur en dadelik begin werk, sonder om te wag dat die rekords oor alle Shards versprei word. Natuurlik kan sommige Shard of Replica nie die data dadelik sien nie, maar alles sal binnekort beskikbaar wees.
Integrasie metodes
Daar is 2 maniere om met Elastic te integreer:
- Deur 'n inheemse kliënt oor TCP. Die inheemse drywer sterf geleidelik uit: dit word nie meer ondersteun nie, dit het 'n baie ongerieflike sintaksis. Daarom gebruik ons dit feitlik nie en probeer om dit heeltemal te laat vaar.
- Deur 'n HTTP-koppelvlak wat beide JSON-versoeke en Lucene-sintaksis kan gebruik. Die laaste een is 'n teksenjin wat Elastic gebruik. In hierdie weergawe kry ons die vermoë om deur JSON-versoeke oor HTTP te batch. Dit is die opsie wat ons probeer gebruik.
Danksy die HTTP-koppelvlak kan ons biblioteke gebruik wat 'n asynchrone implementering van die HTTP-kliënt verskaf. Ons kan voordeel trek uit Batch en die asynchrone API, wat lei tot hoë werkverrigting, wat baie gehelp het in die dae van die groot promosie (meer daaroor hieronder)
Enkele getalle vir vergelyking:
- Stoor Postgres-bounty-gebruikers in 20 drade sonder groepering: 460713 rekords in 42 sekondes
- Elasties + reaktiewe kliënt vir 10 drade + bondel vir 1000 elemente: 596749 rekords in 11 sekondes
- Elastiese + reaktiewe kliënt vir 10 drade + bondel vir 1000 elemente: 23801684 inskrywings in 4 minute
Nou het ons 'n HTTP-versoekbestuurder geskryf wat JSON as Batch/not Batch bou en dit via enige HTTP-kliënt stuur, ongeag die biblioteek. Jy kan ook kies om versoeke sinchronies of asinchronies te stuur.
In sommige integrasies gebruik ons steeds die amptelike vervoerkliënt, maar dit is net 'n kwessie van die volgende herfaktorering. In hierdie geval word 'n pasgemaakte kliënt wat op die basis van Spring WebClient gebou is vir verwerking gebruik.
groot bevordering
Een keer per jaar bied die projek 'n groot promosie vir gebruikers aan - dit is dieselfde Highload, aangesien ons tans met tienmiljoene gebruikers op dieselfde tyd werk.
Gewoonlik vind pieke van vragte gedurende die vakansie plaas, maar hierdie promosie is op 'n heeltemal ander vlak. Voorverlede jaar, op die dag van die promosie, het ons 27 580 890 eenhede goedere verkoop. Die data is vir meer as 'n halfuur verwerk, wat ongerief vir gebruikers veroorsaak het. Gebruikers het pryse vir deelname ontvang, maar dit het duidelik geword dat die proses versnel moes word.
Aan die begin van 2019 het ons besluit dat ons ElasticSearch nodig het. Vir 'n hele jaar het ons die verwerking van die ontvangde data in Elastic en die uitreiking daarvan in die api van die mobiele toepassing en webwerf georganiseer. Gevolglik het ons die volgende jaar tydens die veldtog verwerk 15 131 783 inskrywings in 6 minute.
Aangesien ons baie mense het wat goedere wil koop en aan die trekking van pryse in promosies wil deelneem, is dit 'n tydelike maatreël. Nou stuur ons bygewerkte inligting na Elastic, maar in die toekoms beplan ons om argiefinligting vir die afgelope maande na Postgres oor te dra as 'n permanente berging. Om nie die Elastiese indeks te verstop nie, wat ook sy beperkings het.
Gevolgtrekking/Gevolgtrekkings
Op die oomblik het ons al die dienste wat ons wou oorgedra na Elastic en het vir eers hieroor stilgehou. Nou bou ons 'n indeks in Elastic bo-op die hoof aanhoudende berging in Postgres, wat die gebruikerslading oorneem.
In die toekoms beplan ons om dienste oor te dra as ons verstaan dat die dataversoek te divers word en vir 'n onbeperkte aantal kolomme gesoek word. Dit is nie meer 'n taak vir Postgres nie.
As ons volteks soektog in funksionaliteit nodig het of as ons baie verskillende soekkriteria het, dan weet ons reeds dat dit in Elastic vertaal moet word.
⌘⌘⌘
Dankie vir die lees. As jou maatskappy ook ElasticSearch gebruik en sy eie implementeringsgevalle het, vertel ons dan. Dit sal interessant wees om te weet hoe dit met ander gaan 🙂
Bron: will.com