Teams sometimes need lower latency, lower costs (especially as they scale) or the ability to run their applications somewhere other than AWS. Je ľahké pochopiť, prečo sa toľko tímov od svojho zavedenia v roku 2012 obrátilo na Amazon DynamoDB.Je jednoduché začať, najmä ak je vaša organizácia už zakorenená v ekosystéme AWS. Je relatívne rýchla a škálovateľná, s nízkou krivkou učenia.A keďže je plne spravovaná, odstraňuje operačné úsilie a know-how, ktoré sú tradične potrebné na udržanie databázy a spustenie v zdravom stave. V priebehu času sa však objavujú nevýhody, najmä v dôsledku zmeny veľkosti pracovných záťaží a požiadaviek na podnikanie.Teams niekedy potrebujú nižšiu latenciu, nižšie náklady (najmä keď sa rozširujú) alebo schopnosť spustiť svoje aplikácie niekde inde ako v AWS. V týchto prípadoch je ScyllaDB, ktorý ponúka rozhranie API kompatibilné s DynamoDB, často vybraný ako alternatíva. Pozrime sa na výzvy, ktoré viedli k tomu, že tri tímy opustili DynamoDB. Multi-cloud flexibilita a úspora nákladov Yieldmo je online reklamná platforma, ktorá spája vydavateľov a inzerentov v reálnom čase pomocou aukčného systému, optimalizovaného s ML. Ich podnikanie sa spolieha na doručovanie reklám rýchlo (do 200-300 milisekúnd) a efektívne, čo si vyžaduje ultra-rýchle, vysoko výkonné vyhľadávanie databázy v rozsahu. Spočiatku vybudovali platformu na DynamoDB. Avšak zatiaľ čo DynamoDB bola spoľahlivá, významné obmedzenia sa objavili, keď rástli. Ako vysvetlil Todd Coleman, technický spoluzakladateľ a hlavný architekt, ich hlavné obavy boli dvojité: eskalujúce náklady a geografické obmedzenia. Databáza sa stávala čoraz drahšou, keď sa rozširovala, a zamkla ich do AWS, čo bránilo skutočnej flexibilite viacerých cloudov. Pri skúmaní alternatív DynamoDB dúfali, že nájdu možnosť, ktorá by udržala rýchlosť, škálovateľnosť a spoľahlivosť a zároveň znížila náklady a poskytla nezávislosť poskytovateľa cloudu. Yieldmo najprv zvážil zostať s DynamoDB a pridať cachingovú vrstvu. Avšak caching nemohol vyriešiť problém geografickej latencie. vynechanie cache by bolo príliš pomalé, takže tento prístup je nepraktický. Tiež preskúmali Aerospike, ktorý ponúkol rýchlosť a podporu cez cloud. Avšak indexovanie v pamäti spoločnosti Aerospike by si vyžadovalo obrovský a drahý klastr na spracovanie veľkého počtu malých dátových objektov spoločnosti Yieldmo. Potom objavili ScyllaDB. A DynamoDB-kompatibilný API (Alternator) spoločnosti ScyllaDB bol zmeniteľom hry. Todd vysvetlil: „ScyllaDB podporuje nasadenie cez cloud, vyžaduje spravovateľný počet serverov a ponúka konkurencieschopné náklady. Najlepšie zo všetkého je, že jeho rozhranie API je kompatibilné s DynamoDB, čo znamená, že môžeme migrovať s minimálnymi zmenami kódu. Proces migrácie bol starostlivo naplánovaný s využitím ich existujúcej architektúry Kafka message queue na zabezpečenie integrity údajov.Vykonali dva testy proof-of-concept (POC): najprv s jednou tabuľkou 28 miliárd objektov a potom vo všetkých piatich regiónoch AWS. Výsledky boli impozantné. Todd zdieľal: „Naše náklady na databázu boli znížené na polovicu, dokonca aj s rezervovanou kapacitou DynamoDB.“ A okrem úspor nákladov získal Yieldmo flexibilitu na potenciálne nasadenie medzi rôznymi poskytovateľmi cloudu. Zhrnutie, Todd dospel k záveru: „Jedným z našich počiatočných obáv bolo odísť od preukázanej spoľahlivosti DynamoDB. Avšak, ScyllaDB bol vynikajúcim partnerom. Ich tím poskytuje monitorovanie našich zoskupení, upozorňuje nás na potenciálne problémy a radí nám, kedy je potrebné škálovanie z hľadiska nepretržitej údržby. Počúvať od Yieldmo Migrácia na GCP s lepším výkonom a nižšími nákladmi Digital Turbine, hlavný hráč v oblasti mobilných reklamných technológií s ročným obratom 500 miliónov dolárov, čelil rastúcim výzvam s implementáciou DynamoDB.Zatiaľ čo jej primárnou motiváciou pre migráciu bola štandardizácia na Google Cloud Platform po akvizíciách, existujúce riešenie DynamoDB spôsobovalo obavy z výkonu a nákladov v rozsahu. "Môže to byť trochu drahé, keď sa rozširujete, aby ste boli úprimní," vysvetlil Joseph Shorter, viceprezident pre architektúru platformy v spoločnosti Digital Turbine. Robili sme veľa čítaní – 90% všetkých interakcií s DynamoDB bolo čítaním operácií. so všetkými týmito operáciami sme zistili, že výkonové hity nás vyžadovali, aby sme sa zvýšili viac, než sme chceli, čo zvýšilo náklady.“ Digitálna turbína potrebovala migráciu, aby bola čo najrýchlejšia a čo najnižšie riziková, čo znamenalo udržiavanie refaktoringu aplikácií na minimum. Hlavnou obavou, podľa Shorter, bola „Ako môžeme migrovať bez radikálneho refaktorovania našej platformy, pri zachovaní prinajmenšom rovnakého výkonu a hodnoty – a vyhnúť sa situácii havárie a spálenia? Po vyhodnotení niekoľkých možností sa Digital Turbine presťahovala na ScyllaDB a dosiahla okamžité zlepšenia. "20% rozdiel v nákladoch - to je veľké číslo, bez ohľadu na to, o čom hovoríte," poznamenal Shorter. "A keď uvažujete o našich plánoch rozšíriť sa ešte ďalej, stáva sa to ešte významnejšie." Okrem úspor nákladov sa zistili, že „jednoducho nevyužívajú clustery ScyllaDB“, čo naznačuje priestor pre ešte väčší rast bez proporčného zvýšenia nákladov. Počúvať z digitálnej turbíny Vysoká rýchlosť písania s nízkou latenciou a nižšími nákladmi Tím používateľského stavu a prispôsobenia pre jednu z najväčších mediálnych streamovacích služieb na svete používal DynamoDB už niekoľko rokov.Keď rekonštruovali dva existujúce prípady použitia, zaujímali sa, či je čas na zmenu databázy. Pauza / pokračovanie: Ak používateľ sleduje show a preruší ju, môže si vyzdvihnúť miesto, kde sa zastavila - na akomkoľvek zariadení, z akéhokoľvek miesta. Stav sledovania: Pomocou tých istých údajov určíte, či používateľ sledoval reláciu. Tu je jednoduchý architektonický diagram: Každých 30 sekúnd klient odošle srdce s aktualizovanou pozíciou hlavy programu a potom tieto udalosti odošle do databázy. Edge Pipeline nahráva udalosti v rovnakej oblasti ako používateľ, zatiaľ čo Authority (Auth) Pipeline kombinuje udalosti pre všetkých päť regiónov, ktoré spoločnosť slúži. Dve hlavné technické požiadavky na podporu tejto architektúry boli: Aby sa zabezpečila skvelá užívateľská skúsenosť, systém musel zostať vysoko dostupný, s nízkou latenciou a schopnosťou škálovania na základe nárastu prevádzky. Aby sa zabránilo rozsiahlej inštalácii infraštruktúry alebo práci DBA, potrebovali jednoduchú integráciu so svojimi službami AWS. Akonáhle boli tieto boxy skontrolované, tím dúfal, že zníži celkové náklady. "Naša existujúca infraštruktúra mala dáta rozptýlené v rôznych zoskupeniach DynamoDB a Elasticache, takže sme naozaj chceli niečo jednoduché, ktoré by ich mohlo kombinovať do oveľa nižšieho nákladového systému," vysvetlil ich backendový inžinier. Konkrétne potrebujú databázu s: Podpora viacerých regiónov, pretože služba bola populárna v piatich hlavných geografických regiónoch. Aktualizácie nemali prísnu dohodu o úrovni služieb (SLA), ale systém potreboval vykonať podmienené aktualizácie na základe časových pečiatok udalostí. Schopnosť manipulovať s viac ako 78K čítaním za sekundu s latenciou P99 10 až 20 milisekúnd.Použitý prípad zahŕňal iba jednoduché bodové dotazy; veci ako indexy, oddelenie a zložité vzory dotazu neboli primárnym problémom. Približne 10 TB dát s priestorom na rast. Podľa ich backendového inžiniera, „DynamoDB by mohol perfektne podporovať naše technické požiadavky. ale vzhľadom na našu veľkosť dát a vysoký (písanie ťažký) prietok, pokračovanie s DynamoDB by bolo ako posúvanie peňazí do ohňa.“ Na základe ich požiadaviek na výkon písania a náklady sa rozhodli preskúmať ScyllaDB. Na preukázanie konceptu vytvorili skúšobný cluster ScyllaDB Cloud so šiestimi uzlovami AWS i4i 4xlarge a cluster predinštalovali s 3 miliardami záznamov. Spustili kombinované zaťaženie 170K písaní za sekundu a 78K čítaní za sekundu. Tieto nízke latencie, spojené s významnými úsporami nákladov (viac ako 50%), ich presvedčili, aby opustili DynamoDB. Okrem nižších latencií za nižšie náklady, tím tiež ocenil nasledujúce aspekty ScyllaDB: Konštrukcia spoločnosti ScyllaDB zameraná na výkon (vybudovaná na základe rámca Seastar, s využitím C++, s vedomím NUMA, s ponukou ovládačov s vedomím rozdielov atď.) pomáha tímu znižovať čas a náklady na údržbu. Stratégia inkrementálneho zhutnenia im pomáha výrazne znížiť zosilňovanie písania. Flexibilná úroveň konzistencie a faktory replikácie im pomáhajú podporovať samostatné potrubia Auth a Edge. Napríklad Auth používa konzistenciu kvorumu, zatiaľ čo Edge používa úroveň konzistencie „1“ kvôli duplicite údajov a vysokému výkonu. Ich backendový inžinier dospel k záveru: „Výber databázy je ťažký. Musíte brať do úvahy nielen funkcie, ale aj náklady. "V našom prípade, vzhľadom na vysoké požiadavky na priepustnosť a latenciu, DynamoDB serverless nebola skvelou voľbou. Tiež nepodceňujte úlohu hardvéru. Lepšie využívanie hardvéru je kľúčom k zníženiu nákladov a zároveň k zlepšeniu výkonu." Naučte sa viac Je váš tím ďalší? Ak váš tím zvažuje , , to explore. Prihlásiť sa na aby sme vám povedali viac o vašom prípade použitia, SLA, technických požiadavkách a o tom, čo dúfate, že optimalizujete. Dáme vám vedieť, či je ScyllaDB vhodný a ak áno, čo môže migrácia znamenať z hľadiska zmien aplikácií, modelovania údajov, infraštruktúry atď. Prechod z DynamoDB ScyllaDB môže byť možnosťou Technická konzultácia Bonus: Tu je rýchly pohľad na to, ako ScyllaDB porovnáva s DynamoDB: Napísané podľa : → Názov: Guilherme da Silva Nogueira a Felipe Cardeneti Mendesová . Napísané podľa Názov: Guilherme da Silva Nogueira Felipe Cardeneti Mendesová
