Hei Habr! Nimeni on Maxim Vasiliev, työskentelen analyytikkona ja projektipäällikkönä FINCHilla. Tänään haluan kertoa sinulle, kuinka ElasticSearchin avulla pystyimme käsittelemään 15 miljoonaa pyyntöä 6 minuutissa ja optimoimaan yhden asiakkaamme sivuston päivittäiset lataukset. Valitettavasti joudumme tulemaan ilman nimiä, koska meillä on NDA, toivomme, että artikkelin sisältö ei kärsi tästä. Mennään.
Miten projekti toimii
Taustallamme luomme palveluita, jotka varmistavat asiakkaidemme verkkosivujen ja mobiilisovelluksen toimivuuden. Yleinen rakenne näkyy kaaviossa:
Työn aikana käsittelemme suuren määrän tapahtumia: ostoja, maksuja, operaatioita käyttäjien saldoilla, joista tallennamme paljon lokeja, sekä tuomme ja viemme näitä tietoja ulkoisiin järjestelmiin.
On myös käänteisiä prosesseja, kun saamme dataa asiakkaalta ja siirrämme sen käyttäjälle. Lisäksi on edelleen prosesseja maksujen ja bonusohjelmien kanssa työskentelemiseen.
Lyhyt tausta
Aluksi käytimme PostgreSQL:ää ainoana tietovarastona. Sen vakioetuja DBMS:lle: tapahtumien läsnäolo, kehitetty tietojen näytteenottokieli, laaja valikoima työkaluja integrointiin; yhdistettynä hyvään suorituskykyyn täytti tarpeitamme melko pitkään.
Tallensimme Postgresiin ehdottomasti kaikki tiedot tapahtumista uutisiin. Mutta käyttäjien määrä kasvoi ja sen myötä pyyntöjen määrä.
Ymmärtääkseni vuotuinen istuntojen määrä vuonna 2017 vain työpöytäsivustolla on 131 miljoonaa. Vuonna 2018 - 125 miljoonaa. 2019 jälleen 130 miljoonaa. Lisää vielä 100-200 miljoonaa sivuston mobiiliversiosta ja mobiilisovelluksesta, ja sinä tulee valtava määrä pyyntöjä.
Projektin kasvun myötä Postgres lakkasi selviytymästä kuormituksesta, meillä ei ollut aikaa - ilmestyi suuri määrä erilaisia kyselyjä, joille emme pystyneet luomaan riittävää määrää indeksejä.
Ymmärsimme, että tarvitaan muita tietovarastoja, jotka täyttäisivät tarpeemme ja poistaisivat PostgreSQL:n taakan. Elasticsearch ja MongoDB katsottiin mahdollisiksi vaihtoehdoiksi. Jälkimmäinen hävisi seuraavissa kohdissa:
- Hidas indeksointinopeus indeksien datamäärän kasvaessa. Elasticilla nopeus ei riipu tiedon määrästä.
- Ei kokotekstihakua
Joten valitsimme Elasticin itsellemme ja valmistauduimme siirtymään.
Siirtyminen elastiseen
1. Aloitimme siirtymisen myyntipistehakupalvelusta. Asiakkaallamme on yhteensä noin 70 000 myyntipistettä, mikä vaatii monenlaisia hakuja sivustolla ja sovelluksessa:
- Tekstihaku kaupungin nimen mukaan
- Geoeetsi tietystä säteestä jostain kohdasta. Esimerkiksi, jos käyttäjä haluaa nähdä, mitkä myyntipisteet ovat lähimpänä hänen kotiaan.
- Hae tietyn neliön mukaan - käyttäjä piirtää neliön karttaan, ja kaikki tämän säteen pisteet näytetään hänelle.
- Hae lisäsuodattimilla. Myyntipaikat eroavat toisistaan valikoimaltaan
Jos puhumme organisaatiosta, niin Postgresissa meillä on tietolähde sekä kartalle että uutisille, ja Elastic Snapshots -kuvat otetaan alkuperäisistä tiedoista. Tosiasia on, että alun perin Postgres ei pystynyt selviytymään hausta kaikilla kriteereillä. Sen lisäksi, että indeksejä oli monia, ne saattoivat myös mennä päällekkäin, joten Postgres-ajastin eksyi eikä ymmärtänyt mitä indeksiä käyttää.
2. Seuraavana jonossa oli uutisosio. Julkaisuja ilmestyy sivustolle päivittäin, jotta käyttäjä ei eksy tiedonkulkuun, tiedot on lajiteltava ennen julkaisua. Tätä varten haku on tarkoitettu: voit etsiä sivustoa tekstihaun perusteella ja samalla liittää lisäsuodattimia, koska nekin tehdään Elasticin kautta.
3. Sitten siirsimme tapahtuman käsittelyn. Käyttäjät voivat ostaa tietyn tuotteen sivustolta ja osallistua palkintojen arvontaan. Tällaisten ostosten jälkeen käsittelemme suuria määriä tietoja, erityisesti viikonloppuisin ja pyhäpäivinä. Vertailun vuoksi, jos tavallisina päivinä ostosten määrä on jossain 1,5-2 miljoonan välillä, niin juhlapyhinä luku voi nousta 53 miljoonaan.
Samalla tiedot on käsiteltävä mahdollisimman lyhyessä ajassa - käyttäjät eivät halua odottaa tulosta useita päiviä. Tällaisia määräaikoja ei voida saavuttaa Postgresin kautta - saimme usein lukkoja, ja kun käsittelimme kaikkia pyyntöjä, käyttäjät eivät voineet tarkistaa, ovatko he saaneet palkintoja vai eivät. Tämä ei ole kovin miellyttävää liiketoiminnalle, joten siirsimme käsittelyn Elasticsearchiin.
jaksotus
Nyt päivitykset on määritetty tapahtumapohjaisesti seuraavien ehtojen mukaisesti:
- Myyntipisteet. Heti kun saamme tietoja ulkoisesta lähteestä, aloitamme päivityksen välittömästi.
- Uutiset. Heti kun uutisia muokataan sivustolla, se lähetetään automaattisesti Elasticille.
Tässäkin kannattaa mainita Elasticin edut. Postgresissa pyyntöä lähetettäessä sinun on odotettava, kunnes se käsittelee kaikki tietueet rehellisesti. Voit lähettää 10 XNUMX tietuetta Elasticille ja aloittaa työskentelyn välittömästi odottamatta tietueiden jakamista kaikille Shardeille. Tietenkin jotkut sirpaleet tai replikat eivät välttämättä näe tietoja heti, mutta kaikki on saatavilla hyvin pian.
Integrointimenetelmät
On 2 tapaa integroida Elasticiin:
- Natiiviasiakkaan kautta TCP:n kautta. Alkuperäinen ajuri on vähitellen kuolemassa: sitä ei enää tueta, sillä on erittäin hankala syntaksi. Siksi emme käytännössä käytä sitä ja yritämme hylätä sen kokonaan.
- HTTP-rajapinnan kautta, joka voi käyttää sekä JSON-pyyntöjä että Lucene-syntaksia. Viimeinen on tekstimoottori, joka käyttää Elasticia. Tässä versiossa voimme suorittaa erän JSON-pyyntöjen kautta HTTP:n kautta. Tämä on vaihtoehto, jota yritämme käyttää.
HTTP-rajapinnan ansiosta voimme käyttää kirjastoja, jotka tarjoavat HTTP-asiakkaan asynkronisen toteutuksen. Voimme hyödyntää erää ja asynkronista APIa, mikä johtaa korkeaan suorituskykyyn, mikä auttoi paljon suuren promootiopäivän aikana (lisätietoja alla)
Muutama luku vertailuksi:
- Postgres-palkkion käyttäjien tallentaminen 20 säiettä ilman ryhmittelyä: 460713 tietuetta 42 sekunnissa
- Elastinen + reaktiivinen asiakas 10 säikeelle + erä 1000 elementille: 596749 tietuetta 11 sekunnissa
- Elastinen + reaktiivinen asiakas 10 säikeelle + erä 1000 elementille: 23801684 merkintää 4 minuutissa
Nyt olemme kirjoittaneet HTTP-pyyntöjen hallinnan, joka rakentaa JSON-muodossa Erä/ei Erä ja lähettää sen minkä tahansa HTTP-asiakkaan kautta kirjastosta riippumatta. Voit myös valita, lähetetäänkö pyyntöjä synkronisesti tai asynkronisesti.
Joissakin integraatioissa käytämme edelleen virallista kuljetusasiakasta, mutta tämä on vasta seuraavan refaktoroinnin asia. Tässä tapauksessa käsittelyyn käytetään Spring WebClientin pohjalta rakennettua mukautettua asiakasohjelmaa.
iso promootio
Kerran vuodessa projekti isännöi suurta promootiota käyttäjille - tämä on sama Highload, koska tällä hetkellä työskentelemme kymmenien miljoonien käyttäjien kanssa samaan aikaan.
Yleensä kuormitushuiput esiintyvät lomien aikana, mutta tämä promootio on aivan eri tasolla. Toissa vuonna, kampanjapäivänä, myimme 27 580 890 tavaraa. Tietoja käsiteltiin yli puoli tuntia, mikä aiheutti haittaa käyttäjille. Käyttäjät saivat osallistumisesta palkintoja, mutta kävi selväksi, että prosessia oli vauhditettava.
Vuoden 2019 alussa päätimme, että tarvitsemme ElasticSearchin. Koko vuoden ajan järjestimme vastaanotettujen tietojen käsittelyä Elasticissa ja niiden myöntämisen mobiilisovelluksen ja verkkosivuston api:ssä. Tämän seurauksena seuraavana vuonna kampanjan aikana käsittelimme 15 131 783 merkintää 6 minuutissa.
Koska meillä on paljon ihmisiä, jotka haluavat ostaa tavaroita ja osallistua palkintojen arvontaan kampanjoissa, tämä on väliaikainen toimenpide. Nyt lähetämme ajantasaista tietoa Elasticille, mutta jatkossa aiomme siirtää viime kuukausien arkistoidut tiedot Postgresiin pysyväksi varastoksi. Jotta ei tukkeutuisi Elastic-indeksiä, jolla on myös rajoituksensa.
Päätelmä/päätelmät
Tällä hetkellä olemme siirtäneet Elasticille kaikki haluamamme palvelut ja keskeytämme tämän toistaiseksi. Nyt rakennamme Elasticiin hakemistoa Postgresin pysyvän päätallennustilan päälle, joka kestää käyttäjän kuorman.
Jatkossa aiomme siirtää palveluita, jos ymmärrämme, että tietopyyntö tulee liian monimuotoiseksi ja sitä haetaan rajattomasti sarakkeita. Tämä ei ole enää Postgresin tehtävä.
Jos tarvitsemme kokotekstihaun toiminnallisuudessa tai jos meillä on paljon erilaisia hakuehtoja, tiedämme jo, että tämä on käännettävä Elasticiksi.
⌘⌘⌘
Kiitos kun luit. Jos yrityksesi käyttää myös ElasticSearchia ja sillä on omat käyttöönottotapaukset, kerro meille. Mielenkiintoista tietää miten muilla menee 🙂
Lähde: will.com