Teams sometimes need lower latency, lower costs (especially as they scale) or the ability to run their applications somewhere other than AWS. Het is gemakkelijk te begrijpen waarom zo veel teams zich sinds de introductie in 2012 hebben gewend aan Amazon DynamoDB.Het is eenvoudig om te beginnen, vooral als uw organisatie al verankerd is in het AWS-ecosysteem.Het is relatief snel en schaalbaar, met een lage leercurve.En omdat het volledig wordt beheerd, ontneemt het de operationele inspanning en knowhow die traditioneel nodig is om een database up-to-date te houden en in een gezonde staat te draaien. Maar na verloop van tijd verschijnen nadelen, vooral naarmate de schaal van de workloads en de bedrijfsvereisten evolueren. Teams hebben soms behoefte aan lagere latency, lagere kosten (vooral als ze schaal) of de mogelijkheid om hun applicaties ergens anders dan AWS uit te voeren. Laten we de uitdagingen onderzoeken die ertoe hebben geleid dat drie teams DynamoDB verlieten. Multi-cloud flexibiliteit en kostenbesparing Yieldmo is een online advertentieplatform dat uitgevers en adverteerders in realtime verbindt met behulp van een op veiling gebaseerd systeem, geoptimaliseerd met ML. Hun bedrijf vertrouwt op het leveren van advertenties snel (binnen 200-300 milliseconden) en efficiënt, wat ultra-snelle, high-throughput database searchups vereist op schaal. Ze bouwden in eerste instantie het platform op DynamoDB. Hoewel DynamoDB betrouwbaar was, kwamen er aanzienlijke beperkingen naar voren naarmate ze groeiden. Zoals Todd Coleman, Technical Co-Founder en Chief Architect, uitlegde, waren hun primaire zorgen tweeledig: stijgende kosten en geografische beperkingen. Terwijl ze DynamoDB-alternatieven onderzochten, hoopten ze een optie te vinden die snelheid, schaalbaarheid en betrouwbaarheid zou behouden en tegelijkertijd kosten zou verlagen en onafhankelijkheid van cloudleveranciers zou bieden. Yieldmo overwoog eerst om bij DynamoDB te blijven en een cachinglaag toe te voegen. echter, caching kon het geografische latency probleem niet oplossen. cache misses zouden te langzaam zijn, waardoor deze aanpak onpraktisch is. Ze onderzochten ook Aerospike, dat snelheid en cross-cloud-ondersteuning bood. echter, zou de indexering in het geheugen van Aerospike een verboden grote en dure cluster nodig hebben om Yieldmo's grote aantal kleine gegevensobjecten te verwerken. En de DynamoDB-compatibele API (Alternator) van ScyllaDB was een game changer. Todd legde uit: "ScyllaDB ondersteunde cross-cloud-implementaties, vereiste een beheerbaar aantal servers en bood concurrerende kosten.Het beste van alles, de API was compatibel met DynamoDB, wat betekent dat we konden migreren met minimale codewijzigingen. Het migratieproces werd zorgvuldig gepland en gebruikte hun bestaande Kafka-reeksarchitectuur om gegevensintegriteit te garanderen.Ze voerden twee proof-of-concept (POC) tests uit: eerst met een enkele tabel van 28 miljard objecten, en vervolgens in alle vijf AWS-regio's. De resultaten waren indrukwekkend. Todd deelde: "Onze databasekosten werden gehalveerd, zelfs met DynamoDB gereserveerde capaciteitsprijzen."En naast kostenbesparingen kreeg Yieldmo de flexibiliteit om mogelijk over verschillende cloudproviders in te zetten. Todd concludeerde: “Een van onze eerste zorgen was om weg te gaan van de bewezen betrouwbaarheid van DynamoDB. ScyllaDB is echter een uitstekende partner geweest. Hun team zorgt voor monitoring van onze clusters, waarschuwt ons voor mogelijke problemen en adviseert ons wanneer schaalbeheer nodig is in termen van voortdurend onderhoud overhead. De ervaring is vergelijkbaar met DynamoDB, maar met grotere onafhankelijkheid en aanzienlijke kostenbesparingen.” Luister naar Yieldmo Migratie naar GCP met betere prestaties en lagere kosten Digital Turbine, een belangrijke speler in de mobiele advertentietechnologie met een jaarlijkse omzet van $ 500 miljoen, werd geconfronteerd met groeiende uitdagingen met de implementatie van DynamoDB.Terwijl de primaire motivatie voor de migratie de standaardisatie op Google Cloud Platform na overnames was, had de bestaande DynamoDB-oplossing zowel prestatie- als kostenproblemen op schaal veroorzaakt. "Het kan een beetje duur zijn als je schaalt, om eerlijk te zijn," legde Joseph Shorter, vice president van Platform Architecture bij Digital Turbine uit. We deden een ton van lezingen – 90% van alle interacties met DynamoDB waren leesoperaties. De belangrijkste zorg, volgens Shorter, was “Hoe kunnen we migreren zonder ons platform radicaal te refactoren, terwijl we op zijn minst dezelfde prestaties en waarde behouden – en een crash-and-burn-situatie vermijden? Na verschillende opties te hebben geëvalueerd, verhuisde Digital Turbine naar ScyllaDB en behaalde onmiddellijke verbeteringen. "Een kostenverschil van 20% - dat is een groot aantal, ongeacht waar je het over hebt," merkte Shorter op. "en als je denkt aan onze plannen om nog verder te schalen, wordt het nog belangrijker." Naast de kostenbesparing vonden ze zichzelf "nauwelijks aan de slag met de ScyllaDB-clusters", wat ruimte suggereert voor nog meer groei zonder evenredige kostenverhogingen. Luisteren naar Digital Turbine Hoge schrijfsnelheid met lage latency en lagere kosten Het gebruikersstatus- en aanpassingsteam voor een van 's werelds grootste media streamingdiensten had DynamoDB al enkele jaren gebruikt.Toen ze twee bestaande gebruikersgevallen opnieuw oprichtten, vroegen ze zich af of het tijd was voor een databasewijziging.De twee gebruikersgevallen waren: Pause / hervatten: Als een gebruiker een show bekijkt en het pauzeert, kunnen ze ophalen waar ze zijn gestopt - op elk apparaat, vanaf elke locatie. Bekijk status: Gebruik dezelfde gegevens om te bepalen of de gebruiker de show heeft bekeken. Hier is een eenvoudig architectuurdiagram: Elke 30 seconden stuurt de client hartslag met de bijgewerkte speelvloerpositie van de show en stuurt deze gebeurtenissen vervolgens naar de database. De Edge Pipeline laadt gebeurtenissen in dezelfde regio als de gebruiker, terwijl de Authority (Auth) Pipeline gebeurtenissen combineert voor alle vijf regio's die het bedrijf bedient. De twee belangrijkste technische vereisten voor het ondersteunen van deze architectuur waren: Om een geweldige gebruikerservaring te garanderen, moest het systeem zeer beschikbaar blijven, met lage latencyrekeningen en de mogelijkheid om te scalen op basis van verkeersgroei. Om uitgebreide infrastructuurinstallaties of DBA-werkzaamheden te voorkomen, hadden ze eenvoudige integratie met hun AWS-services nodig. Nadat die dozen werden gecontroleerd, hoopte het team ook de totale kosten te verminderen. "Onze bestaande infrastructuur had gegevens verspreid over verschillende clusters van DynamoDB en Elasticache, dus we wilden echt iets eenvoudigs dat deze in een veel lagere kosten systeem zou kunnen combineren," legde hun backend engineer uit. In het bijzonder hebben ze een database nodig met: Ondersteuning voor meerdere regio's, omdat de service populair was in vijf grote geografische regio's. Updates hadden geen strikte service level agreement (SLA), maar het systeem moest voorwaardelijke updates uitvoeren op basis van gebeurtenis timestamps. De mogelijkheid om met meer dan 78K per seconde te lezen met een P99-latentie van 10 tot 20 milliseconden.De gebruikssituatie omvatte alleen eenvoudige puntvragen; dingen zoals indexen, partitionering en ingewikkelde querypatronen waren geen primaire zorg. Ongeveer 10TB data met ruimte voor groei. Waarom verhuizen van DynamoDB? Volgens hun backend-ingenieur, “DynamoDB zou onze technische vereisten perfect kunnen ondersteunen. Maar gezien onze gegevensgrootte en hoge (schrijven zware) doorvoer, zou het doorgaan met DynamoDB zijn geweest als het gooien van geld in het vuur.” Op basis van hun vereisten voor schrijfprestaties en -kosten besloten ze om ScyllaDB te verkennen. Voor een conceptbewijs hebben ze een ScyllaDB Cloud-testcluster opgesteld met zes AWS i4i 4xlarge knooppunten en de cluster vooraf geladen met 3 miljard records. Ze hebben gecombineerde ladingen van 170K schrijven per seconde en 78K lezen per seconde uitgevoerd. Deze lage latencies, in combinatie met aanzienlijke kostenbesparingen (meer dan 50%), overtuigde hen om DynamoDB te verlaten. Het prestatiegerichte ontwerp van ScyllaDB (gebouwd op het Seastar-framework, met C++, NUMA-bewustzijn, het aanbieden van niet-bewuste stuurprogramma's, enz.) helpt het team de onderhoudstijd en -kosten te verminderen. Incrementele compactie strategie helpt hen aanzienlijk te verminderen schrijven versterking. Flexibele consistentie-niveau en replicatiefactoren helpen hen bij het ondersteunen van afzonderlijke Auth- en Edge-pijpleidingen.Bijvoorbeeld, Auth gebruikt quorum-consistentie terwijl Edge een consistentie-niveau van "1" gebruikt vanwege de data-duplicatie en hoge doorvoer. Hun backend-ingenieur concludeerde: “Het kiezen van een database is moeilijk. je moet niet alleen functies, maar ook kosten overwegen. "In ons geval, vanwege de hoge doorvoer- en latencyvereisten, was DynamoDB serverless geen geweldige optie. ook, onderschat de rol van hardware niet. Leer meer Is jouw team de volgende? Als je team overweegt - het om te verkennen. inschrijven voor om meer te vertellen over uw gebruikscase, SLA's, technische vereisten en wat u hoopt te optimaliseren.We laten u weten of ScyllaDB een goede pasvorm is en, zo ja, wat een migratie kan betekenen in termen van toepassingswijzigingen, gegevensmodellering, infrastructuur enzovoort. Een verhuizing van DynamoDB ScyllaDB kan een optie zijn Een technisch overleg Bonus: Hier is een snelle blik op hoe ScyllaDB vergelijkt met DynamoDB: Written by : van Vader Guilherme da Silva Nogueira en van Felipe Cardeneti Mendes . Geschreven door Vader Guilherme da Silva Nogueira van Felipe Cardeneti Mendes
