Habari Habr! Jina langu ni Maxim Vasiliev, ninafanya kazi kama mchambuzi na meneja wa mradi huko FINCH. Leo ningependa kukuambia jinsi, kwa kutumia ElasticSearch, tuliweza kuchakata maombi milioni 15 kwa dakika 6 na kuboresha mizigo ya kila siku kwenye tovuti ya mmoja wa wateja wetu. Kwa bahati mbaya, tutalazimika kufanya bila majina, kwa kuwa tunayo NDA, tunatumai kuwa yaliyomo kwenye kifungu hicho hayatateseka na hii. Twende zetu.
Jinsi mradi unavyofanya kazi
Kwa upande wetu, tunaunda huduma zinazohakikisha utendakazi wa tovuti za mteja wetu na programu ya simu ya mkononi. Muundo wa jumla unaweza kuonekana kwenye mchoro:
Katika mchakato wa kazi, tunasindika idadi kubwa ya shughuli: ununuzi, malipo, shughuli na mizani ya watumiaji, ambayo tunahifadhi kumbukumbu nyingi, pamoja na kuagiza na kuuza nje data hii kwa mifumo ya nje.
Pia kuna michakato ya kurudi nyuma tunapopokea data kutoka kwa mteja na kuihamisha kwa mtumiaji. Kwa kuongeza, bado kuna taratibu za kufanya kazi na malipo na mipango ya ziada.
Mandhari fupi
Hapo awali, tulitumia PostgreSQL kama hifadhi pekee ya data. Faida zake za kawaida kwa DBMS: uwepo wa shughuli, lugha ya sampuli ya data iliyoendelezwa, zana mbalimbali za ushirikiano; pamoja na utendaji mzuri ulitosheleza mahitaji yetu kwa muda mrefu.
Tulihifadhi data yote kabisa katika Postgres: kutoka kwa shughuli za ununuzi hadi habari. Lakini idadi ya watumiaji ilikua, na kwa hiyo idadi ya maombi.
Kwa uelewa, idadi ya kila mwaka ya vikao mwaka 2017 tu kwenye tovuti ya desktop ni milioni 131. Mnamo 2018 - milioni 125. 2019 tena milioni 130. Ongeza milioni 100-200 nyingine kutoka kwa toleo la simu la tovuti na programu ya simu, na wewe utapata idadi kubwa ya maombi.
Pamoja na ukuaji wa mradi huo, Postgres aliacha kukabiliana na mzigo, hatukuwa na muda - idadi kubwa ya maswali mbalimbali ilionekana, ambayo hatukuweza kuunda idadi ya kutosha ya indexes.
Tulielewa kuwa kulikuwa na haja ya hifadhi nyingine za data ambazo zingetoa mahitaji yetu na kuondoa mzigo kwenye PostgreSQL. Elasticsearch na MongoDB zilizingatiwa kama chaguo zinazowezekana. Wa pili walipoteza kwa pointi zifuatazo:
- Kasi ya polepole ya kuorodhesha kadri idadi ya data katika faharasa inavyoongezeka. Kwa Elastic, kasi haitegemei kiasi cha data.
- Hakuna utafutaji kamili wa maandishi
Kwa hivyo tulijichagulia Elastic na tukajitayarisha kwa mpito.
Mpito kwa Elastiki
1. Tulianza mpito kutoka kwa huduma ya utafutaji ya mauzo. Mteja wetu ana jumla ya pointi 70 za mauzo, na hii inahitaji aina kadhaa za utafutaji kwenye tovuti na katika maombi:
- Tafuta maandishi kwa jina la jiji
- Geosearch ndani ya eneo fulani kutoka sehemu fulani. Kwa mfano, ikiwa mtumiaji anataka kuona ni sehemu gani za mauzo ziko karibu na nyumba yake.
- Tafuta kwa mraba uliopeanwa - mtumiaji huchota mraba kwenye ramani, na alama zote kwenye eneo hili zinaonyeshwa kwake.
- Tafuta kwa vichujio vya ziada. Pointi za mauzo hutofautiana kutoka kwa kila mmoja kwa urval
Ikiwa tunazungumza juu ya shirika, basi katika Postgres tuna chanzo cha data kwa ramani na habari, na katika Vijisehemu vya Elastic huchukuliwa kutoka kwa data asili. Ukweli ni kwamba awali Postgres hakuweza kukabiliana na utafutaji kwa vigezo vyote. Sio tu kwamba kulikuwa na faharisi nyingi, zingeweza pia kuingiliana, kwa hivyo kipanga ratiba cha Postgres kilipotea na hakuelewa ni faharasa gani ya kutumia.
2. Kilichofuata kwenye mstari kilikuwa sehemu ya habari. Machapisho yanaonekana kwenye tovuti kila siku ili mtumiaji asipotee katika mtiririko wa habari, data lazima ipangwa kabla ya kutoa. Hii ndiyo utafutaji wa utafutaji: unaweza kutafuta tovuti kwa mechi ya maandishi, na wakati huo huo kuunganisha filters za ziada, kwa vile pia zinafanywa kwa njia ya Elastic.
3. Kisha tukahamisha usindikaji wa shughuli. Watumiaji wanaweza kununua bidhaa fulani kwenye tovuti na kushiriki katika droo ya zawadi. Baada ya ununuzi kama huo, tunachakata data nyingi, haswa wikendi na likizo. Kwa kulinganisha, ikiwa kwa siku za kawaida idadi ya ununuzi ni mahali fulani kati ya milioni 1,5-2, basi kwenye likizo takwimu inaweza kufikia milioni 53.
Wakati huo huo, data lazima ifanyike kwa muda mfupi iwezekanavyo - watumiaji hawapendi kusubiri matokeo kwa siku kadhaa. Hakuna njia ya kufikia makataa kama haya kupitia Postgres - mara nyingi tulipokea kufuli, na tulipokuwa tukishughulikia maombi yote, watumiaji hawakuweza kuangalia ikiwa walipokea zawadi au la. Hii haipendezi sana kwa biashara, kwa hivyo tulihamisha uchakataji hadi Elasticsearch.
Periodicity
Sasa sasisho zimesanidiwa kulingana na tukio, kulingana na masharti yafuatayo:
- Pointi za mauzo. Mara tu tunapopokea data kutoka kwa chanzo cha nje, tunaanza sasisho mara moja.
- Habari. Mara tu habari yoyote inapohaririwa kwenye tovuti, inatumwa kiotomatiki kwa Elastic.
Hapa tena inafaa kutaja faida za Elastic. Katika Postgres, wakati wa kutuma ombi, unapaswa kusubiri hadi ichakate rekodi zote kwa uaminifu. Unaweza kutuma rekodi 10 kwa Elastic na uanze kufanya kazi mara moja, bila kungoja rekodi hizo kusambazwa kwenye Shards zote. Bila shaka, baadhi ya Shard au Replica wanaweza wasione data mara moja, lakini kila kitu kitapatikana hivi karibuni.
Mbinu za ujumuishaji
Kuna njia 2 za kuunganishwa na Elastic:
- Kupitia mteja asilia kupitia TCP. Dereva asilia anakufa polepole: haitumiki tena, ina syntax isiyofaa sana. Kwa hivyo, kwa kweli hatuitumii na kujaribu kuiacha kabisa.
- Kupitia kiolesura cha HTTP ambacho kinaweza kutumia maombi ya JSON na syntax ya Lucene. Ya mwisho ni injini ya maandishi inayotumia Elastic. Katika toleo hili, tunapata uwezo wa Kukusanya kupitia maombi ya JSON kupitia HTTP. Hili ndilo chaguo tunalojaribu kutumia.
Shukrani kwa kiolesura cha HTTP, tunaweza kutumia maktaba zinazotoa utekelezaji usiolingana wa kiteja cha HTTP. Tunaweza kuchukua fursa ya Kundi na API isiyolingana, ambayo husababisha utendaji wa juu, ambao ulisaidia sana katika siku za ukuzaji mkubwa (zaidi juu ya hiyo hapa chini)
Nambari kadhaa za kulinganisha:
- Kuokoa watumiaji wa fadhila ya Postgres katika nyuzi 20 bila kupanga vikundi: rekodi 460713 katika sekunde 42
- Elastic + mteja tendaji kwa nyuzi 10 + kundi la vitu 1000: rekodi 596749 katika sekunde 11
- Elastic + mteja tendaji kwa nyuzi 10 + bechi kwa vitu 1000: Maingizo 23801684 ndani ya dakika 4
Sasa tumeandika kidhibiti cha ombi la HTTP ambacho huunda JSON kama Batch/not Batch na kuituma kupitia kiteja chochote cha HTTP, bila kujali maktaba. Unaweza pia kuchagua kutuma maombi kwa usawa au kwa usawa.
Katika baadhi ya miunganisho, bado tunatumia mteja rasmi wa usafiri, lakini hili ni suala la urekebishaji unaofuata. Katika kesi hii, mteja wa kawaida aliyejengwa kwa misingi ya Spring WebClient hutumiwa kwa usindikaji.
kukuza kubwa
Mara moja kwa mwaka, mradi huandaa ofa kubwa kwa watumiaji - hii ni Highload sawa, kwani kwa wakati huu tunafanya kazi na makumi ya mamilioni ya watumiaji kwa wakati mmoja.
Kawaida kilele cha mizigo hutokea wakati wa likizo, lakini ukuzaji huu ni kwa kiwango tofauti kabisa. Mwaka mmoja kabla ya hapo, siku ya ofa, tuliuza bidhaa 27. Data ilichakatwa kwa zaidi ya nusu saa, jambo ambalo lilisababisha usumbufu kwa watumiaji. Watumiaji walipokea zawadi kwa ushiriki, lakini ikawa wazi kuwa mchakato unahitajika kuharakishwa.
Mwanzoni mwa 2019, tuliamua kwamba tunahitaji ElasticSearch. Kwa mwaka mzima, tulipanga usindikaji wa data iliyopokelewa katika Elastic na utoaji wao katika api ya programu ya simu na tovuti. Matokeo yake, mwaka uliofuata wakati wa kampeni, tulishughulikia Maingizo 15 ndani ya dakika 131.
Kwa kuwa tuna watu wengi ambao wanataka kununua bidhaa na kushiriki katika kuchora zawadi katika matangazo, hii ni hatua ya muda. Sasa tunatuma maelezo ya hivi punde kwa Elastic, lakini katika siku zijazo tunapanga kuhamisha maelezo yaliyohifadhiwa kwa miezi iliyopita hadi Postgres kama hifadhi ya kudumu. Ili sio kuziba index ya Elastic, ambayo pia ina vikwazo vyake.
Hitimisho/Hitimisho
Kwa sasa, tumehamisha huduma zote ambazo tulitaka kwa Elastic na tumesitisha kwa hili kwa sasa. Sasa tunaunda faharasa katika Elastic juu ya hifadhi kuu inayoendelea katika Postgres, ambayo inachukua mzigo wa mtumiaji.
Katika siku zijazo, tunapanga kuhamisha huduma ikiwa tunaelewa kuwa ombi la data linakuwa tofauti sana na hutafutwa kwa idadi isiyo na kikomo ya safu wima. Hili si jukumu tena kwa Postgres.
Ikiwa tunahitaji utafutaji wa maandishi kamili katika utendakazi au ikiwa tuna vigezo vingi tofauti vya utafutaji, basi tunajua tayari kwamba hii inahitaji kutafsiriwa katika Elastic.
βββ
Asante kwa kusoma. Ikiwa kampuni yako pia inatumia ElasticSearch na ina kesi zake za utekelezaji, basi tuambie. Itakuwa ya kuvutia kujua jinsi wengine walivyo π
Chanzo: mapenzi.com