Hæ Habr! Ég heiti Maxim Vasiliev, ég vinn sem sérfræðingur og verkefnastjóri hjá FINCH. Í dag langar mig að segja þér hvernig við, með því að nota ElasticSearch, gátum afgreitt 15 milljónir beiðna á 6 mínútum og fínstillt daglegt álag á síðu eins viðskiptavinar okkar. Því miður verðum við að vera án nafna, þar sem við erum með NDA, vonum við að innihald greinarinnar verði ekki fyrir þessu. Förum.
Hvernig verkefnið virkar
Á bakenda okkar búum við til þjónustu sem tryggir frammistöðu vefsíður viðskiptavinar okkar og farsímaforrit. Almenna uppbyggingu má sjá á skýringarmyndinni:
Í vinnuferlinu vinnum við úr miklum fjölda viðskipta: innkaupum, greiðslum, aðgerðum með notendastöðu, sem við geymum mikið af annálum fyrir, auk þess að flytja inn og flytja þessi gögn inn í ytri kerfi.
Það eru líka öfug ferli þegar við fáum gögn frá viðskiptavininum og flytjum þau til notandans. Að auki eru enn ferlar til að vinna með greiðslur og bónusforrit.
Stutt bakgrunnur
Upphaflega notuðum við PostgreSQL sem eina gagnageymsluna. Staðlaðir kostir þess fyrir DBMS: tilvist viðskipta, þróað gagnasýnatökumál, fjölbreytt úrval verkfæra til samþættingar; ásamt góðri frammistöðu fullnægði þörfum okkar í nokkuð langan tíma.
Við geymdum nákvæmlega öll gögn í Postgres: frá viðskiptum til frétta. En notendum fjölgaði og þar með fjöldi beiðna.
Til skilnings er árlegur fjöldi lota árið 2017 aðeins á skjáborðssíðunni 131 milljón. Árið 2018 - 125 milljónir. 2019 aftur 130 milljónir. Bættu við 100-200 milljónum frá farsímaútgáfu síðunnar og farsímaforritinu og þú mun fá gríðarlegan fjölda beiðna.
Með vexti verkefnisins hætti Postgres að takast á við álagið, við höfðum ekki tíma - fjöldinn allur af ýmsum fyrirspurnum birtist, sem við gátum ekki búið til nægilega marga vísitölur fyrir.
Við skildum að það væri þörf fyrir aðrar gagnageymslur sem myndu veita þörfum okkar og taka álagið af PostgreSQL. Elasticsearch og MongoDB voru talin mögulegir valkostir. Sá síðarnefndi tapaði á eftirfarandi stigum:
- Hægur verðtryggingarhraði eftir því sem gagnamagn í vísitölum eykst. Með Elastic fer hraðinn ekki eftir gagnamagni.
- Engin fulltextaleit
Svo við völdum Elastic fyrir okkur og undirbjuggum okkur fyrir umskiptin.
Umskipti í teygjanlegt
1. Við byrjuðum á umskiptum frá leitarþjónustu á sölustöðum. Viðskiptavinur okkar hefur samtals um 70 sölustaði og til þess þarf nokkrar tegundir af leit á síðunni og í forritinu:
- Textaleit eftir borgarnafni
- Jarðleit innan ákveðins radíuss frá einhverjum tímapunkti. Til dæmis ef notandi vill sjá hvaða sölustaðir eru næst heimili hans.
- Leitaðu eftir tilteknum ferningi - notandinn teiknar ferning á kortinu og allir punktar í þessum radíus eru sýndir honum.
- Leitaðu með viðbótarsíum. Sölustaðir eru ólíkir hver öðrum í úrvali
Ef við tölum um skipulagið þá erum við í Postgres með gagnagjafa fyrir bæði kortið og fréttirnar og í Elastic Snapshots eru teknar úr upprunalegu gögnunum. Staðreyndin er sú að upphaflega gat Postgres ekki tekist á við leitina með öllum forsendum. Ekki aðeins voru margar vísitölur, þær gætu líka skarast, þannig að Postgres tímaáætlunin týndist og skildi ekki hvaða vísitölu ætti að nota.
2. Næstur í röðinni var fréttakaflinn. Rit birtast á síðunni á hverjum degi svo notandinn villist ekki í upplýsingaflæðinu, flokka þarf gögnin fyrir útgáfu. Þetta er það sem leitin er að: þú getur leitað á síðunni eftir textasamsvörun og á sama tíma tengt viðbótarsíur, þar sem þær eru einnig gerðar í gegnum Elastic.
3. Síðan færðum við færsluvinnsluna. Notendur geta keypt ákveðna vöru á síðunni og tekið þátt í útdrætti. Eftir slík kaup vinnum við mikið magn gagna, sérstaklega um helgar og á hátíðum. Til samanburðar, ef á venjulegum dögum er fjöldi innkaupa einhvers staðar á milli 1,5-2 milljónir, þá á hátíðum getur talan orðið 53 milljónir.
Á sama tíma þarf að vinna úr gögnunum á sem skemmstum tíma - notendum líkar ekki að bíða eftir niðurstöðunni í nokkra daga. Það er engin leið að ná slíkum fresti í gegnum Postgres - við fengum oft læsingar og á meðan við vorum að vinna úr öllum beiðnum gátu notendur ekki athugað hvort þeir fengju verðlaun eða ekki. Þetta er ekki mjög skemmtilegt fyrir fyrirtæki, svo við færðum vinnsluna yfir á Elasticsearch.
Tímabil
Nú eru uppfærslur stilltar atburðamiðaðar, samkvæmt eftirfarandi skilyrðum:
- Sölustaðir. Um leið og við fáum gögn frá utanaðkomandi aðilum byrjum við strax á uppfærslunni.
- Fréttir. Um leið og einhverjum fréttum er breytt á síðunni eru þær sendar sjálfkrafa á Elastic.
Hér er aftur rétt að minnast á kosti Elastic. Í Postgres, þegar þú sendir beiðni, þarftu að bíða þar til það vinnur heiðarlega úr öllum gögnum. Þú getur sent 10 færslur til Elastic og byrjað að vinna strax, án þess að bíða eftir að færslunum sé dreift yfir allar Shards. Auðvitað geta sumir Shard eða Replica ekki séð gögnin strax, en allt verður tiltækt mjög fljótlega.
Samþættingaraðferðir
Það eru 2 leiðir til að samþætta Elastic:
- Í gegnum innfæddan viðskiptavin yfir TCP. Innfæddur bílstjóri er smám saman að deyja út: hann er ekki lengur studdur, hann hefur mjög óþægilega setningafræði. Þess vegna notum við það nánast ekki og reynum að yfirgefa það algjörlega.
- Í gegnum HTTP viðmót sem getur notað bæði JSON beiðnir og Lucene setningafræði. Sú síðasta er textavél sem notar Elastic. Í þessari útgáfu fáum við getu til að hópa í gegnum JSON beiðnir yfir HTTP. Þetta er valkosturinn sem við erum að reyna að nota.
Þökk sé HTTP viðmótinu getum við notað bókasöfn sem veita ósamstillta útfærslu á HTTP biðlaranum. Við getum nýtt okkur Batch og ósamstilltu API, sem skilar miklum afköstum, sem hjálpaði mikið á dögum stóru kynningarinnar (meira um það hér að neðan)
Nokkrar tölur til samanburðar:
- Vistar Postgres bounty notendur í 20 þræði án flokkunar: 460713 færslur á 42 sekúndum
- Teygjanlegur + hvarfgjarn viðskiptavinur fyrir 10 þræði + lotu fyrir 1000 þætti: 596749 færslur á 11 sekúndum
- Teygjanlegur + hvarfgjarn viðskiptavinur fyrir 10 þræði + lotu fyrir 1000 þætti: 23801684 færslur á 4 mínútum
Nú höfum við skrifað HTTP beiðnistjóra sem byggir JSON sem Batch / ekki Batch og sendir það í gegnum hvaða HTTP viðskiptavin sem er, óháð bókasafni. Þú getur líka valið að senda beiðnir samstillt eða ósamstillt.
Í sumum samþættingum notum við enn opinbera flutningsmiðilinn, en þetta er bara spurning um næstu endurnýjun. Í þessu tilviki er sérsniðinn viðskiptavinur byggður á Spring WebClient notaður til vinnslu.
stór kynning
Einu sinni á ári hýsir verkefnið stóra kynningu fyrir notendur - þetta er sama Highload, þar sem á þessum tíma vinnum við með tugum milljóna notenda á sama tíma.
Yfirleitt verða álagstoppar yfir hátíðirnar, en þessi kynning er á allt öðru stigi. Árið áður, á kynningardegi, seldum við 27 einingar af vörum. Unnið var með gögnin í meira en hálftíma sem olli notendum óþægindum. Notendur fengu verðlaun fyrir þátttöku en ljóst var að flýta þurfti ferlinu.
Í byrjun árs 2019 ákváðum við að við þyrftum ElasticSearch. Í heilt ár skipulögðum við vinnslu móttekinna gagna í Elastic og útgáfu þeirra í api farsímaforritsins og vefsíðunnar. Þar af leiðandi, næsta ár í átakinu, unnum við 15 færslur á 131 mínútum.
Þar sem við eigum fullt af fólki sem vill kaupa vörur og taka þátt í útdrætti vinninga í kynningum er þetta tímabundin ráðstöfun. Nú erum við að senda uppfærðar upplýsingar til Elastic en í framtíðinni ætlum við að flytja geymsluupplýsingar undanfarna mánuði yfir á Postgres sem varanlega geymslu. Til þess að stífla ekki teygjuvísitöluna, sem hefur líka sínar takmarkanir.
Niðurstaða/Ályktanir
Í augnablikinu höfum við flutt alla þá þjónustu sem við vildum yfir á Elastic og höfum gert hlé á þessu í bili. Nú erum við að byggja vísitölu í Elastic ofan á aðal viðvarandi geymsluna í Postgres sem tekur yfir notendaálagið.
Í framtíðinni ætlum við að flytja þjónustu ef við skiljum að gagnabeiðnin verður of fjölbreytt og leitað er í ótakmarkaðan fjölda dálka. Þetta er ekki lengur verkefni fyrir Postgres.
Ef okkur vantar fulltextaleit í virkni eða ef við höfum mikið af mismunandi leitarskilyrðum, þá vitum við nú þegar að þetta þarf að þýða yfir á Elastic.
⌘⌘⌘
Takk fyrir að lesa. Ef fyrirtækið þitt notar líka ElasticSearch og hefur sín eigin innleiðingartilvik, segðu okkur þá. Það verður fróðlegt að vita hvernig aðrir hafa það 🙂
Heimild: www.habr.com