Sprievodca pochopením vzorov škálovania databázy

Existuje veľa článkov online, ktoré popisujú vzory škálovateľnosti databázy, ale väčšinou ide o roztrúsené články - iba o techniky, ktoré sú definované náhodne bez väčších súvislostí. Zistil som, že nie sú definované krok za krokom, a nediskutujem o tom, kedy zvoliť, ktorá možnosť škálovania je dostupná, ktoré možnosti škálovania sú v praxi uskutočniteľné a prečo.

Preto plánujem podrobne rozobrať niektoré z techník v budúcich článkoch. Na začiatok mám pocit, že je lepšie, ak diskutujem o postupných technikách s nejakým kontextom po svojom. Tento článok je na vysokej úrovni - nebudem tu podrobne rozoberať techniky škálovania, ale poskytnem prehľad. Tak poďme na to.

Prípadová štúdia

Predpokladajme, že ste si vytvorili startup, ktorý ponúka zdieľanie jázd za lacnú cenu. Spočiatku, keď začínate, zacieľujete na mesto a sotva máte po svojej počiatočnej reklame desiatky zákazníkov.

Uložíte všetkých zákazníkov, cesty, polohy, údaje o rezerváciách a históriu ciest zákazníkov do jednej databázy alebo s najväčšou pravdepodobnosťou do jedného fyzického stroja. Na vyriešenie problémov nie je potrebné vymyslené ukladanie do vyrovnávacej pamäte ani veľký objem dát, pretože vaša aplikácia je veľmi nová. To je v tejto chvíli ideálne riešenie pre váš prípad použitia, pretože je len veľmi málo zákazníkov a váš systém napríklad ťažko rezervuje 1 cestu za 5 minút.

Postupom času sa však do vášho systému začne prihlasovať viac ľudí, pretože ste najlacnejšou službou na trhu a vďaka vašej propagácii a reklamám. Začnete rezervovať povedzme 10 rezervácií za minútu a pomaly sa ich počet zvyšuje na 20, 30 rezervácií za minútu.

V tejto chvíli si uvedomíte, že systém začal pracovať zle: latencia API sa výrazne zvýšila a niektoré transakcie uviazli alebo hladovali a nakoniec zlyhali. Vaša aplikácia si vyžaduje viac času na odpoveď, čo spôsobuje nespokojnosť zákazníkov. Čo môžete urobiť na vyriešenie problému?

Vzor 1 - Optimalizácia dotazov a implementácia skupiny pripojení:

Prvé riešenie, ktoré vás napadne, je, že vyrovnávacia pamäť často používa nedynamické údaje, ako je história rezervácií, história platieb, profily používateľov atď. Ale po tomto uložení do medzipamäte aplikačnej vrstvy nemôžete vyriešiť problém latencie rozhraní API vystavujúcich dynamické údaje, ako je napríklad umiestnenie aktuálneho ovládača alebo najbližšie kabíny pre daného zákazníka alebo aktuálne náklady na cestu v určitom okamihu po začiatku cesty.

Zistíte, že vaša databáza je pravdepodobne silne normalizovaná, a preto z dôvodu denormalizácie zavediete do vysoko používaných tabuliek niektoré nadbytočné stĺpce (tieto stĺpce sa často vyskytujú WHEREalebo sa v nich uvádzajú JOIN ONklauzuly). To redukuje počet dotazov na spojenie, rozdeľuje veľký dotaz na niekoľko menších dotazov a výsledky sa sčítajú v aplikačnej vrstve.

Ďalšou paralelnou optimalizáciou, ktorú môžete urobiť, je doladenie pripojení k databáze. Knižnice databázových klientov a externé knižnice sú dostupné takmer vo všetkých programovacích jazykoch. Knižnice fondu pripojení môžete použiť na medzipamäť databázových pripojení, alebo môžete nakonfigurovať veľkosť oblasti pripojení v samotnom systéme správy databáz.

Vytvorenie ľubovoľného sieťového pripojenia je nákladné, pretože si vyžaduje určitú spätnú komunikáciu medzi klientom a serverom. Zdieľanie pripojení vám môže pomôcť optimalizovať počet pripojení. Knižnice fondu pripojení vám môžu pomôcť pri multiplexnom pripojení - to isté databázové pripojenie môže používať viac aplikačných vlákien. Uvidím, či budem môcť neskôr podrobne vysvetliť združovanie pripojení v samostatnom článku.

