Hej Habr! Mi nomiĝas Maxim Vasiliev, mi laboras kiel analizisto kaj projektestro ĉe FINCH. Hodiaŭ mi ŝatus rakonti al vi kiel, uzante ElasticSearch, ni povis prilabori 15 milionojn da petoj en 6 minutoj kaj optimumigi la ĉiutagajn ŝarĝojn en la retejo de unu el niaj klientoj. Bedaŭrinde, ni devos malhavi nomojn, ĉar ni havas NDA, ni esperas, ke la enhavo de la artikolo ne suferos pro tio. Ni iru.
Kiel funkcias la projekto
En nia backend, ni kreas servojn, kiuj certigas la agadon de la retejoj kaj moveblaj aplikoj de nia kliento. La ĝenerala strukturo povas esti vidita en la diagramo:
En la procezo de laboro, ni prilaboras grandan nombron da transakcioj: aĉetoj, pagoj, operacioj kun uzantekvilibroj, por kiuj ni stokas multajn protokolojn, kaj ankaŭ importas kaj eksportas ĉi tiujn datumojn al eksteraj sistemoj.
Estas ankaŭ inversaj procezoj kiam ni ricevas datumojn de la kliento kaj transdonas ĝin al la uzanto. Krome, ekzistas ankoraŭ procezoj por labori kun pagoj kaj bonusaj programoj.
Mallonga fono
Komence, ni uzis PostgreSQL kiel la solan datumvendejon. Ĝiaj normaj avantaĝoj por DBMS: la ĉeesto de transakcioj, evoluinta datuma specimenlingvo, larĝa gamo de iloj por integriĝo; kombinita kun bona agado kontentigis niajn bezonojn dum sufiĉe longa tempo.
Ni stokis absolute ĉiujn datumojn en Postgres: de transakcioj ĝis novaĵoj. Sed la nombro da uzantoj kreskis, kaj kun ĝi la nombro da petoj.
Por kompreno, la jara nombro da sesioj en 2017 nur sur la labortabla retejo estas 131 milionoj En 2018 - 125 milionoj 2019 denove 130 milionoj Aldonu pliajn 100-200 milionojn el la movebla versio de la retejo kaj la poŝtelefona aplikaĵo, kaj vi ricevos grandegan nombron da petoj.
Kun la kresko de la projekto, Postgres ĉesis trakti la ŝarĝon, ni ne havis tempon - aperis granda nombro da diversaj demandoj, por kiuj ni ne povis krei sufiĉan nombron da indeksoj.
Ni komprenis, ke necesas aliaj datumbutikoj, kiuj provizos niajn bezonojn kaj malŝarĝus PostgreSQL. Elasticsearch kaj MongoDB estis konsideritaj kiel eblaj opcioj. Ĉi-lasta perdis je la sekvaj punktoj:
- Malrapida indeksa rapideco dum la kvanto da datumoj en indeksoj kreskas. Kun Elastic, la rapideco ne dependas de la kvanto da datumoj.
- Neniu plenteksta serĉo
Do ni elektis Elastic por ni mem kaj prepariĝis por la transiro.
Transiro al Elasta
1. Ni komencis la transiron de la venda servo de serĉo. Nia kliento havas entute ĉirkaŭ 70 vendopunktojn, kaj ĉi tio postulas plurajn specojn de serĉoj en la retejo kaj en la aplikaĵo:
- Tekstserĉo laŭ urbonomo
- Geoserĉo ene de antaŭfiksita radiuso de iu punkto. Ekzemple, se la uzanto volas vidi, kiuj vendejoj estas plej proksimaj al sia hejmo.
- Serĉu laŭ donita kvadrato - la uzanto desegnas kvadraton sur la mapo, kaj ĉiuj punktoj en ĉi tiu radiuso estas montritaj al li.
- Serĉu per pliaj filtriloj. Vendpunktoj diferencas unu de la alia laŭ sortimento
Se ni parolas pri la organizo, tiam en Postgres ni havas datumfonton por kaj la mapo kaj la novaĵoj, kaj en Elastic Snapshots estas prenitaj el la originaj datumoj. La fakto estas, ke komence Postgres ne povis elteni la serĉon laŭ ĉiuj kriterioj. Ne nur estis multaj indeksoj, ili ankaŭ povus interkovri, do la postgresplanilo perdiĝis kaj ne komprenis kiun indekson uzi.
2. Sekva en la vico estis la novaĵsekcio. Publikaĵoj aperas en la retejo ĉiutage, por ke la uzanto ne perdiĝu en la fluo de informoj, la datumoj devas esti ordigitaj antaŭ ol elsendi. Jen kion serĉas serĉo: vi povas serĉi la retejon laŭ teksta kongruo, kaj samtempe konekti pliajn filtrilojn, ĉar ili ankaŭ estas faritaj per Elastic.
3. Tiam ni movis la transakcian prilaboradon. Uzantoj povas aĉeti certan produkton en la retejo kaj partopreni premion. Post tiaj aĉetoj, ni prilaboras grandan kvanton da datumoj, precipe dum semajnfinoj kaj ferioj. Por komparo, se en ordinaraj tagoj la nombro da aĉetoj estas ie inter 1,5-2 milionoj, tiam dum ferioj la cifero povas atingi 53 milionojn.
Samtempe, la datumoj devas esti prilaboritaj en la plej mallonga ebla tempo - uzantoj ne ŝatas atendi la rezulton dum pluraj tagoj. Ne ekzistas maniero atingi tiajn limdatojn per Postgres - ni ofte ricevis serurojn, kaj dum ni pritraktis ĉiujn petojn, uzantoj ne povis kontroli ĉu ili ricevis premiojn aŭ ne. Ĉi tio ne estas tre agrabla por komerco, do ni movis la prilaboradon al Elasticsearch.
Periodeco
Nun ĝisdatigoj estas agorditaj evento-bazitaj, laŭ la sekvaj kondiĉoj:
- Vendaj punktoj. Tuj kiam ni ricevas datumojn de ekstera fonto, ni tuj komencas la ĝisdatigon.
- Novaĵoj. Tuj kiam iu novaĵo estas redaktata en la retejo, ĝi estas aŭtomate sendita al Elastic.
Ĉi tie denove indas mencii la avantaĝojn de Elastic. En Postgres, kiam vi sendas peton, vi devas atendi ĝis ĝi honeste prilaboras ĉiujn rekordojn. Vi povas sendi 10 rekordojn al Elastic kaj komenci labori tuj, sen atendi ke la rekordoj estos distribuitaj tra ĉiuj Fragaĵoj. Kompreneble, iuj fragmentoj aŭ kopioj eble ne vidos la datumojn tuj, sed ĉio estos disponebla tre baldaŭ.
Integrigaj metodoj
Estas 2 manieroj integriĝi kun Elastic:
- Tra denaska kliento super TCP. La denaska ŝoforo iom post iom formortas: ĝi ne plu estas subtenata, ĝi havas tre maloportunan sintakson. Tial ni praktike ne uzas ĝin kaj provas tute forlasi ĝin.
- Per HTTP-interfaco kiu povas uzi kaj JSON-petojn kaj Lucene-sintakso. La lasta estas teksta motoro, kiu uzas Elastic. En ĉi tiu versio, ni ricevas la kapablon Batch per JSON-petoj per HTTP. Ĉi tiu estas la opcio, kiun ni provas uzi.
Danke al la HTTP-interfaco, ni povas uzi bibliotekojn, kiuj provizas nesinkronan efektivigon de la HTTP-kliento. Ni povas utiligi Batch kaj la nesinkronan API, kiu rezultigas altan rendimenton, kio multe helpis en la tagoj de la granda promocio (pli pri tio ĉi sube)
Kelkaj nombroj por komparo:
- Konservado de postgresaj premio-uzantoj en 20 fadenoj sen grupigo: 460713 rekordoj en 42 sekundoj
- Elasta + reaktiva kliento por 10 fadenoj + aro por 1000 elementoj: 596749 registroj en 11 sekundoj
- Elasta + reaktiva kliento por 10 fadenoj + aro por 1000 elementoj: 23801684 enskriboj en 4 minutoj
Nun ni skribis HTTP-peton-administranton, kiu konstruas JSON kiel Batch/ne Batch kaj sendas ĝin per iu HTTP-kliento, sendepende de la biblioteko. Vi ankaŭ povas elekti sendi petojn sinkrone aŭ nesinkrone.
En iuj integriĝoj, ni ankoraŭ uzas la oficialan transportklienton, sed ĉi tio estas nur afero de la sekva refaktorado. En ĉi tiu kazo, kutima kliento konstruita surbaze de Spring WebClient estas uzata por prilaborado.
granda promocio
Unufoje jare, la projekto aranĝas grandan reklamadon por uzantoj - ĉi tio estas la sama Highload, ĉar nuntempe ni laboras kun dekoj da milionoj da uzantoj samtempe.
Kutime pintoj de ŝarĝoj okazas dum la ferioj, sed ĉi tiu promocio estas sur tute alia nivelo. La antaŭan jaron, en la tago de la promocio, ni vendis 27 580 890 ekzemplerojn da varoj. La datumoj estis prilaboritaj dum pli ol duonhoro, kio kaŭzis ĝenojn por uzantoj. Uzantoj ricevis premiojn pro partopreno, sed evidentiĝis, ke necesas akceli la procezon.
Komence de 2019, ni decidis, ke ni bezonas ElasticSearch. Dum tuta jaro, ni organizis la prilaboradon de la ricevitaj datumoj en Elastic kaj ilian elsendon en la api de la poŝtelefona aplikaĵo kaj retejo. Rezulte, la venontan jaron dum la kampanjo, ni prilaboris 15 enskriboj en 131 minutoj.
Ĉar ni havas multajn homojn, kiuj volas aĉeti varojn kaj partopreni en la tirado de premioj en promocioj, ĉi tio estas provizora mezuro. Nun ni sendas ĝisdatajn informojn al Elastic, sed estonte ni planas transdoni arkivitajn informojn de la pasintaj monatoj al Postgres kiel konstanta stokado. Por ne ŝtopi la Elastan indicon, kiu ankaŭ havas siajn limojn.
Konkludo/Konkludoj
Nuntempe, ni transdonis ĉiujn servojn, kiujn ni deziris al Elastic kaj paŭzis pri tio nuntempe. Nun ni konstruas indekson en Elastic super la ĉefa konstanta stokado en Postgres, kiu transprenas la uzantŝarĝon.
En la estonteco, ni planas translokigi servojn se ni komprenas, ke la datumpeto fariĝas tro diversa kaj estas serĉata senlima nombro da kolumnoj. Ĉi tio ne plu estas tasko por Postgres.
Se ni bezonas plentekstan serĉon en funkcieco aŭ se ni havas multajn malsamajn serĉkriteriojn, tiam ni jam scias, ke ĉi tio devas esti tradukita en Elastikon.
⌘⌘⌘
Dankon pro legado. Se via kompanio ankaŭ uzas ElasticSearch kaj havas siajn proprajn efektivigajn kazojn, tiam diru al ni. Estos interese scii kiel aliaj estas 🙂
fonto: www.habr.com