Automatinerkrementierung auf Azure Tischspeicher

Question

Ich entwickle derzeit eine Anwendung für die Speicherung von Azure Table. In dieser Anwendung habe ich Tabelle mit relativ wenigen Einsätzen (ein paar Tausend pro Tag), und der Hauptschlüssel dieser Einheiten wird in einer anderen Tabelle verwendet, die Milliarden Zeilen enthält.

Daher suche ich nach einer Möglichkeit, eine automatisch inkrementierte Ganzzahl anstelle von GUID als Hauptschlüssel in der kleinen Tabelle zu verwenden (da es viel Speicherplatz spart und die Skalierbarkeit der Einsätze nicht wirklich ein Problem ist).

Es gab einige Diskussionen zu diesem Thema, z. B. http://social.msdn.microsoft.com/forums/en/windowsazure/thread/6b7d1ece-301b-4f1-85ab-eeb274349797.

Da jedoch Probleme mit Parallelität sehr schwer zu debuggen und zu erkennen können, fällt es mir ein wenig unangenehm, dies für sich selbst zu implementieren. Meine Frage ist daher, wenn es eine gut getestete Impelemntation davon gibt?

Answer 1

Ich habe das noch nicht implementiert, arbeite aber daran ...

Sie können eine Warteschlange mit Ihren nächsten IDs säen und sie dann einfach von der Warteschlange ausziehen, wenn Sie sie benötigen.

Sie müssen eine Tabelle aufbewahren, um den Wert der größten Zahl der Warteschlange zu enthalten. Wenn Sie wissen, dass Sie nicht eine Tonne der Ganzzahlen verwenden, können Sie von Zeit zu Zeit einen Arbeiter aufwachen und sicherstellen, dass die Warteschlange noch Ganzzahlen enthält. Sie könnten auch eine gebrauchte Int -Warteschlange haben, die der Arbeiter überprüfen könnte, um die Verwendung im Auge zu behalten.

Sie können diesen Arbeiter auch einbinden. Wenn die Warteschlange leer wäre, wenn Ihr Code eine ID (zufällig) benötigte, könnte er das Nickerchen des Arbeiters unterbrechen, um mehr Schlüssel so schnell wie möglich zu erstellen.

Wenn dieser Anruf fehlgeschlagen wäre, müssten Sie einen Weg benötigen (sagen Sie dem Arbeiter, dass Sie die Arbeit für sie erledigen werden (Sperre), dann arbeiten die Arbeiter daran, den nächsten Ausweis zu erhalten und freizuschalten).

1. sperren
2. Holen Sie sich den letzten Schlüssel aus der Tabelle
3. inkrementieren und speichern
4. Freischalten

Verwenden Sie dann den neuen Wert.

Answer 2

Für alle, die es auf der Suche finden, gibt es eine bessere Lösung. Die minimale Zeit für die Tischschloss beträgt 15 Sekunden - Das ist schrecklich. Verwenden Sie es nicht, wenn Sie eine wirklich skalierbare Lösung erstellen möchten. Verwenden Etag!

Erstellen Sie eine Entität in der Tabelle für ID (Sie können sie sogar als ID oder was auch immer benennen).

1) Lesen Sie es.

2) Inkrement.

3) InsertorUpdate MIT ETag angegeben (aus der Leseabfrage).

Wenn letzte Operation (InsertOrUpdate) Erfolg, dann haben Sie eine neue, einzigartige, automatisch inkrementierte ID. Wenn es fehlschlägt (Ausnahme mit HttpStatusCode == 412) bedeutet, dass ein anderer Client es geändert hat. Wiederholen Sie also erneut 1,2 und 3. Die übliche Zeit für Read+InsertOrUpdate ist weniger als 200 ms. Mein Testdienstprogramm mit Quelle auf GitHub.

Answer 3

Sehen UniqueIDGenerator -Klasse von Josh Twist.

Answer 4

Die Lösung, die ich gefunden habe, die doppelte IDs verhindert und Sie autoinkrementiert können

1. Lock (Leasing) einen Blob und lass das als logisches Tor wirken.

2. Lesen Sie dann den Wert.

3. Schreiben Sie den inkrementierten Wert

4. Lösen Sie den Mietvertrag

5. Verwenden Sie den Wert in Ihrer App/Tabelle

Wenn Ihre Arbeiterrolle während dieses Prozesses abstürzen würde, hätten Sie in Ihrem Geschäft nur einen fehlenden Ausweis. IMHO, das ist besser als Duplikate.

Hier ist ein Code -Beispiel und weitere Informationen Bei diesem Ansatz von Steve Marx

Answer 5

Wenn Sie Richtlinien wirklich vermeiden müssen, haben Sie überlegt, etwas basierend auf Datum/Uhrzeit zu verwenden, und nutzen Sie dann Partitionsschlüssel, um das Parallelitätsrisiko zu minimieren.

Ihr Partitionschlüssel könnte nach Benutzer, Jahr, Monat, Tag, Stunde usw. sein, und der Zeilenschlüssel könnte der Rest der DateTime in einem geringen Zeitpunkt sein, um die Parallelität zu kontrollieren.

Natürlich müssen Sie sich zum Preis des Datums in Azure fragen, wenn das Vermeiden einer Richtlinie all diese zusätzlichen Anstrengungen wert ist (vorausgesetzt, eine Richtlinie wird nur funktionieren).