Zmerajte latenciu svojich API a nájdite pravdepodobne o 20–50% alebo viac zníženú latenciu. To je v tomto okamihu dobrá optimalizácia.

Teraz ste rozšírili svoje podnikanie do jedného mesta, zaregistrujete sa viac zákazníkov a pomaly začnete robiť 80–100 rezervácií za minútu. Váš systém nie je schopný zvládnuť túto stupnicu. Opäť vidíte, že sa zvýšila latencia API, databázová vrstva sa vzdala, ale tentoraz vám žiadna optimalizácia dotazu neprináša žiadny výrazný nárast výkonu. Skontrolujete systémovú metriku a zistíte, že miesto na disku je takmer plné, procesor je 80% zaneprázdnený, pamäť RAM sa plní veľmi rýchlo.

Vzor 2 - Vertikálne zväčšenie alebo zväčšenie:

Po preskúmaní všetkých metrík systému viete, že neexistuje iné ľahké riešenie ako aktualizácia hardvéru systému. Veľkosť pamäte RAM si upgradujete dvakrát, miesto na disku povedzme trikrát alebo viac. Toto sa nazýva vertikálne zväčšenie alebo zväčšenie vášho systému. O aktualizácii vášho stroja informujete svoj tím infraštruktúry alebo tím vývojárov alebo agentov dátových centier tretích strán.

Ako však nastavíte stroj na vertikálne zväčšenie?

Pridelíte väčší stroj. Jedným z prístupov je nemigrovať údaje manuálne zo starého počítača, radšej nastaviť nový počítač replicana existujúci počítač ( primary) - vytvoriť dočasnú primary replicakonfiguráciu. Nech sa replikácia deje prirodzene. Po dokončení replikácie povýšte nový počítač na primárny a starší počítač prepnite do režimu offline. Pretože sa od väčšieho stroja očakáva splnenie všetkých požiadaviek, všetky čítania a zápisy sa uskutočnia na tomto stroji.

V pohode Váš systém je opäť funkčný a má zvýšený výkon.

Vášmu podnikaniu sa darí veľmi dobre a rozhodli ste sa rozšíriť na ďalšie 3 mestá - teraz pôsobíte celkovo v 5 mestách. Doprava je 3x vyššia ako predtým, očakáva sa, že urobíte okolo 300 rezervácií za minútu. Predtým, ako dosiahnete túto cieľovú rezerváciu, opäť narazíte na výkonnostnú krízu, veľkosť indexu databázy sa v pamäti výrazne zväčšuje, vyžaduje neustálu údržbu, skenovanie tabuľky s indexom je stále pomalšie ako kedykoľvek predtým. Vypočítate náklady na ďalšie zväčšenie stroja, ale nie ste o nich presvedčení. Čo teraz robíš?

Vzor 3 - Segregácia zodpovednosti za príkazové dotazy (CQRS):

Zistíte, že veľký stroj nie je schopný vybaviť všetky read/writepožiadavky. Vo väčšine prípadov tiež každá spoločnosť potrebuje transakčné schopnosti, writeale nie readoperácie. Ste tiež v poriadku s trochou nekonzistentných alebo oneskorených readoperácií a vaša firma s tým tiež nemá problém. Vidíte príležitosť, kde by mohla byť dobrá voľba oddeliť read& writeoperácie fyzického stroja. Vytvorí priestor pre jednotlivé stroje na zvládnutie viacerých read/writeoperácií.

Teraz si vezmete ďalšie dva veľké stroje a nastavíte ich ako replicasúčasný stroj. Replikácia databázy sa postará o distribúciu dát zo primarystroja na replicastroj. Všetky replikačné dotazy (Query ( Q) in CQRS) navigujete do replík - akýkoľvek replicamôže slúžiť akejkoľvek požiadavke na čítanie, všetky dotazové otázky (Command ( C) in CQRS) navigujete do primary. V replikácii môže byť malé oneskorenie, ale podľa prípadu použitia vašej firmy je to v poriadku.

Väčšina stredne veľkých startupov, ktoré obsluhujú niekoľko stotisíc požiadaviek každý deň, môže prežiť s nastavením primárnej repliky za predpokladu, že pravidelne archivujú staršie dáta.

