Wie skaliert Azure DocumentDB? Und muss ich mich darum sorgen?

Question

Ich habe eine Anwendung, die SQL Azure übertrifft - auf jeden Fall den Preis, den ich zu zahlen bereit bin - und ich bin interessiert, Azure DocumentDB zu untersuchen. Die Vorschau hat eindeutig unterschiedliche Skalierbarkeitsgrenzen (wie beispielsweise here beschrieben), aber ich denke, dass ich wahrscheinlich mit denen für die Vorschauperiode davonkommen könnte, vorausgesetzt, dass ich sie richtig verwende.

Also hier ist die Frage, die ich habe. Wie muss ich meine Anwendung so gestalten, dass die integrierte Skalierbarkeit der Azure DocumentDB genutzt wird? Zum Beispiel, ich weiß, dass mit Azure Table Storage - das billig, aber schrecklich stark begrenzte Alternative - Sie müssen alle Ihre Daten in einer zweistufigen Hierarchie zu strukturieren: PartitionKey und RowKey. Vorausgesetzt, dass Sie das tun (was in einer realen Anwendung nahezu unmöglich ist), verschiebt ATS (wie ich es verstehe) Partitionen hinter den Kulissen, von Maschine zu Maschine, so dass Sie nahezu unendliche Skalierbarkeit erhalten. Super, und du musst nie darüber nachdenken.

Skalierung mit SQL Server ist offensichtlich viel komplizierter - Sie müssen Ihr eigenes Sharding-System entwerfen, sich damit befassen, herauszufinden, auf welchem ​​Server der fragliche Shard sitzt, und so weiter. Möglich, und zwar recht skalierbar, aber komplex und schmerzhaft.

Wie funktioniert die Skalierbarkeit mit DocumentDB? Es verspricht eine beliebige Skalierbarkeit, aber wie funktioniert die Speicher-Engine hinter den Kulissen? Ich sehe, dass es "Datenbanken" hat, und jede Datenbank kann eine gewisse Anzahl von "Sammlungen" haben, und so weiter. Aber wie ist seine willkürliche Skalierbarkeit diesen anderen Konzepten zuzuordnen? Wenn ich eine SQL-Tabelle habe, die Hunderte von Millionen Zeilen enthält, bekomme ich die Skalierbarkeit, die ich benötige, wenn ich all diese Daten in eine Sammlung lege? Oder muss ich es manuell über mehrere Sammlungen verteilen? Oder über mehrere DB's? Oder ist DocumentDB irgendwie schlau genug, um Abfragen performant über mehrere Maschinen hinweg zusammenzuführen, ohne dass ich darüber nachdenken muss? Oder...?

Ich habe mich umgesehen, und habe noch keine Anleitung gefunden, wie man das angeht. Sehr interessiert daran, was andere Leute gefunden haben oder was MS empfiehlt.

Answer 1

Update: Ab April 2016 hat DocumentDB das Konzept einer partitioned collection eingeführt, mit der Sie die Server-seitige Partitionierung horizontal skalieren und nutzen können.

Eine einzige DocumentDB-Datenbank kann praktisch auf eine unbegrenzte Menge von Dokumentenspeichern skaliert werden, die durch Sammlungen partitioniert sind (mit anderen Worten, Sie können durch Hinzufügen weiterer Sammlungen skalieren).

Jede Sammlung bietet 10 GB Speicherplatz und eine variable Durchsatzmenge (basierend auf dem Leistungsniveau). Eine Sammlung bietet auch den Umfang für die Speicherung von Dokumenten und die Ausführung von Abfragen. und ist auch die Transaktionsdomäne für alle darin enthaltenen Dokumente.

Quelle: http://azure.microsoft.com/en-us/documentation/articles/documentdb-manage/

Hier ist ein link to a blog post ich auf DocumentDB auf Skalierung und Partitionierungsdaten für eine Multi-Tenant-Anwendung geschrieben.

Answer 2

Sie Fan kann Abfragen wie folgt aus - http://stuartmcleantech.blogspot.co.uk/2016/03/scalable-querying-multiple-azure.html

Answer 3

Mit der neuesten Version von DocumentDB haben sich die Dinge geändert. Es gibt immer noch die Grenze von 10 GB pro Sammlung, aber in der Vergangenheit lag es an Ihnen, herauszufinden, wie Sie Ihre Daten in mehrere Sammlungen aufteilen, um die 10-GB-Grenze nicht zu überschreiten.

Stattdessen können Sie nun einen Partitionsschlüssel angeben, und DocumentDB übernimmt jetzt die Partitionierung für Sie, z. Wenn Sie über Protokolldaten verfügen, möchten Sie möglicherweise die Daten für den Datumswert in Ihrem JSON-Dokument partitionieren, sodass jeden Tag eine neue Partition erstellt wird.