Slodzes optimizācija Highload projektā, izmantojot ElasticSearch

Čau Habr! Mani sauc Maksims Vasiļjevs, es strādāju par analÄ«tiÄ·i un projektu vadÄ«tāju uzņēmumā FINCH. Å odien es vēlos jums pastāstÄ«t, kā, izmantojot ElasticSearch, mēs varējām apstrādāt 15 miljonus pieprasÄ«jumu 6 minÅ«tēs un optimizēt ikdienas slodzes viena mÅ«su klienta vietnē. Diemžēl nāksies iztikt bez nosaukumiem, jo ā€‹ā€‹mums ir NDA, ceram, ka raksta saturs no tā necietÄ«s. Ejam.

Kā projekts darbojas

Savā aizmugurē mēs veidojam pakalpojumus, kas nodroÅ”ina mÅ«su klientu vietņu un mobilās aplikācijas veiktspēju. Vispārējo struktÅ«ru var redzēt diagrammā:

Slodzes optimizācija Highload projektā, izmantojot ElasticSearch

Darba procesā apstrādājam lielu skaitu darÄ«jumu: pirkumus, maksājumus, operācijas ar lietotāju bilancēm, par kurām glabājam daudz žurnālu, kā arÄ« importējam un eksportējam Å”os datus uz ārējām sistēmām.

Ir arī reversie procesi, kad mēs saņemam datus no klienta un nododam tos lietotājam. Turklāt joprojām pastāv procesi darbam ar maksājumiem un bonusu programmām.

ÄŖss fons

Sākotnēji mēs izmantojām PostgreSQL kā vienÄ«go datu krātuvi. Tā standarta priekÅ”rocÄ«bas DBVS: transakciju klātbÅ«tne, izstrādāta datu izlases valoda, plaÅ”s integrācijas rÄ«ku klāsts; apvienojumā ar labu sniegumu diezgan ilgu laiku apmierināja mÅ«su vajadzÄ«bas.

Mēs Postgres glabājām pilnīgi visus datus: no darījumiem līdz ziņām. Taču pieauga lietotāju skaits un līdz ar to arī pieprasījumu skaits.

Lai saprastu, 2017. gadā ikgadējais sesiju skaits tikai galddatora vietnē ir 131 miljons. 2018. gadā - 125 miljoni. 2019. gadā atkal 130 miljoni. Pievienojiet vēl 100-200 miljonus no vietnes mobilās versijas un mobilās aplikācijas, un jūs saņems milzīgu skaitu pieprasījumu.

Projektam augot, Postgres pārstāja tikt galā ar slodzi, mums nebija laika - parādījās liels skaits dažādu vaicājumu, kuriem nevarējām izveidot pietiekamu skaitu indeksu.

Mēs sapratām, ka ir nepiecieÅ”ami citi datu krātuves, kas nodroÅ”inātu mÅ«su vajadzÄ«bas un noņemtu PostgreSQL slodzi. Kā iespējamās iespējas tika uzskatÄ«tas Elasticsearch un MongoDB. Pēdējais zaudēja ar Ŕādiem punktiem:

  1. Lēns indeksÄ“Å”anas ātrums, jo pieaug datu apjoms indeksos. Izmantojot Elastic, ātrums nav atkarÄ«gs no datu apjoma.
  2. Nav pilna teksta meklēŔanas

Tāpēc mēs izvēlējāmies Elastic sev un gatavojāmies pārejai.

Pāreja uz elastīgo

1. Sākām pāreju no tirdzniecÄ«bas vietu meklÄ“Å”anas servisa. MÅ«su klientam kopumā ir aptuveni 70 000 tirdzniecÄ«bas vietu, un tas prasa vairāku veidu meklÄ“Å”anu vietnē un lietojumprogrammā:

  • Teksta meklÄ“Å”ana pēc pilsētas nosaukuma
  • Ä¢eomeklÄ“Å”ana noteiktā rādiusā no kāda punkta. Piemēram, ja lietotājs vēlas redzēt, kuras tirdzniecÄ«bas vietas atrodas vistuvāk viņa mājām.
  • Meklēt pēc dotā kvadrāta ā€“ lietotājs uzzÄ«mē kvadrātu kartē, un viņam tiek parādÄ«ti visi punkti Å”ajā rādiusā.
  • Meklēt pēc papildu filtriem. TirdzniecÄ«bas vietas atŔķiras viena no otras sortimentā

