Identitätsspalte in DocumentDB

AFAIK, DocumentDB hat kein solches Konzept. Jedes Dokument in DocumentDB hat eine Eigenschaft id , die das Dokument eindeutig identifiziert, aber das Feld id vom Typ string ist. Wenn Sie ein Dokument erstellen, können Sie festlegen, dass kein Wert für dieses Feld angegeben werden soll, und DocumentDB weist automatisch eine ID zu, aber dieser Wert ist eine GUID. Wenn Sie also die Autoinkrementfunktionalität erreichen möchten, müssen Sie dies selbst erledigen. Beachten Sie jedoch, dass es sich um eine Eigenschaft vom Typ String handelt, so dass Sie selbst dann, wenn Sie dies selbst bearbeiten, die Zeichenfolge mit Nullen auffüllen müssen, damit die Werte in der richtigen Reihenfolge zurückgegeben werden, z. B. 1, 2, 3 usw. statt 1, 10, 11, ... 19, 2, 20 ....

Es gibt immer noch (Stand August 2016) keine integrierte Identity -Funktionalität; Es gibt eine Anfrage für solche im Feedback-Forum für DocumentDB, die für hier . Aber bedenken Sie, dass ein automatischer Zähler etwas gegen die meisten NoSQL-Design-Philosophien ist.

Es gibt jedoch einige Ansätze, die als Problemumgehungen verfolgt werden können, und beide haben eine Einschränkung; Die erste Möglichkeit besteht darin, ein Counter Document innerhalb einer Stored Procedure zu aktualisieren:

GESPEICHERTE VERFAHREN UND ZÄHLDOKUMENT

1. Erstellen Sie ein Dokument, das eine numerische Werteigenschaft enthält. Entweder den eigenen Link zwischenspeichern oder vorzugsweise mit einer bekannten ID wie "__ DocumentType _Counter" erstellen, und dann können Sie die UriFactory verwenden, um eine Dokumentenverknüpfung zu erstellen, die einen effizienten "direkten" Zugriff ermöglicht zu diesem Counter Document .

2. Erstellen Sie eine Stored Procedure, die ein einzufügendes Dokument akzeptiert, und das Uri des Counter Document . Wählen Sie in dieser Stored Procedure den Wert des Counters aus, inkrementieren Sie ihn, weisen Sie ihn der relevanten Eigenschaft des einzufügenden Dokuments zu, und speichern Sie den inkrementierten Wert als Update für das Counter-Dokument, wenn dies erfolgreich beibehalten wurde.

   >

Dieser Ansatz funktioniert, da Stored Procedures automatisch als Transaktion ausgeführt werden.

Vorbehalt : Transaktionen werden derzeit jedoch nur innerhalb der Grenzen einer Sammlung definiert. Sie können diese Methode nicht mit Counter Document in einer Sammlung verwenden, wenn Sie ein Dokument in eine andere einfügen.

REDIS

Die zweite Option, die es zu entdecken gilt, die ein wenig mehr Komplexität und ein wenig zusätzliche Kosten mit sich bringt und nicht vollständig in Bezug auf die Erhöhung und Einfügung eines Dokuments ist (aber in meiner persönlichen Erfahrung bietet größerer Durchsatz), erstellt einen Azure Redis-Cache und behält den Counter-Wert im Redis Key Value-Speicher bei, der dann mithilfe eines LUA-Skripts abgefragt und inkrementiert wird.

Dies stellt sicher, dass die Abfrage des Counter-Werts und seines Inkrements eine unteilbare Transaktion ist, da Redis single threaded ist und LUA-Skripte grundsätzlich bis zur Fertigstellung blockieren (aber sehr schnell ausgeführt werden).

Es ist auch möglich, MULTI-EXEC-Befehle zu verwenden. Diese haben ihre eigenen Probleme und müssen untersucht werden, um festzustellen, ob sie für Sie relevant sind.

Weitere Informationen zu Redis-Transaktionen finden Sie hier - Transaktionen in Redis

Vorbehalt: Wenn Ihr Dokument nicht erfolgreich ist, haben Sie "Ghost" -IDs, die für Sie akzeptabel sind oder nicht.

Update : Als Reaktion auf den Kommentar bezüglich "Hinzufügen von RU-Kosten zu jeder Erstellungsoperation" und "serialisiert alle Schreibvorgänge" - ja, wenn Sie den Counter Document -Ansatz verwenden Dies ist der Fall beim Erstellen von Dokumenten, die eine inkrementierte Identity -Eigenschaft erfordern. keine anderen Inserts wären betroffen .

Diese beiden "Kosten" sind notwendig, um die gewünschte Funktionalität bei der Verwendung von DocumentDB zu erreichen - die das Konzept einer Eigenschaft Identity nicht inhärent unterstützt; Beständigkeit gegenüber einem Dokument, um Wiederherstellung / Kontinuität zu gewährleisten, Serialisierung für Konsistenz. RU-Kosten sind im allgemeinen Gebrauch vernachlässigbar, und Techniken wie die Dosierung können dazu verwendet werden, dies auszugleichen.

Gegenwärtig gibt es keine DocumentDB-Alternative, die keine Zähler- oder Serialisierungsschreibvorgänge fortsetzt und gleichzeitig die Integrität für einen inkrementierten Zähler mehrerer Aufrufer garantiert.

Der Rat von Andrew Liu vom DocumentDB-Team ist in der Tat, ein Counter Document zu verwenden, wie in verknüpfte Frage - bitte beachten Sie auch die Kommentare unter Andrew's Antwort.

Da gespeicherte Prozeduren in DocumentDB vorkompiliert werden, sind sie eine effiziente Methode zum Ausführen von "& gt; 1" -Operationen. Sie sind derzeit auch der optimale Weg, um eine Transaktion durchzuführen. "Irgendwo" muss die einzige Quelle der Wahrheit für den Schalter sein; Wie bereits erwähnt, ist eine Option Redis, aber, wie ich darauf hinwies, ist dies kein Teil einer Transaktion, die zurückgesetzt wird, wenn das Einfügen von Dokumenten fehlschlägt, was möglicherweise nicht akzeptabel ist; in Event Sourcing zum Beispiel ist es nicht.