DynamoDB vs MongoDB NoSQL [geschlossen]

Ich versuche herauszufinden, was ich für ein zukünftiges Projekt verwenden kann. Wir planen, im ersten Jahr etwa 500.000 Datensätze pro Monat zu speichern. In den nächsten Jahren ist dies möglicherweise eine vertikale Anwendung, sodass keine Verwendung erforderlich ist Datenbank dafür, das ist der Grund, warum ich mich für einen noSQL-Datenspeicher entschieden habe.

Die erste Option, die mir in den Sinn kam, war mongo db, da es sich um ein sehr ausgereiftes Produkt handelt, das von der Community sehr unterstützt wird. Andererseits haben wir ein brandneues Produkt, das einen verwalteten Service mit höchster Leistung bietet. Ich werde dies entwickeln Anwendung, aber es gibt keinen Wartungsplan (zumindest für den Moment), daher denke ich, dass dies ein großer Vorteil sein wird, da Amazon eine elastische Möglichkeit zur Skalierung bietet.

Mein Hauptanliegen ist die Abfragestruktur. Ich habe mir die DynamoDB-Abfragefunktionen noch nicht angesehen, aber da es sich um eine ak / v-Datenspeicherung handelt, bin ich der Meinung, dass dies eingeschränkter sein könnte als mongo db.

Wenn jemand die Erfahrung gemacht hat, ein Projekt von mongoDB nach DynamoDB zu verschieben, wird jeder Rat voll und ganz geschätzt.

Ich habe kürzlich meine MongoDB auf DynamoDB migriert und 3 Blogs geschrieben, um Erfahrungen und Daten über Leistung und Kosten auszutauschen.

Migrieren Sie von MongoDB zu AWS DynamoDB + SimpleDB

7 Gründe, warum Sie MongoDB über DynamoDB verwenden sollten

3 Gründe, warum Sie DynamoDB über MongoDB verwenden sollten

Ich weiß, dass dies alt ist, aber es taucht immer noch auf, wenn Sie nach dem Vergleich suchen. Wir haben Mongo verwendet und sind fast ausschließlich auf Dynamo umgestiegen, was jetzt unsere erste Wahl ist. Nicht weil es mehr Funktionen hat, tut es nicht. Mongo hat eine bessere Abfragesprache, Sie können innerhalb einer Struktur indizieren, es gibt viele kleine Dinge. Die Überlegenheit von Dynamo liegt in dem, was der OP in seinem Kommentar feststellte: Es ist einfach. Sie müssen sich nicht um Server kümmern. Wenn Sie anfangen, eine Mongo-Sharded-Lösung einzurichten, wird dies kompliziert. Sie können zu einem der Hosting-Unternehmen gehen, aber das ist auch nicht billig. Wenn Sie mit Dynamo mehr Durchsatz benötigen, klicken Sie einfach auf eine Schaltfläche. Sie können Skripte schreiben, die automatisch skaliert werden. Wenn es Zeit ist, Dynamo zu aktualisieren, ist es für Sie erledigt. Das ist alles viel kostbarer Stress und Zeit, die nicht aufgewendet wird. Wenn du nicht '

Daher verwenden wir jetzt standardmäßig Dynamo. Mongo vielleicht, wenn die Datenstruktur kompliziert genug ist, um dies zu rechtfertigen, würden wir wahrscheinlich zu einer SQL-Datenbank zurückkehren. Dynamo ist stumpf, Sie müssen wirklich darüber nachdenken, wie Sie es erstellen werden, und wahrscheinlich werden Sie Redis in Elasticcache verwenden, damit es für komplexe Dinge funktioniert. Aber es ist sicher schön, sich nicht darum kümmern zu müssen. Sie codieren. Das ist es.

Bei 500.000 Dokumenten gibt es keinen Grund zur Skalierung. Ein typischer Laptop mit einer SSD und 8 GB RAM kann problemlos 10 Millionen Datensätze erstellen. Wenn Sie also aufgrund der Skalierung versuchen, eine Auswahl zu treffen, spielt Ihre Auswahl keine Rolle. Ich würde vorschlagen, dass Sie auswählen, was Ihnen am besten gefällt und wo Sie vielleicht den meisten Online-Support finden.

Für schnelle Übersichtsvergleiche gefällt mir diese Website mit vielen Vergleichsseiten sehr gut, z. B. AWS DynamoDB vs MongoDB; http://db-engines.com/de/system/Amazon+DynamoDB%3BMongoDB

Kurze Antwort: Beginnen Sie mit SQL und fügen Sie NoSQL nur bei Bedarf hinzu. (es sei denn, Sie benötigen nichts anderes als sehr einfache Abfragen)