Teraz sa rozširujete na ďalšie 2 mestá a zistíte, že vaše primarynie je schopné vybaviť všetky writežiadosti. Mnoho writepožiadaviek má latenciu. Okrem toho je oneskorenie medzi primary& replicaniekedy vplyvu zákazníkmi a vodiči ex - kedy končí výlet, zákazník úspešne zaplatí vodičovi, ale vodič nie je schopný vidieť platbu, pretože aktivita zákazníka je writepožiadavka, ktorý ide do primary, zatiaľ čo činnosť vodiča je readpožiadavka to ide do jednej z replík. Váš celkový systém je taký pomalý, že vodič nevidí platbu aspoň pol minúty - čo je frustrujúce pre vodiča aj zákazníka. Ako to riešite?

Vzor 4 - Multi primárna replikácia

Škálovali ste skutočne dobre s primary-replicakonfiguráciou, teraz však potrebujete vyšší výkon zápisu. Možno budete pripravení trochu kompromitovať readvýkon žiadosti. Prečo nerozložiť žiadosť o zápis aj do súboru replica?

V multi-primarykonfigurácii môžu všetky stroje fungovať ako primary& replica. Môžete si myslieť, multi-primaryako hovorí kruh strojov A->B->C->D->A. Bmôže replikovať údaje z A, Cmôže replikovať údaje z B, Dmôže replikovať údaje z C, Amôže replikovať údaje z D. Môžete zapisovať údaje do ľubovoľného uzla, zatiaľ čo čítať údaje, môžete vysielať dopyt do všetkých uzlov, ktokoľvek odpovie, vráti to. Všetky uzly budú mať rovnakú databázovú schému, rovnakú sadu tabuliek, index atď. Musíte sa teda uistiť, že nedochádza ku kolízii idmedzi uzlami v tej istej tabuľke, inak by počas vysielania viac uzlov vrátilo rovnaké údaje id.

Spravidla je lepšie použiť UUIDalebo GUIDpre ID. Ďalšou nevýhodou tejto techniky je - readdotazy môžu byť neefektívne, pretože zahŕňajú vysielanie dotazu a získanie správneho výsledku - v zásade prístup rozptýleného zhromažďovania.

Teraz sa rozširujete na ďalších 5 miest a váš systém má opäť bolesti. Očakáva sa, že vybavíte zhruba 50 žiadostí za sekundu. Ste v zúfalej potrebe vybaviť veľké množstvo súbežných požiadaviek. Ako to dosiahnete?

Vzor 5 - Rozdelenie:

Viete, že vaša locationdatabáza je niečo, čo rastie writea readprenáša sa. Pravdepodobne write:readpomer je 7:3. To vyvíja veľký tlak na existujúce databázy. Tieto locationtabuľky obsahujú niekoľko základných údajov, ako sú longitude, latitude, timestamp, driver id, trip idatď. To nemá čo do činenia s užívateľskými výlety, užívateľských dát, údajov o platbách atď Čo asi oddeľujúca locationtabuľky v samostatnom schéme databázy? Čo tak dať túto databázu do samostatných strojov so správnym primary-replicaalebo multi-primarynakonfigurovaným?

Toto sa nazýva rozdelenie údajov podľa funkcií. Rôzna databáza môže hostiť údaje kategorizované podľa rôznych funkcií, ak je to potrebné, výsledok sa dá agregovať do zadnej vrstvy. Pomocou tejto techniky sa môžete zamerať na dobré škálovanie tých funkcionalít, ktoré vyžadujú vysoké read/writepožiadavky. Aj keď back-endová alebo aplikačná vrstva musí niesť zodpovednosť za pripojenie sa k výsledkom, ak je to potrebné, čo pravdepodobne spôsobí ďalšie zmeny kódu.

Teraz si predstavte, že ste rozšírili svoje podnikanie do celkovo 20 miest vo vašej krajine a plánujete čoskoro expandovať do Austrálie. Váš rastúci dopyt po aplikácii si vyžaduje rýchlejšiu a rýchlejšiu reakciu. Žiadna z vyššie uvedených metód vám teraz nemôže pomôcť až do extrému. Váš systém musíte škálovať tak, aby rozšírenie do ďalších krajín / oblastí nie vždy vyžadovalo časté zmeny v inžinierstve alebo architektúre. Ako to robíš?