Ja mēs runājam par organizāciju, tad Postgres mums ir datu avots gan kartei, gan ziņām, un elastÄ«gajos momentuzņēmumos tiek ņemti no sākotnējiem datiem. Fakts ir tāds, ka sākotnēji Postgres nevarēja tikt galā ar meklÄ“Å”anu pēc visiem kritērijiem. Ne tikai bija daudz indeksu, tie varēja arÄ« pārklāties, tāpēc Postgres plānotājs apmaldÄ«jās un nesaprata, kuru indeksu izmantot.

2. Nākamā rindā bija ziņu sadaļa. Publikācijas vietnē parādās katru dienu, lai lietotājs nepazustu informācijas plÅ«smā, dati ir jāsakārto pirms izdoÅ”anas. Å Ä« ir meklÄ“Å”ana: jÅ«s varat meklēt vietnē pēc teksta atbilstÄ«bas un tajā paŔā laikā pievienot papildu filtrus, jo arÄ« tie tiek veikti, izmantojot Elastic.

3. Pēc tam mēs pārcēlām darÄ«jumu apstrādi. Lietotāji vietnē var iegādāties noteiktu produktu un piedalÄ«ties balvu izlozē. Pēc Ŕādiem pirkumiem mēs apstrādājam lielu datu apjomu, Ä«paÅ”i brÄ«vdienās un svētku dienās. SalÄ«dzinājumam, ja parastās dienās pirkumu skaits ir kaut kur starp 1,5-2 miljoniem, tad brÄ«vdienās Å”is rādÄ«tājs var sasniegt 53 miljonus.

Tajā paŔā laikā dati ir jāapstrādā pēc iespējas Ä«sākā laikā ā€“ lietotājiem nepatÄ«k gaidÄ«t rezultātu vairākas dienas. Izmantojot Postgres, Ŕādus termiņus nevar sasniegt ā€” mēs bieži saņēmām slēdzenes, un, kamēr mēs apstrādājām visus pieprasÄ«jumus, lietotāji nevarēja pārbaudÄ«t, vai viņi ir saņēmuÅ”i balvas. Tas nav Ä«paÅ”i patÄ«kami biznesam, tāpēc mēs pārcēlām apstrādi uz Elasticsearch.

Periodiskums

Tagad atjauninājumi ir konfigurēti, pamatojoties uz notikumiem, saskaņā ar Ŕādiem nosacÄ«jumiem:

  1. TirdzniecÄ«bas vietas. TiklÄ«dz mēs saņemam datus no ārēja avota, mēs nekavējoties sākam atjaunināŔanu.
  2. Jaunumi. Tiklīdz kāds jaunums tiek rediģēts vietnē, tas tiek automātiski nosūtīts uz Elastic.

Å eit atkal ir vērts pieminēt Elastic priekÅ”rocÄ«bas. Postgres, nosÅ«tot pieprasÄ«jumu, ir jāgaida, lÄ«dz tas godÄ«gi apstrādā visus ierakstus. Varat nosÅ«tÄ«t 10 XNUMX ierakstu uz Elastic un nekavējoties sākt darbu, negaidot, kamēr ieraksti tiks izplatÄ«ti pa visām Shards. Protams, daži Shard vai Replica var neredzēt datus uzreiz, taču viss bÅ«s pieejams ļoti drÄ«z.

Integrācijas metodes

Ir 2 veidi, kā integrēt ar Elastic:

  1. Izmantojot vietējo klientu, izmantojot TCP. Vietējais draiveris pamazām izmirst: tas vairs netiek atbalstÄ«ts, tam ir ļoti neērta sintakse. Tāpēc mēs to praktiski neizmantojam un cenÅ”amies pilnÄ«bā atteikties.
  2. Izmantojot HTTP saskarni, kas var izmantot gan JSON pieprasÄ«jumus, gan Lucene sintaksi. Pēdējais ir teksta dzinējs, kas izmanto Elastic. Å ajā versijā mēs iegÅ«stam iespēju pakeÅ”ot, izmantojot JSON pieprasÄ«jumus, izmantojot HTTP. Å o iespēju mēs cenÅ”amies izmantot.

Pateicoties HTTP interfeisam, mēs varam izmantot bibliotēkas, kas nodroÅ”ina HTTP klienta asinhronu ievieÅ”anu. Mēs varam izmantot Batch un asinhronās API priekÅ”rocÄ«bas, kas nodroÅ”ina augstu veiktspēju, kas ļoti palÄ«dzēja lielās reklāmas dienās (vairāk par to tālāk).

