Sollte DocumentDB OfferThroughput in Code festgelegt werden?

Question

Eines der schwierigsten Dinge mit DocumentDB ist herauszufinden, wie viele Request Units pro Sekunde (RUs/s) Sie Ihre Anwendung Tag für Tag, sondern auch während Nutzungsspitzen ausführen müssen. Wenn Sie das falsch verstehen, löst der DocumentDB-Client Ausnahmen aus, was ein schreckliches Nutzungsmodell ist.

Ich habe den OfferThroughput-Wert hart auf 400 codiert (was die niedrigsten RUs/s zu sein scheint), wenn eine neue Sammlung in den DocumentDB-Beispielen erstellt wird. Ich hätte gedacht, dass es am besten wäre, es im Azure-Portal zu setzen, sodass es dynamisch geändert werden kann, ohne Codeänderungen vornehmen zu müssen.

In welchem ​​Szenario wird es im Code festgelegt und welcher Wert hat Vorrang?

Answer 1

Sowohl das Azure-Portal als auch die SDKs verwenden die REST-API (https://msdn.microsoft.com/en-us/library/azure/mt632095.aspx), um den Durchsatz einer Sammlung zu aktualisieren. Das Portal verwendet das clientseitige SDK von DocumentDB. Es gibt also keine Vorrang- oder Präferenzreihenfolge - der letzte Aufruf zum Aktualisieren der Leistung wird für die Sammlung wirksam.

In Bezug darauf, welche Szenarien den Durchsatz in Code im Vergleich zum Portal bieten, hängt dies von Ihrem Präferenz- und Bereitstellungsprozess ab. Für Produktionsanwendungen ist Code besser, da Sie ihn einfach automatisieren können. Sie können den Durchsatz dynamisch ändern oder die Konfiguration für mehrere Sammlungen einheitlich vornehmen.

Answer 2

Ich muss zustimmen, das Provisioning-Modell für den Kauf Durchsatz auf DocumentDB scheint sehr un-Cloud-y. In der Tat ist entweder die Bereitstellung auf der höchsten Stufe, die ein Spitzenwert jemals benötigt, oder Sie programmieren selbst etwas, um den Durchsatz über das Azure-SDK zu erhöhen und zu senken (was bei mehr als einem Albtraum zu einem Alptraum wird) Quelle der Spitze gegen diese Sammlung).

Das Preismodell ist lächerlich. Da die zugrundeliegende Architektur (vor allem auf der 250-GB-Ebene) sowieso gut skalierbar zu sein scheint, sollten wir sie einfach per Verwendung abrechnen.

Seitennotiz, um es dynamisch zu sein, Sie sind Schreiben von Code, da es scheint keine Regel-orientierte Lösung unter Azure zu helfen.