Auto-Inkrement, die auf Azure Table Storage

Ich bin derzeit auf der Entwicklung von Anwendungen für Azure-Tabellenspeicher. In der Anwendung ich habe die Tabelle, die relativ wenig Einsätze (ein paar tausend/Tag), und der Primärschlüssel für diese Einheiten verwendet werden, die in einer anderen Tabelle, die Milliarden von Zeilen.

Deshalb bin ich auf der Suche nach einem Weg, verwenden Sie auto-increment integer, anstelle von GUID als Primärschlüssel in der kleinen Tabelle (da es spart viel Speicher und Skalierbarkeit der Einsätze ist nicht wirklich ein Problem).

Es waren einige Diskussionen zum Thema, z.B. auf http://social.msdn.microsoft.com/Forums/en/windowsazure/thread/6b7d1ece-301b-44f1-85ab-eeb274349797.

Jedoch, da concurrency-Probleme kann sehr schwierig sein, zu Debuggen und Stelle, ich bin ein bisschen unangenehm mit der Umsetzung dieser auf der eigenen. Meine Frage ist daher ob es eine gut getestet impelemntation?

InformationsquelleAutor der Frage Yrlec | 2009-12-08

  1. 4

    Habe ich noch nicht umgesetzt noch nicht, aber arbeite dran ...

    Könnten Sie Samen einer Warteschlange mit Ihren neben-ids zu verwenden, dann wählen Sie einfach diese aus der Warteschlange, wenn Sie Sie benötigen.

    Sie brauchen, um eine Tabelle zu enthalten, die den Wert der größten Zahl Hinzugefügt, um die Warteschlange. Wenn Sie wissen, dass Sie nicht über eine Tonne von Ganzzahlen, Sie hätten einen Arbeiter jeder so oft aufwachen und sicherstellen, dass die Warteschlange noch ganze zahlen. Sie könnten auch ein verwendet int Warteschlange der Arbeiter könnte überprüfen, halten Sie ein Auge auf die Nutzung.

    Man könnte auch den Haken, dass die Arbeiter so, wenn die Warteschlange leer war, wenn Ihr code benötigt eine id (durch Zufall) könnte es zu unterbrechen, die der Arbeitnehmer nap zu erstellen, die mehr Tasten so schnell wie möglich.

    Wenn dieser Aufruf fehlschlägt, müssten Sie einen Weg, um (sagen die Arbeiter, die Sie gehen, um die Arbeit für Sie tun (lock), dann tun die Arbeiter arbeiten, der immer die nächste id und entsperren)

    1. lock
    2. um den letzten Schlüssel aus der erstellten Tabelle
    3. Inkrementieren und speichern
    4. entsperren

    verwenden Sie dann den neuen Wert ein.

    InformationsquelleAutor der Antwort Jason Haley

  2. 12

    Für alle, die finden es in der Suche, es ist eine bessere Lösung. Minimale Zeit für die Tabelle gesperrt wird 15 Sekunden - das ist schrecklich. Nicht verwenden, wenn Sie möchten, eine wirklich skalierbare Lösung. Verwenden Etag!

    Erstellen einer Entität in der Tabelle für ID (Sie können auch Namen als ID oder was auch immer).

    1) Lesen es.

    2) Erhöhen.

    3) InsertOrUpdate MIT ETag angegeben (aus der read-Abfrage).

    wenn der Letzte Betrieb (InsertOrUpdate) gelingt, dann haben Sie eine neue, einzigartige auto-increment-ID. Wenn es nicht (mit Ausnahme HttpStatusCode == 412), es bedeutet, dass einige andere client geändert. So, wieder 1,2 und 3.
    Die übliche Zeit für Read+InsertOrUpdate ist weniger als 200ms. Mein test-Dienstprogramm mit source auf github.

    InformationsquelleAutor der Antwort crea7or

  3. 5

    Sehen UniqueIdGenerator Klasse von Josh Twist.

    InformationsquelleAutor der Antwort Pavel Chuchuva

  4. 4

    Die Lösung, die ich gefunden, die verhindert, dass doppelte ids und ermöglicht Ihnen, autoincrement ist es zu

    1. lock (Mietvertrag) ein blob und lassen, die als eine logische gate.

    2. Lesen Sie dann den Wert.

    3. Schreiben der inkrementierten Wert

    4. Release der Mietvertrag

    5. Verwenden Sie den Wert in Ihrem app/Tabelle

    Dann, wenn Sie Ihre worker-Rolle wurden zu Absturz während dieses Prozesses, dann würden Sie nur eine fehlende ID im store. IMHO, ist besser als Duplikate.

    Hier ist ein Beispielcode und weitere Informationen auf diesen Ansatz von Steve Marx

    InformationsquelleAutor der Antwort random65537

  5. 3

    Wenn Sie wirklich brauchen, um zu vermeiden, guids, haben Sie sich überlegt, mit so etwas basierend auf Datum/Zeit, und dann nutzt partition Schlüssel zu minimieren, die Parallelität Risiko.

    Ihre partition Schlüssel könnte durch user, Jahr, Monat, Tag, Stunde, etc, und die Zeile Schlüssel, könnte der rest des datetime-auf eine genügend kleine Zeitspanne zur Steuerung der Parallelität.

    Natürlich fragt man sich, bei dem Preis aktuell in Azure, wenn die Vermeidung einer Guid ist wirklich Wert, alle von diesen zusätzlichen Aufwand (vorausgesetzt wird eine Guid nur Arbeit).

    InformationsquelleAutor der Antwort Scott Watermasysk

Schreibe einen Kommentar