Meine persönliche Erfahrung: Ich habe MongoDB nicht für Abfragen verwendet, aber seit April 2015 ist DynamoDB immer noch sehr verkrüppelt, wenn es um etwas geht, das über die grundlegendsten Schlüssel- / Wertabfragen hinausgeht. Ich liebe es für die grundlegenden Dinge, aber wenn Sie Abfragesprache wollen, dann suchen Sie nach einer echten SQL-Datenbanklösung.

In DynamoDB können Sie einen Hash oder einen Hash- und Bereichsschlüssel abfragen und mehrere sekundäre globale Indizes verwenden. Ich mache Abfragen für eine einzelne Tabelle mit 4 möglichen Filterparametern und sortiere die Ergebnisse. Dies wird (kaum) durch die Verwendung der globalen Sekundärindizes mit Filterausdrücken unterstützt. Das Problem tritt auf, wenn Sie versuchen, die Gesamtergebnisse mit dem Filter abzugleichen. Sie können nicht nur nach den ersten 10 Elementen suchen, die mit dem Filter übereinstimmen, sondern es werden 10 Elemente überprüft, und Sie erhalten möglicherweise 0 gültige Ergebnisse, die Sie dazu zwingen, erneut zu arbeiten Scannen von der Weiter-Taste - Schmerzen im Nacken und verbraucht zu viel von Ihrer Tabellenlesequote für ein einfaches Szenario.

