Aupa Habr! Nire izena Maxim Vasiliev da, FINCH-en analista eta proiektu zuzendari gisa lan egiten dut. Gaur esan nahiko nuke nola, ElasticSearch erabiliz, 15 minututan 6 milioi eskaera prozesatu eta gure bezeroetako baten gunean eguneroko kargak optimizatu ahal izan ditugun. Tamalez, izenik gabe egin beharko dugu, NDA dugunez, artikuluaren edukiak hori sufritzea espero dugu. Goazen.
Proiektuak nola funtzionatzen duen
Gure backend-ean, gure bezeroen webguneen eta mugikorreko aplikazioen errendimendua bermatzen duten zerbitzuak sortzen ditugu. Egitura orokorra diagraman ikus daiteke:
Lan-prozesuan, transakzio ugari prozesatzen ditugu: erosketak, ordainketak, erabiltzaileen saldoekin egindako eragiketak, eta horretarako erregistro asko gordetzen ditugu, baita datu horiek kanpoko sistemetara inportatu eta esportatu ere.
Alderantzizko prozesuak ere badaude bezeroaren datuak jaso eta erabiltzaileari transferitzen ditugunean. Horrez gain, ordainketak eta bonus programekin lan egiteko prozesuak daude oraindik.
Aurrekari laburrak
Hasieran, PostgreSQL erabili genuen datu biltegi bakar gisa. DBMS baterako dituen abantaila estandarrak: transakzioen presentzia, datuen laginketa-lengoaia garatua, integraziorako tresna sorta zabala; errendimendu onarekin konbinatuta gure beharrak nahiko denbora luzez asetu zituen.
Postgres-en datu guztiak gorde genituen: transakzioetatik hasi eta albisteetara. Baina erabiltzaile kopurua hazi zen, eta horrekin batera eskaera kopurua.
Ulertzeko, 2017an mahaigaineko gunean bakarrik 131 milioi urteko saio kopurua da. 2018an - 125 milioi. 2019an berriz 130 milioi. Gehitu beste 100-200 milioi gunearen mugikorren bertsiotik eta mugikorretarako aplikaziotik, eta zuk eskaera ugari jasoko ditu.
Proiektuaren hazkundearekin, Postgres-ek kargari aurre egiteari utzi zion, ez genuen denborarik izan - hainbat kontsulta ugari agertu ziren, eta horretarako ezin izan genuen indize kopuru nahikorik sortu.
Ulertu genuen gure beharrak hornitzeko eta PostgreSQL karga kenduko zuten beste datu biltegi batzuen beharra zegoela. Elasticsearch eta MongoDB aukera posibletzat hartu ziren. Azken honek puntu hauetan galdu zuen:
- Indize-abiadura motela indizeetan datu kopurua hazten den heinean. Elastic-ekin, abiadura ez da datu kopuruaren araberakoa.
- Testu osoko bilaketarik ez
Beraz, Elastic guretzat aukeratu genuen eta trantsiziorako prestatu ginen.
Elastikorako trantsizioa
1. Salmenta puntuko bilaketa zerbitzutik hasi ginen trantsizioa. Gure bezeroak 70 salmenta puntu inguru ditu guztira, eta horretarako hainbat bilaketa mota egin behar dira webgunean eta aplikazioan:
- Testu bilaketa hiriaren izenaren arabera
- Geobilaketa erradio jakin batean puntu batetik aurrera. Adibidez, erabiltzaileak bere etxetik hurbilen dauden salmenta puntuak ikusi nahi baditu.
- Bilatu karratu jakin baten arabera - erabiltzaileak karratu bat marrazten du mapan, eta erradio honetako puntu guztiak erakusten zaizkio.
- Bilatu iragazki gehigarrien bidez. Salmenta puntuak elkarren artean desberdinak dira sorta aldetik
Antolakuntzaz hitz egiten badugu, Postgres-en datu iturri bat dugu bai maparako bai albisterako, eta Elastic Snapshots-en jatorrizko datuetatik hartzen dira. Kontua da hasieran Postgres-ek ezin ziola egin bilaketari irizpide guztien arabera. Indize asko ez ezik, gainjar daitezke, beraz, Postgres programatzailea galdu egin zen eta ez zuen ulertu zein indize erabili.
2. Hurrengo lerroan albisteen atala izan zen. Argitalpenak webgunean egunero agertzen dira, erabiltzailea informazio-fluxuan gal ez dadin, datuak igorri aurretik ordenatu behar dira. Hauxe da bilaketa: gunea bilatu dezakezu testu-partaidetzaren arabera, eta, aldi berean, iragazki osagarriak konektatu, Elastic bidez ere egiten baitira.
3. Ondoren, transakzioen prozesaketa mugitu dugu. Erabiltzaileek produktu jakin bat eros dezakete webgunean eta zozketa batean parte hartu. Horrelako erosketak egin ondoren, datu ugari prozesatzen ditugu, batez ere asteburuetan eta jaiegunetan. Konparazio baterako, egun arruntetan erosketa kopurua 1,5-2 milioi artekoa bada, jaiegunetan kopurua 53 milioira irits daiteke.
Aldi berean, datuak ahalik eta denbora laburrenean prozesatu behar dira - erabiltzaileek ez dute gustuko emaitzaren zain egon hainbat egunetan. Postgres-en bidez ez dago horrelako epeak lortzeko modurik - askotan blokeoak jasotzen genituen, eta eskaera guztiak prozesatzen genituen bitartean, erabiltzaileek ezin zuten egiaztatu sariak jaso zituzten ala ez. Hau ez da oso atsegina negozioarentzat, beraz, Elasticsearch-era eraman dugu prozesatzea.
aldizkakotasun
Orain eguneraketak gertaeren arabera konfiguratzen dira, baldintza hauen arabera:
- Salmenta puntuak. Kanpoko iturri batetik datuak jaso bezain laster, berehala hasiko gara eguneratzea.
- Berriak. Webgunean edozein albiste editatu bezain laster, automatikoki bidaltzen da Elastic-era.
Hemen berriro aipatzekoa da Elastic-en abantailak. Postgres-en, eskaera bat bidaltzean, erregistro guztiak zintzotasunez prozesatu arte itxaron behar duzu. 10 erregistro bidal ditzakezu Elastic-era eta lanean has zaitezke berehala, erregistroak zati guztietan banatuko diren arte itxaron gabe. Jakina, Shard edo Erreplika batzuek ez dituzte datuak berehala ikusiko, baina dena laster egongo da eskuragarri.
Integrazio metodoak
Elastic-en integratzeko 2 modu daude:
- TCP bidezko bezero natibo baten bidez. Jatorrizko gidaria pixkanaka hiltzen ari da: jada ez da onartzen, oso sintaxi deserosoa du. Hori dela eta, ia ez dugu erabiltzen eta guztiz alde batera uzten saiatzen gara.
- JSON eskaerak eta Lucene sintaxia erabil ditzakeen HTTP interfaze baten bidez. Azkena Elastic erabiltzen duen testu-motor bat da. Bertsio honetan, HTTP bidez JSON eskaeren bidez batch egiteko gaitasuna lortzen dugu. Hau da erabiltzen saiatzen ari garen aukera.
HTTP interfazeari esker, HTTP bezeroaren ezarpen asinkronoa eskaintzen duten liburutegiak erabil ditzakegu. Batch eta API asinkronoa aprobetxatu ditzakegu, errendimendu handia eragiten duena, eta horrek asko lagundu zuen promozio handiaren egunetan (hori gehiago behean)
Zenbaki batzuk alderatzeko:
- Postgres Bounty erabiltzaileak 20 haritan gordetzea taldekatu gabe: 460713 erregistro 42 segundotan
- Bezero elastikoa + erreaktiboa 10 haritarako + 1000 elementuren lotea: 596749 erregistro 11 segundotan
- Bezero elastikoa + erreaktiboa 10 haritarako + 1000 elementuren lotea: 23801684 sarrera 4 minututan
Orain, HTTP eskaera-kudeatzailea idatzi dugu, JSON Batch / ez Batch gisa eraikitzen duena eta edozein HTTP bezeroren bidez bidaltzen duena, liburutegia edozein dela ere. Eskaerak modu sinkronoan edo asinkronoan bidaltzea ere aukera dezakezu.
Zenbait integraziotan, garraio-bezero ofiziala erabiltzen dugu oraindik, baina hurrengo birfaktorizazioa baino ez da. Kasu honetan, Spring WebClient-en oinarrituta eraikitako bezero pertsonalizatua erabiltzen da prozesatzeko.
promozio handia
Urtean behin, proiektuak sustapen handi bat egiten du erabiltzaileentzat - Highload bera da, une honetan hamar milioi erabiltzailerekin lan egiten baitugu aldi berean.
Normalean karga-gailurrak oporretan gertatzen dira, baina promozio hau guztiz beste maila batean dago. Aurreko urtean, promozioaren egunean, 27 salgai saldu genituen. Datuak ordu erdi baino gehiagoz prozesatu ziren eta horrek eragozpenak eragin zituen erabiltzaileei. Erabiltzaileek parte hartzeko sariak jaso zituzten, baina argi geratu zen prozesua azkartu beharra zegoela.
2019aren hasieran, ElasticSearch behar genuela erabaki genuen. Urte osoz, jasotako datuen tratamendua Elastic-en eta horien igorpena mugikorretarako aplikazioaren eta webgunearen apian antolatu genuen. Ondorioz, hurrengo urtean kanpainan zehar, tramitatu genuen 15 sarrera 131 minututan.
Salgaiak erosi eta promozioetako sarien zozketan parte hartu nahi duen jende asko daukagunez, hau behin-behineko neurria da. Orain informazio eguneratua bidaltzen ari gara Elastic-era, baina etorkizunean azken hilabeteetako artxibatutako informazioa Postgres-era biltegiratze iraunkor gisa transferitzeko asmoa dugu. Elastiko indizea ez ixteko, horrek ere bere mugak dituela.
Ondorioa/Ondorioak
Momentuz, nahi genituen zerbitzu guztiak Elastic-era transferitu ditugu eta oraingoz honetan eten egin dugu. Orain Elastic-en indize bat eraikitzen ari gara Postgres-en biltegiratze iraunkor nagusiaren gainean, erabiltzailearen karga hartzen duena.
Etorkizunean, zerbitzuak transferitzeko asmoa dugu, baldin eta ulertzen badugu datu-eskaera askotarikoa dela eta zutabe kopuru mugagabea bilatzen bada. Hau jada ez da Postgresen zeregina.
Funtzionalitatean testu osoko bilaketak behar baditugu edo bilaketa-irizpide ezberdin asko baditugu, badakigu hori Elastic-era itzuli behar dela.
βββ
Eskerrik asko irakurtzeagatik. Zure enpresak ElasticSearch ere erabiltzen badu eta bere ezarpen kasuak baditu, esan iezaguzu. Interesgarria izango da besteak nola dauden jakitea π
Iturria: www.habr.com