Vzor 6 - Horizontálne škálovanie:

Robíte veľa googlov, veľa čítate o tom, ako iné spoločnosti problém vyriešili - a prídete na to, že musíte urobiť horizontálnu mierku. Pridelíte povedzme 50 strojov - všetky majú rovnakú databázovú schému, ktorá obsahuje rovnakú sadu tabuliek. Všetky stroje obsahujú iba časť údajov.

Pretože všetky databázy obsahujú rovnakú sadu tabuliek, môžete systém navrhnúť tak, aby sa tam nachádzali údaje, tj; všetky súvisiace dátové prenosy na rovnakom stroji. Každý stroj môže mať svoje vlastné repliky, repliky je možné použiť pri zotavení po zlyhaní. Každá z databáz sa volá shard. Fyzický stroj môže mať jeden alebo viac shards- záleží na vašom návrhu, ako chcete. Musíte sa rozhodnúť sharding keytak, aby jednotlivec sharding keyvždy odkazoval na rovnaký stroj. Takže si môžete predstaviť veľa strojov, ktoré všetky obsahujú súvisiace údaje v rovnakej množine tabuliek, read/writepožiadavkách na ten istý riadok alebo rovnakú množinu pozemkov zdrojov v rovnakom databázovom stroji.

Úlomok je vo všeobecnosti ťažký - aspoň to tvrdia inžinieri z rôznych spoločností. Ale keď obslúžite milióny alebo miliardy žiadostí, musíte urobiť také ťažké rozhodnutie.

Rozoberiem to shardingpodrobnejšie v ďalšom príspevku, takže brzdím pokušenie diskutovať v tomto príspevku viac.

Teraz, keď máte zavedený úlomok, ste si istí, že sa môžete rozšíriť do mnohých krajín. Vaše podnikanie vzrástlo natoľko, že vás investori tlačia k tomu, aby ste rozšírili svoje podnikanie na všetky kontinenty. Tu opäť vidíte nejaký problém. Latencia API znova. Vaša služba je hostená v USA a ľudia z Vietnamu majú za sebou ťažké jazdy. Prečo? Čo s tým robíš?

Vzor 7 - Múdry oddiel dátového centra:

Vaše podnikanie rastie v Amerike, južnej Ázii a v niekoľkých krajinách v Európe. Denne robíte milióny rezervácií a na váš server prichádzajú miliardy požiadaviek. Gratulujeme - toto je vrcholná chvíľa pre vaše podnikanie.

Ale keďže žiadosti z aplikácie musia cestovať naprieč kontinentmi cez stovky alebo tisíce serverov na internete, nastáva latencia. A čo distribúcia prenosu medzi dátovými centrami? Môžete si založiť dátové centrum v Singapure, ktoré vybavuje všetky požiadavky z južnej Ázie, dátové centrum v Nemecku dokáže vybaviť všetky požiadavky z európskych krajín a kalifornské dátové centrum dokáže vybaviť všetky žiadosti z USA.

Tiež povolíte krížovú replikáciu dátového centra, ktorá pomáha pri zotavení po katastrofe. Takže ak kalifornské dátové centrum vykoná replikáciu do singapurského dátového centra, v prípade, že dôjde k zlyhaniu kalifornského dátového centra v dôsledku problému s elektrinou alebo prírodnou katastrofou, všetky požiadavky USA sa môžu vrátiť späť do singapurského dátového centra atď.

Táto technika škálovania je užitočná, keď máte milióny zákazníkov, ktorí slúžia v rôznych krajinách, a nemôžete sa vyrovnať so stratou dát. Musíte vždy udržiavať dostupnosť systému.

Toto je niekoľko všeobecných postupov krok za krokom pre zmenu mierky databázy. Aj keď väčšina technikov nemá dostatok šancí na implementáciu týchto techník, ako celok je lepšie získať širšiu predstavu o takomto systéme, čo vám v budúcnosti môže pomôcť pri lepšom navrhovaní systému a architektúry.

V nasledujúcich článkoch sa pokúsim podrobne rozobrať niektoré pojmy. Ak máte nejaké otázky, neváhajte a odpovedzte na ne.

Článok je pôvodne publikovaný na strednom účte autora: //medium.com/@kousiknath/understanding-database-scaling-patterns-ac24e5223522