2017-02-03 1 views
0

Ich habe die Migration unseres Datenspeichers von MongoDB zu DynamoDB geprüft, da es sich um einen gut etablierten AWS-Dienst handelt.Unterstützung für Abfragen zwischen Dokumenten in DynamoDB

Ich bin mir jedoch nicht sicher, ob das DynamoDB-Datenmodell robust genug ist, um unsere Anwendungsfälle zu unterstützen. Ich verstehe, dass DynamoDB im Jahr 2014 Dokumentunterstützung hinzugefügt hat, aber welche Beispiele auch immer ich gesehen habe, sieht nicht so aus, als würde es Abfragen adressieren, die über Dokumente hinweg funktionieren und keinen Wert für den Partitionsschlüssel angeben.

Zum Beispiel, wenn ich ein Dokument mit Mitarbeiter Informationen haben, { "name": "John Doe", "Abteilung": "sales", "date_of_joining": "2017.01.21" }

und ich muss Abfrage wie geben mir alle Mitarbeiter, die nach 01.01.2016 beigetreten sind, dann kann ich es nicht mit diesem Schema machen. Ich könnte diese Abfrage nach dem Erstellen eines sekundären Index, der einen zufällig generierten Partitionsschlüssel (sagen 0-99) und erstellen Sie einen Sortierschlüssel auf "date_of_joining" erstellen, dann für alle Partitionen abfragen und Bedingung auf "date_of_joining" setzen . Dies ist jedoch eine zu komplexe Methode, um eine einfache Abfrage durchzuführen. Dies ist in MongoDB ziemlich einfach.

Kann jemand mit dem Verständnis helfen, wenn es eine bessere Möglichkeit gibt, solche Abfragen in DynamoDB durchzuführen, und ist DynamoDB wirklich für solche Anwendungsfälle geeignet?

+0

etwas ähnliches http://stackoverflow.com/a/34961036/2811189 –

Antwort

1

Eigentlich muss der Partitionsschlüssel des GSI nicht eindeutig sein. Sie können date_of_joining als einen Partitionsschlüssel von GSI haben.

Wenn Sie jedoch den Partitionsschlüssel abfragen, können Sie greater than nicht für das Partitionsschlüsselfeld verwenden. Nur Gleichheit wird für den Partitionsschlüssel unterstützt. Ich bin mir nicht sicher, warum Sie eine Zufallszahl als Partitionsschlüssel von GSI und date_of_joining als Sortierschlüssel haben wollten. Selbst wenn Sie so etwas entwerfen, ist es nicht möglich, DynamoDB Query API zu verwenden, um das erwartete Ergebnis zu erhalten. Möglicherweise verwenden Sie die DynamoDB-Scan-API, die in DynamoDB eine kostspielige Operation darstellt.

GSI:

date_of_joining - as Partition key 

in Query-API unterstützt: -

Wenn Sie mehrere Artikel für die gleiche DOJ haben, haben das Ergebnis mit mehreren Elemente (dh, wenn Sie GSI Abfrage).

KeyConditionExpression : 'date_of_joining = :doj' 

Nicht in Query-API unterstützt: -

KeyConditionExpression : 'date_of_joining > :doj' 

Fazit: -

Sie benötigen DynamoDB Scan zu verwenden. Wenn Sie Scan verwenden, ist GSI möglicherweise nicht erforderlich. Sie können die Haupttabelle direkt mit FilterExpression scannen.

FilterExpression : 'date_of_joining > :doj' 

Nachteil: -

  • Costly

  • nicht effizient

+0

Vielen Dank für Ihre Antwort. Der Grund, warum ich eine Spalte mit Zahlen von 0-99 hinzufüge, ist, dass, da das Abfragen den Wert des Partitionsschlüssels erfordert, ich die Werte (0-99) bereitstellen könnte. Müsste 100 Abfragen auslösen, aber die Verarbeitung würde sich gut über den Cluster verteilen. Und wenn ich 'date_of_joining' als Sortierschlüssel mache, kann ich mehr als und weniger als Abfragen darüber machen. Bitte lassen Sie mich wissen, wenn das nicht der Fall ist. – Ashish

+0

Auch, warum nicht Scans gute Option in DynamoDB – Ashish

+0

Scan ist keine gute Option, weil es Verlust der Lesekapazität verbraucht, die direkt auf die Kosten bezogen. Es ist nicht effizient, da es alle Elemente in der Tabelle lesen und dann die Filterkriterien anwenden muss, um das Ergebnis zu erzeugen. Denken Sie über die Leistung und die Kosten nach, wenn die Tabelle 100 KBitems enthält. – notionquest

0

Sie können entscheiden, ob Sie Ihre Bereichsabfragen mit einem Indexierungs Backend zu unterstützen. Beispielsweise könnten Sie Ihre Tabellenaktualisierungen in DynamoDB mit einer Lambda-Funktion an AWS ElasticSearch streamen und anschließend ES nach Datensätzen abfragen, die dem Bereich der von Ihnen ausgewählten Beitrittsdaten entsprechen.

+0

Danke Alexander. Im Moment sind wir schon so sehr mit so vielen Datenbanken verloren, dass wir nicht zwei für eine Arbeitslast hinzufügen möchten. – Ashish

Verwandte Themen