L'Auto-incrémentation sur Azure Table Storage

Je suis actuellement en train de développer une application pour Azure Table Storage. Dans cette application, j'ai un tableau qui aura relativement peu d'insertions (un couple de mille/jour) et la clé primaire de ces entités sera utilisé dans un autre tableau, ce qui aura des milliards de lignes.

Donc je suis à la recherche d'une façon d'utiliser un auto-incrémenté entier, au lieu de GUID, comme clé primaire dans la table (car il permettra d'économiser beaucoup de rangement et d'évolutivité des plaquettes est pas vraiment un problème).

Il y a eu quelques discussions sur le sujet, par exemple sur la http://social.msdn.microsoft.com/Forums/en/windowsazure/thread/6b7d1ece-301b-44f1-85ab-eeb274349797.

Cependant, depuis les problèmes de simultanéité peut être vraiment difficile de déboguer et de spot, je suis un peu mal à l'aise avec la mise en œuvre de cette sur la propre. Ma question est donc si il y a un bien testé impelemntation?

Si votre vraiment inquiet sur elle, avoir une table dans SQL azure générer les valeurs d'identité?
C'est une très bonne suggestion. Cependant, cela voudrait me forcer à l'installation de mon SQL-server, SQL Azure Services de Données ne prend pas en charge l'identité des colonnes: shanmcarthur.net/cloud-services/... .

OriginalL'auteur Yrlec | 2009-12-08

  1. 4

    Je n'ai pas encore mis en œuvre cette encore, mais y travaille ...

    Vous pourriez semences d'une file d'attente de votre prochaine identifiants à utiliser, puis il suffit de les ramasser à la file d'attente lorsque vous en avez besoin.

    Vous avez besoin de garder un tableau pour contenir la valeur du plus grand nombre ajouté à la file d'attente. Si vous savez que vous ne serez pas à l'aide d'une tonne de nombres entiers, vous pourriez avoir un travailleur chaque tellement souvent se réveiller et assurez-vous que la file d'attente a toujours des nombres entiers. Vous pourriez également avoir utilisé int file d'attente le travailleur pourrait vérifier pour garder un œil sur l'utilisation.

    Vous pouvez également crochet que travailleur jusqu'donc, si la file d'attente était vide lors de votre code a besoin d'un identifiant (par hasard), il peut perturber le travailleur de la sieste pour créer plus de touches les plus brefs délais.

    Si cet appel n'a pas été vous avez besoin d'une façon de (dites le travailleur que vous allez faire le travail pour eux (lock), puis de faire les travailleurs de l'obtention de la prochaine id et déverrouiller)

    1. de verrouillage
    2. obtenir la dernière touche créé à partir de la table
    3. incrémenter et enregistrer
    4. déverrouiller

    ensuite utiliser la nouvelle valeur.

    Mais comment ne une file d'attente de garantie que l'id en double ne sont pas créés? Ce que je peux comprendre à partir de download.microsoft.com/download/5/2/D/... est qu'un message est ajouté à la file d'attente à nouveau si un travailleur processus échoue lors du traitement de la file d'attente de message. Vous devez donc faire le travail sur le rôle de travailleur idempotent. Si le même message (c'est à dire le même ID) est utilisé par les deux différents rôles de travail je ne vois pas comment vous pouvez faire ce que idempotent.
    Si vous avez seulement 1 woker de la création de l'id puis dup serait mis dans la file d'attente. Lors de l'extraction de l'id de la file d'attente, le message, puis supprimer le message avant d'utiliser le message contenu (id). Que devraient s'assurer qu'aucune id sont utilisés plus d'une fois. Semble que le pire scénario serait alors vous risquez de perdre la clé, mais votre unicité doit encore être bonne.
    La deuxième phrase ci-dessus devrait être: "Si vous avez seulement 1 woker de la création de l'id puis de dup ne pas être mis dans la file d'attente ..."

    OriginalL'auteur Jason Haley

  2. 12

    Pour tout le monde qui le trouverez dans la recherche, il est une meilleure solution. Peu de temps pour verrouiller la table est de 15 secondes - c'est affreux. Ne l'utilisez pas si vous voulez créer une véritable solution évolutive. Utilisation Etag!

    Créer une entité dans le tableau pour ID (vous pouvez même nom que l'ID ou quoi que ce soit).

    1) Lire.

    2) Incrément.

    3) InsertOrUpdate AVEC ETag spécifié (à partir de la lecture de la requête).

    si la dernière opération (InsertOrUpdate) réussit, vous avez un nouveau, unique, auto-incrémenté ID. Si elle échoue (à l'exception HttpStatusCode == 412), cela signifie qu'un autre client a changé. Donc, répétez le 1,2 et 3.
    L'heure habituelle pour Read+InsertOrUpdate est à moins de 200ms. Mon utilitaire de test avec source sur github.

    Une excellente idée.
    que penser de l'utilisation EGTs pour garantir des opérations atomiques, de lire et d'incrément? Est qu'un moyen viable de le faire? docs.microsoft.com/en-gb/azure/storage/...

    OriginalL'auteur crea7or

  3. 5

    Voir UniqueIdGenerator classe par Josh Torsion.

    Ce billet de blog est incroyable!

    OriginalL'auteur Pavel Chuchuva

  4. 4

    La solution que j'ai trouvé qui empêche id en double et vous permet de autoincrement il est à

    1. de verrouillage (location) blob et la laisser agir comme une porte logique.

    2. Puis lire la valeur.

    3. Écrire la valeur incrémentée

    4. Libérer le bail

    5. Utiliser la valeur de votre application/table

    Alors si votre rôle de travail ont été plantage au cours de ce processus, alors qu'un ID manquant dans votre magasin. À mon humble avis c'est mieux que de le reproduire.

    Ici est un exemple de code et plus d'informations sur cette approche de Steve Marx

    OriginalL'auteur random65537

  5. 3

    Si vous avez vraiment besoin pour éviter les guid, avez-vous envisagé d'utiliser quelque chose basé sur la date/heure, puis en tirant parti de clés de partition afin de minimiser la simultanéité des risques.

    Votre clé de partition pourrait être par l'utilisateur, année, mois, jour, heure, etc et la touche de ligne qui pourrait être le reste de la date à un assez petit laps de temps pour le contrôle de la simultanéité.

    Bien sûr, vous devez vous demander, au prix de date dans Azure, s'évitant un Guid est très important de cet effort supplémentaire (en supposant un Guid tout fonctionne).

    OriginalL'auteur Scott Watermasysk