Das Limitproblem mit Filtern in der Abfrage wird in den Dokumenten ( http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/QueryAndScan.html#ScanQueryLimit) beschrieben ):

In einer Antwort gibt DynamoDB alle darin enthaltenen Übereinstimmungsergebnisse zurück
den Umfang des Grenzwerts. Zum Beispiel, wenn Sie eine Abfrage ausgeben
oder eine Scananforderung mit einem Grenzwert von 6 und ohne Filter
Ausdruck gibt die Operation die ersten sechs Elemente in der zurück 
Tabelle, die den Anforderungsparametern entspricht. Wenn Sie auch a
FilterExpression, die Operation gibt die Elemente innerhalb von zurück 
Die ersten sechs Elemente in der Tabelle, die den Filteranforderungen entsprechen.

Mein Fazit ist, dass Abfragen mit FilterExpressions nur in sehr seltenen Fällen verwendet werden können und nicht skalierbar sind, da jede Abfrage den größten Teil oder die gesamte Tabelle leicht lesen kann, was viel zu viele DynamoDB-Leseeinheiten verbraucht. Wenn Sie zu viele Leseeinheiten verwenden, werden Sie gedrosselt und sehen eine schlechte Leistung.

Expertenmeinung: Auf dem AWS-Gipfel am 9. April 2015 befürwortet Brett Hollman, Manager, Solutions Architecture, AWS in seinem Vortrag über das Scalling an Ihre ersten 10 Millionen Benutzer, mit einer SQL-Datenbank zu beginnen und NoSQL nur dann zu verwenden, wenn und ob dies sinnvoll ist. Denn früher oder später benötigen Sie wahrscheinlich irgendwo in Ihrem Stapel einen SQL Server. Seine Folien sind hier: http://www.slideshare.net/AmazonWebServices/deep-dive-scaling-up-to-your-first-10-million-users Siehe Folie 28.

Wir haben eine Kombination aus Mongo / Dynamo für ein Gesundheitsprodukt gewählt. Grundsätzlich ermöglicht Mongo eine bessere Suche, aber der gehostete Dynamo ist großartig, da er ohne zusätzliche Arbeit HIPAA-konform ist. Daher hosten wir den Mongo-Teil ohne personenbezogene Daten in einem Standard-Setup und ermöglichen es Amazon, den HIPAA-Teil in Bezug auf die Infrastruktur zu verarbeiten. Wir können bestimmte Elemente von Mongo abfragen, die Dokumente mit Zeigern (IDs) des zuordenbaren Dynamo-Dokuments aufrufen.

Der Hauptgrund, warum wir uns für Mongo entschieden haben, anstatt die gesamte Anwendung auf Dynamo zu hosten, war aus zwei Gründen. Zuerst mussten wir ortsbezogene Suchvorgänge durchführen, bei denen Mongo großartig ist, und zu der Zeit war Dynamo dies nicht, aber sie haben jetzt eine Option.

Zweitens waren einige Dokumente unstrukturiert und wir wussten nicht im Voraus, wie die Daten aussehen würden. Nehmen wir zum Beispiel an, ein Benutzer gibt ein Dokument in die "Formular" -Sammlung wie folgt ein: {"Benutzername": "Benutzer1", " E-Mail ":" me@me.com "}. Und ein anderer Benutzer fügt dies in dieselbe Sammlung ein {"phone": "813-555-3333", "location": [28.1234, -83.2342]}. Mit mongo können wir jedes dieser dynamischen und unbekannten Felder jederzeit durchsuchen. Mit Dynamo können Sie dies tun, müssen jedoch jedes Mal einen Index erstellen, wenn ein neues Feld hinzugefügt wird, das durchsucht werden soll. Wenn Sie also noch nie zuvor ein Telefonfeld in Ihrem Dynamo-Dokument hatten und es dann plötzlich von jemandem hinzugefügt wird, ist es völlig nicht durchsuchbar.

Dies bringt einen weiteren Punkt auf, den Sie erwähnt haben. Manchmal bedeutet die Auswahl der richtigen Lösung für den Job nicht immer die Auswahl des besten Produkts für den Job. Beispielsweise haben Sie möglicherweise einen Kunden, der das von Ihnen erstellte System für mehr als 10 Jahre benötigt und verwenden wird. Die Entscheidung für eine SaaS / IaaS-Lösung, die gut genug ist, um die Aufgabe zu erledigen, ist möglicherweise eine bessere Option, da Sie sich darauf verlassen können, dass amazon die Systeme auf lange Sicht gewartet und gewartet hat.

Ich habe an beiden gearbeitet und bin ein Fan von beiden.

Aber Sie müssen verstehen, wann was und zu welchem ​​Zweck verwendet werden soll.

Ich denke nicht, dass es eine großartige Idee ist, Ihre gesamte Datenbank in DynamoDB zu verschieben. Der Grund für das Abfragen ist schwierig, außer für Primär- und Sekundärschlüssel. Die Indizierung ist begrenzt und das Scannen in DynamoDB ist schmerzhaft.

Ich würde mich für eine hybride Art von Datenbank entscheiden, in der umfangreiche abfragbare Daten vorhanden sein sollten, nämlich MongoDB, mit all ihren Funktionen, die Sie niemals gezwungen fühlen würden, Verbesserungen oder Modifikationen bereitzustellen.

DynamoDB ist blitzschnell (schneller als MongoDB), daher wird DynamoDB häufig als Alternative zu Sitzungen in skalierbaren Anwendungen verwendet. Die Best Practices von DynamoDB schlagen außerdem vor, dass Daten, die weniger verwendet werden, in eine andere Tabelle verschoben werden.

Angenommen, Sie haben Artikel oder Feeds. Die Leute suchen eher nach Sachen der letzten Woche oder der Sachen dieses Monats. Es ist sehr selten, dass Menschen zwei Jahre alte Daten besuchen. Zu diesem Zweck zieht DynamoDB es vor, Daten nach Monat oder Jahr in verschiedenen Tabellen zu speichern.

DynamoDB ist scheinbar skalierbar, was Sie in MongoDB manuell tun müssen. Sie würden jedoch an Leistung von DynamoDB verlieren, wenn Sie die Durchsatzpartition und die Funktionsweise der Skalierung hinter den Kulissen nicht verstehen.

DynamoDB sollte dort eingesetzt werden, wo Geschwindigkeit entscheidend ist. MongoDB hingegen hat zu viele Hände und Funktionen, was DynamoDB fehlt.

Beispielsweise können Sie einen Replikatsatz von MongoDB so einrichten, dass einer der Replikate eine Dateninstanz enthält, die 8 (oder was auch immer) Stunden alt ist. Wirklich nützlich, wenn Sie etwas Großes in Ihrer Datenbank durcheinander gebracht haben und die Daten so erhalten möchten, wie sie vorher waren.

Das ist aber meine Meinung.

Denken Sie daran, ich habe nur mit MongoDB experimentiert ...

Nach dem, was ich gelesen habe, hat DynamoDB in Bezug auf die Funktionen einen langen Weg zurückgelegt. Früher war es ein sehr einfacher Schlüsselwertspeicher mit äußerst eingeschränkten Speicher- und Abfragefunktionen. Es ist seitdem gewachsen und unterstützt jetzt größere Dokumente + JSON-Unterstützung und globale Sekundärindizes . Die Kluft zwischen dem, was DynamoDB und MongoDB in Bezug auf Funktionen bieten, wird mit jedem Monat kleiner. Die neuen Funktionen von DynamoDB auf erweitert hier .

Ein Großteil der Vergleiche zwischen MongoDB und DynamoDB ist veraltet, da kürzlich DynamoDB-Funktionen hinzugefügt wurden. Dieser Beitrag bietet jedoch einige andere überzeugende Punkte für die Wahl von DynamoDB, nämlich dass es einfach, wartungsarm und oft kostengünstig ist. Eine weitere Diskussion über die Auswahl der Datenbank war interessant zu lesen, wenn auch etwas alt.

Mein Tipp: Wenn Sie ernsthafte Datenbankabfragen durchführen oder in Sprachen arbeiten, die von DynamoDB nicht unterstützt werden, verwenden Sie MongoDB. Ansonsten bleiben Sie bei DynamoDB.