Daži skaitļi salīdzinājumam:

  • Postgres bounty lietotāju saglabāŔana 20 pavedienos bez grupÄ“Å”anas: 460713 ieraksti 42 sekundēs
  • ElastÄ«gs + reaktÄ«vs klients 10 pavedieniem + partija 1000 elementiem: 596749 ieraksti 11 sekundēs
  • ElastÄ«gs + reaktÄ«vs klients 10 pavedieniem + partija 1000 elementiem: 23801684 ieraksti 4 minÅ«tēs

Tagad esam uzrakstÄ«juÅ”i HTTP pieprasÄ«jumu pārvaldnieku, kas veido JSON kā pakeÅ”u/nevis pakeÅ”u un nosÅ«ta to caur jebkuru HTTP klientu neatkarÄ«gi no bibliotēkas. Varat arÄ« izvēlēties sÅ«tÄ«t pieprasÄ«jumus sinhroni vai asinhroni.

Dažās integrācijās mēs joprojām izmantojam oficiālo transporta klientu, taču tas ir tikai nākamās pārveidoÅ”anas jautājums. Å ajā gadÄ«jumā apstrādei tiek izmantots pielāgots klients, kas izveidots, pamatojoties uz Spring WebClient.

Slodzes optimizācija Highload projektā, izmantojot ElasticSearch

liela akcija

Reizi gadā projekts rÄ«ko lielu reklāmu lietotājiem - Ŕī ir tā pati Highload, jo Å”obrÄ«d mēs strādājam ar desmitiem miljonu lietotāju vienlaikus.

Parasti slodžu maksimumi notiek brÄ«vdienās, taču Ŕī akcija ir pavisam citā lÄ«menÄ«. Aizpērn akcijas dienā pārdevām 27 580 890 preču vienÄ«bas. Dati tika apstrādāti vairāk nekā pusstundu, kas lietotājiem sagādāja neērtÄ«bas. Lietotāji saņēma balvas par dalÄ«bu, taču kļuva skaidrs, ka process ir jāpaātrina.

2019. gada sākumā mēs nolēmām, ka mums ir nepiecieÅ”ams ElasticSearch. Veselu gadu organizējām saņemto datu apstrādi Elastic un to izsniegÅ”anu mobilās aplikācijas un mājaslapas api. Rezultātā nākamajā gadā kampaņas laikā mēs apstrādājām 15 131 783 ieraksti 6 minÅ«tēs.

Tā kā mums ir daudz cilvēku, kas vēlas iegādāties preces un piedalÄ«ties balvu izlozē akcijās, tad Å”is ir pagaidu pasākums. Tagad mēs nosÅ«tām jaunāko informāciju Elastic, bet nākotnē plānojam arhivēto informāciju par pēdējiem mēneÅ”iem nodot Postgres kā pastāvÄ«gu krātuvi. Lai neaizsprostotu Elastic indeksu, kam arÄ« ir savi ierobežojumi.

Secinājums/Secinājumi

Å obrÄ«d esam pārcēluÅ”i uz Elastic visus pakalpojumus, kurus vēlējāmies, un pagaidām esam to apturējuÅ”i. Tagad mēs veidojam Elastic indeksu virs galvenās pastāvÄ«gās krātuves Postgres, kas pārņem lietotāja slodzi.

Nākotnē plānojam pārsūtīt pakalpojumus, ja sapratīsim, ka datu pieprasījums kļūst pārāk daudzveidīgs un tiek meklēts neierobežotā skaitā kolonnu. Tas vairs nav Postgres uzdevums.

Ja mums ir nepiecieÅ”ama pilna teksta meklÄ“Å”ana funkcionalitātē vai ja mums ir daudz dažādu meklÄ“Å”anas kritēriju, tad mēs jau zinām, ka tas ir jāpārtulko elastÄ«gajā valodā.

āŒ˜āŒ˜āŒ˜

Paldies, ka izlasÄ«jāt. Ja arÄ« jÅ«su uzņēmums izmanto ElasticSearch un tam ir savi ievieÅ”anas gadÄ«jumi, pastāstiet mums. BÅ«s interesanti uzzināt, kā klājas citiem šŸ™‚

Avots: www.habr.com

Pievieno komentāru