AWS MySQL RDS gegen AWS DynamoDB [geschlossen]

Ich benutze MySQL jetzt schon eine ganze Weile und bin mit der Struktur und den SQL-Abfragen usw. vertraut.

Derzeit wird ein neues System in AWS erstellt, und ich habe mir DynamoDB angesehen. Derzeit weiß ich nur wenig darüber.

Ist einer besser als der andere?

Was sind die Vorteile von DynamoDB?

Wie ist der Übergang von MySQL-Abfragen usw. zu dieser DB im flachen Stil?

Sie können AWS Erklärung darüber lesen Sie hier .

Kurz gesagt, wenn Sie hauptsächlich Lookup- Abfragen (und keine Join-Abfragen) haben, ist DynamoDB (und andere NoSQL-DBs) besser. Wenn Sie mit vielen Daten umgehen müssen , sind Sie bei der Verwendung von MySQL (und anderen RDBMS) eingeschränkt.

Sie können weder Ihre MySQL-Abfragen noch Ihr Datenschema wiederverwenden. Wenn Sie sich jedoch die Mühe machen, NoSQL zu erlernen, fügen Sie Ihrer Toolbox ein wichtiges Tool hinzu. Es gibt viele Fälle, in denen DynamoDB die einfachste Lösung bietet.

Wirklich DynamoDB und MySQL sind Äpfel und Orangen. DynamoDB ist eine NoSQL-Speicherschicht, während MySQL für relationalen Speicher verwendet wird. Sie sollten auswählen, was basierend auf den tatsächlichen Anforderungen Ihrer Anwendung verwendet werden soll. In der Tat können einige Anwendungen mit beiden gut bedient werden.

Wenn Sie beispielsweise Daten speichern, die sich nicht gut für ein relationales Schema eignen (Baumstrukturen, schemalose JSON-Darstellungen usw.), das anhand eines einzelnen Schlüssels oder einer Schlüssel / Bereich-Kombination nachgeschlagen werden kann, dann DynamoDB ( oder ein anderer NoSQL-Speicher) wäre wahrscheinlich die beste Wahl.

Wenn Sie ein genau definiertes Schema für Ihre Daten haben, das gut in eine relationale Struktur passt, und Sie die Flexibilität benötigen, die Daten auf verschiedene Arten abzufragen (natürlich nach Bedarf Indizes hinzufügen), ist RDS möglicherweise die bessere Lösung .

Der Hauptvorteil der Verwendung von DynamoDB als NoSQL-Speicher besteht darin, dass Sie einen garantierten Lese- / Schreibdurchsatz auf jeder gewünschten Ebene erhalten, ohne sich um die Verwaltung eines Cluster-Datenspeichers kümmern zu müssen. Wenn Ihre Anwendung also 1000 Lese- / Schreibvorgänge pro Sekunde erfordert, können Sie einfach Ihre DynamoDB-Tabelle für diese Durchsatzstufe bereitstellen und müssen sich nicht wirklich um die zugrunde liegende Infrastruktur kümmern.

RDS hat den gleichen Vorteil, dass Sie sich nicht um die Infrastruktur selbst kümmern müssen. Wenn Sie jedoch eine erhebliche Anzahl von Schreibvorgängen bis zu dem Punkt ausführen müssen, an dem die größte Instanzgröße nicht mehr mithalten kann, bleiben Sie ohne Optionen (Sie können für Lesevorgänge mithilfe von Lesereplikaten horizontal skalieren).

Aktualisierter Hinweis: DynamoDb unterstützt jetzt die globale Sekundärindizierung, sodass Sie jetzt optimierte Suchvorgänge für andere Datenfelder als den Hash oder die Kombination von Hash- und Bereichsschlüsseln durchführen können.

Wir haben gerade alle unsere DynamoDB-Tabellen auf RDS MySQL migriert.

Während die Verwendung von DynamoDB für bestimmte Aufgaben sinnvoll sein kann, ist es wirklich eine schlechte Idee, ein neues System auf DynamoDB aufzubauen. Für die besten Pläne usw. benötigen Sie immer die zusätzliche Flexibilität Ihrer Datenbank.

Hier sind unsere Gründe, warum wir von DynamoDB umgezogen sind:

1. Indizierung - Das Ändern oder Hinzufügen von Schlüsseln im laufenden Betrieb ist ohne das Erstellen einer neuen Tabelle nicht möglich.
2. Abfragen - Das Abfragen von Daten ist äußerst begrenzt. Insbesondere, wenn Sie nicht indizierte Daten abfragen möchten. Verknüpfungen sind natürlich nicht möglich, daher müssen Sie komplexe Datenbeziehungen auf Ihrer Code- / Cache-Ebene verwalten.
3. Backup - Ein solch langwieriges Backup-Verfahren ist eine enttäuschende Überraschung im Vergleich zum raffinierten Backup von RDS
4. GUI - schlechte UX, eingeschränkte Suche, kein Spaß.
5. Geschwindigkeit - Die Reaktionszeit ist im Vergleich zu RDS problematisch. Sie bauen einen ausgeklügelten Caching-Mechanismus auf, um dies an Stellen zu kompensieren, an denen Sie sich für das interne Caching von RDS entschieden hätten.
6. Datenintegrität - Während das Konzept der fließenden Datenstruktur zunächst gut klingt, sind einige Ihrer Daten besser "in Stein gemeißelt". Starkes Tippen ist ein Segen, wenn ein kleiner Fehler versucht, Ihre Datenbank zu zerstören. Mit DynamoDB ist alles möglich und tatsächlich alles, was schief gehen kann.

Wir verwenden DynamoDB jetzt als Backup für einige Systeme und ich bin sicher, dass wir es in Zukunft für bestimmte, genau definierte Aufgaben verwenden werden. Es ist keine schlechte Datenbank, es ist nur nicht die Datenbank, die 100% Ihres Kernsystems bedient.

Was die Vorteile angeht, würde ich Skalierbarkeit und Haltbarkeit sagen. Es skaliert unglaublich und transparent und ist (irgendwie) immer aktiv. Dies sind wirklich großartige Funktionen, aber sie kompensieren in keiner Weise die Nachteile.

Wenn Sie DynamoDB verwenden, sollten Sie auch wissen, dass die Elemente / Datensätze in DynamoDB auf 400 KB beschränkt sind (siehe DynamoDB-Grenzwerte ). In vielen Anwendungsfällen funktioniert dies nicht. DynamoDB ist also für einige Dinge gut, aber nicht für alle. Gleiches gilt für viele andere NoSQL-Datenbanken.