Teams sometimes need lower latency, lower costs (especially as they scale) or the ability to run their applications somewhere other than AWS. Es ist leicht zu verstehen, warum sich so viele Teams seit seiner Einführung im Jahr 2012 auf Amazon DynamoDB gewandt haben.Es ist einfach zu starten, besonders wenn Ihre Organisation bereits im AWS-Ökosystem verankert ist.Es ist relativ schnell und skalierbar, mit einer niedrigen Lernkurve.Und da es vollständig verwaltet ist, entnimmt es die operative Anstrengung und das Know-how, das traditionell erforderlich ist, um eine Datenbank aufrechtzuerhalten und in einem gesunden Zustand zu laufen. Aber im Laufe der Zeit entstehen Nachteile, insbesondere wenn sich die Arbeitsbelastungen skalieren und die Geschäftsanforderungen weiterentwickeln. Teams benötigen manchmal eine geringere Latenz, geringere Kosten (besonders wenn sie skalieren) oder die Möglichkeit, ihre Anwendungen an einem anderen Ort als AWS auszuführen. Lassen Sie uns die Herausforderungen untersuchen, die drei Teams dazu veranlasst haben, DynamoDB zu verlassen. Multi-Cloud Flexibilität und Kosteneinsparungen Yieldmo ist eine Online-Werbeplattform, die Verlage und Werbetreibende in Echtzeit mithilfe eines auf Auktionen basierenden Systems verbindet, das mit ML optimiert wurde. Wie Todd Coleman, Technical Co-Founder und Chief Architect, erklärte, waren ihre Hauptbedenken zweifach: steigende Kosten und geografische Einschränkungen.Die Datenbank wurde mit ihrer Skalierung immer teurer und sperrte sie in AWS ein, was die wahre Multi-Cloud-Flexibilität verhinderte. Während sie DynamoDB-Alternativen erforschten, hofften sie, eine Option zu finden, die Geschwindigkeit, Skalierbarkeit und Zuverlässigkeit aufrechterhält und gleichzeitig Kosten senkt und die Unabhängigkeit des Cloud-Anbieters gewährleistet. Yieldmo überlegte zunächst, bei DynamoDB zu bleiben und eine Caching-Schicht hinzuzufügen. Das Caching konnte jedoch das Problem der geografischen Latenz nicht beheben. Sie untersuchten auch Aerospike, das Geschwindigkeit und Cross-Cloud-Unterstützung bot. Jedoch hätte die In-Memory-Indexierung von Aerospike einen prohibitiv großen und teuren Cluster benötigt, um die große Anzahl von kleinen Datenobjekten von Yieldmo zu verarbeiten. Dann entdeckten sie ScyllaDB. Und die DynamoDB-kompatible API (Alternator) von ScyllaDB war ein Spielwechsel. Todd erklärte: „ScyllaDB unterstützte Cloud-übergreifende Bereitstellungen, erforderte eine verwaltbare Anzahl von Servern und bot wettbewerbsfähige Kosten. Am besten war seine API DynamoDB-kompatibel, was bedeutet, dass wir mit minimalen Codeänderungen migrieren konnten. Sie führten zwei Proof-of-Concept-Tests (POC) durch: Zuerst mit einer einzigen Tabelle von 28 Milliarden Objekten und dann in allen fünf AWS-Regionen. Die Ergebnisse waren beeindruckend. Todd teilte mit: „Unsere Datenbankkosten wurden halbiert, selbst mit DynamoDB reservierten Kapazitätspreisen.“ Und über die Kosteneinsparungen hinaus erhielt Yieldmo die Flexibilität, potenziell über verschiedene Cloud-Anbieter hinweg zu implementieren. Todd schloss: „Eine unserer anfänglichen Bedenken bestand darin, von der bewährten Zuverlässigkeit von DynamoDB abzuweichen. ScyllaDB war jedoch ein ausgezeichneter Partner. Ihr Team überwacht unsere Cluster, warnt uns vor potenziellen Problemen und berät uns, wann eine Skalierung in Bezug auf laufende Wartung erforderlich ist. Die Erfahrung ist mit DynamoDB vergleichbar, aber mit größerer Unabhängigkeit und erheblichen Kosteneinsparungen.“ von Yieldmo Migration auf GCP mit besserer Leistung und niedrigeren Kosten Digital Turbine, ein wichtiger Akteur in der mobilen Werbetechnik mit einem Jahresumsatz von 500 Millionen US-Dollar, stand mit seiner DynamoDB-Implementierung zunehmenden Herausforderungen gegenüber.Während seine primäre Motivation für die Migration die Standardisierung auf der Google Cloud Platform nach den Übernahmen war, hatte die bestehende DynamoDB-Lösung sowohl Leistungs- als auch Kostenbedenken im Maßstab verursacht. "Es kann ein bisschen teuer sein, wenn Sie skalieren, um ehrlich zu sein", erklärt Joseph Shorter, Vizepräsident für Plattformarchitektur bei Digital Turbine. "Wir fanden einige Leistungsprobleme.Wir machten eine Menge Lesungen - 90% aller Interaktionen mit DynamoDB waren Lesoperationen.Mit all diesen Operationen fanden wir heraus, dass die Leistungshits uns erfordern, mehr zu skalieren, als wir wollten, was die Kosten erhöhte." Digitale Turbine benötigte die Migration, um so schnell und riskant wie möglich zu sein, was bedeutete, dass die Anwendungsrefaktorierung auf ein Minimum gehalten wird. „Wie können wir die Migration durchführen, ohne unsere Plattform radikal neu zu gestalten und gleichzeitig die gleiche Leistung und den gleichen Wert aufrechtzuerhalten – und eine Crash-and-Brand-Situation zu vermeiden? Nach der Auswertung mehrerer Optionen wechselte Digital Turbine zu ScyllaDB und erzielte sofortige Verbesserungen.Die Migration dauerte weniger als einen Sprint umzusetzen und die Ergebnisse übertrafen die Erwartungen. "Ein Kostenunterschied von 20% - das ist eine große Zahl, egal worüber Sie sprechen", bemerkte Shorter. "Und wenn Sie unsere Pläne in Betracht ziehen, noch weiter zu skalieren, wird es noch bedeutender." Abgesehen von den Kosteneinsparungen, fanden sie sich " kaum die ScyllaDB-Cluster zu nutzen", was Raum für noch mehr Wachstum ohne proportionale Kostenerhöhungen vorschlägt. Siehe Digital Turbine Hohe Schreibleistung mit niedriger Latenz und niedrigeren Kosten Das User State and Customizations Team für einen der weltweit größten Medienstreamingdienste nutzte DynamoDB seit mehreren Jahren.Als sie zwei bestehende Nutzungsfälle neu aufbauten, fragten sie sich, ob es an der Zeit sei, eine Datenbank zu ändern.Die beiden Nutzungsfälle waren: Pause/Wiederholung: Wenn ein Benutzer eine Show beobachtet und sie unterbricht, kann er dort abholen, wo er abgebrochen ist – auf jedem Gerät, von jedem Ort. Beobachtungsstatus: Verwenden Sie die gleichen Daten, um festzustellen, ob der Benutzer die Show gesehen hat. Hier ein einfaches Architekturdiagramm: Alle 30 Sekunden sendet der Client Herzschläge mit der aktualisierten Playhead-Position der Show und sendet diese Ereignisse dann in die Datenbank. Die Edge Pipeline lädt Ereignisse in der gleichen Region wie der Benutzer hoch, während die Authority (Auth) Pipeline Ereignisse für alle fünf Regionen kombiniert, die das Unternehmen bedient. Die beiden wichtigsten technischen Anforderungen für die Unterstützung dieser Architektur waren: Um ein großartiges Benutzererlebnis zu gewährleisten, musste das System hochverfügbar bleiben, mit niedrigen Latenzwerte und der Fähigkeit, auf der Grundlage von Verkehrsströmen zu skalieren. Um umfangreiche Infrastrukturinstallationen oder DBA-Arbeiten zu vermeiden, brauchten sie eine einfache Integration mit ihren AWS-Diensten. Sobald diese Kisten überprüft wurden, hoffte das Team auch, die Gesamtkosten zu senken. "Unsere bestehende Infrastruktur hatte Daten in verschiedenen Clustern von DynamoDB und Elasticache verteilt, also wollten wir wirklich etwas Einfaches, das diese in ein viel niedrigeres Kosten-System kombinieren könnte", erklärte ihr Backend-Ingenieur. Insbesondere benötigten sie eine Datenbank mit: Multiregionale Unterstützung, da der Service in fünf großen geografischen Regionen beliebt war. Updates hatten keine strenge Service-Level-Vereinbarung (SLA), aber das System musste bedingte Updates basierend auf Ereigniszeitstempeln durchführen. Die Fähigkeit, über 78K Lesungen pro Sekunde mit einer P99-Latenz von 10 bis 20 Millisekunden zu handhaben.Der Anwendungsfall beinhaltete nur einfache Punktabfragen; Dinge wie Indizes, Partitionierung und komplizierte Abfragemuster waren keine primäre Sorge. Etwa 10 TB Daten mit Wachstumsraum. Nach Angaben ihres Backend-Ingenieurs könnte DynamoDB unsere technischen Anforderungen perfekt unterstützen. „Aber angesichts unserer Datengröße und des hohen (schreiben schweren) Durchsatzes wäre die Fortsetzung mit DynamoDB wie das Schieben von Geld ins Feuer.“ Basierend auf ihren Anforderungen an die Schreibleistung und die Kosten entschieden sie sich, ScyllaDB zu erforschen.Um das Konzept zu beweisen, setzten sie einen ScyllaDB Cloud-Testcluster mit sechs AWS i4i 4xlarge Knoten auf und laden den Cluster mit 3 Milliarden Datensätzen vor. Sie führten kombinierte Lasten von 170K Schreiben pro Sekunde und 78K Lesen pro Sekunde. Diese niedrigen Latenzzeiten, gepaart mit erheblichen Kosteneinsparungen (über 50%), überzeugten sie, DynamoDB zu verlassen. Das leistungsorientierte Design von ScyllaDB (auf dem Seastar-Framework basierend, unter Verwendung von C++, NUMA-bewußt sein, nicht-bewußte Treiber anbieten usw.) hilft dem Team, Wartungszeit und Kosten zu reduzieren. Die Incremental Compaction-Strategie hilft ihnen, die Schreibverstärkung signifikant zu reduzieren. Flexible Konsistenzniveau und Replikationsfaktoren helfen ihnen, separate Auth- und Edge-Pipelines zu unterstützen. Zum Beispiel verwendet Auth Quorum-Konsistenz, während Edge aufgrund der Datenduplikation und des hohen Durchsatzes ein Konsistenzniveau von „1“ verwendet. Ihr Backend-Ingenieur schloss: „Die Wahl einer Datenbank ist schwierig. Sie müssen nicht nur Funktionen, sondern auch Kosten berücksichtigen. Serverless ist keine silberne Kugel, besonders in der Datenbank-Domain. "In unserem Fall war DynamoDB serverless aufgrund der hohen Durchsatz- und Latenzanforderungen keine großartige Option. Auch unterschätzen Sie nicht die Rolle der Hardware. Lerne mehr Ist Ihre Mannschaft die nächste? Wenn Ihr Team überlegt , der zu erkunden. anmelden für um mehr über Ihren Nutzungsfall, SLAs, technische Anforderungen und das zu sprechen, was Sie optimieren möchten.Wir lassen Sie wissen, ob ScyllaDB eine gute Passform ist und, falls ja, was eine Migration in Bezug auf Anwendungsänderungen, Datenmodellierung, Infrastruktur usw. beinhalten könnte. Ein Umzug von DynamoDB ScyllaDB könnte eine Option sein Eine technische Beratung Bonus: Hier ist ein kurzer Blick darauf, wie ScyllaDB mit DynamoDB verglichen wird: geschrieben von von : von Guilherme da Silva Nogueira und von Felipe Cardeneti Mendes . geschrieben von von Guilherme da Silva Nogueira von Felipe Cardeneti Mendes
