Limitations sur les comptes de stockage de la table Windows Azure

Il n'y a aucune limite au nombre de tables que vous pouvez créer dans Windows Azure. Vos seules limites sont celles que vous avez déjà répertoriées. Eh bien ... Je suppose qu'il existe d'autres limites si vous considérez que la taille de l'attribut d'entité est toujours de 64 Ko ou moins ou si vous envisagez des options de lot (100 entités ou 4 Mo, tout ce qui est le moins élevé).

De toute façon, la chose à garder à l'esprit ici est que votre partitioney va être la chose la plus importante que vous produisez. Si vous créez un PK avec le nom du client, vous obtenez de bons avantages de partitionnement. L'inconvénient est que si vous mélangez les données client dans la même table, vous rendez plus difficile la suppression de données (si vous avez besoin de supprimer un client). Vous pouvez donc utiliser la table comme un autre niveau de partitionnement. Le PK que vous créez est scopé à la table que vous le créez sous.

Ce que je considérerais ici, c'est si vous avez besoin de supprimer les données en vrac ou si vous avez besoin d'interroger des données entre les clients (locataires). Pour le premier, il offre une tonne de sens d'utiliser des tables distinctes par client afin qu'une suppression est une opération par rapport à la meilleure des 1 pour 100 entités. Toutefois, si vous devez interroger sur des locataires, il est plus difficile de rejoindre ces données lorsque vous avez plusieurs tables (qui nécessiteraient plusieurs requêtes).

Toutes choses étant égales, j'utiliserais les tables comme un autre niveau de partitionnement s'il n'y a pas de chevauchement dans la fonctionnalité des locataires et que ma vie plus facile si je souhaite supprimer un locataire. Donc, je suppose que c'est l'option 2.

htth

I suggère fortement l'option 2

Nous allons également faire cet itinéraire car il ajoute un niveau de nice ou une fédération pour les données client. Au fur et à mesure que le commentaire de réponse mentionne, il est plus facile de gérer l'ajout / la suppression de clients. Un autre avantage que nous avons remarqué est la «copie-aimable» des données clients. Cette approche facilite la possibilité de déplacer des données spécifiques au client vers d'autres comptes de stockage ou des environnements de développement pour les tests sans affecter le lot entier.

Dans le monde SaaS, il permet également aux clients d'obtenir une copie de leurs propres données avec peu d'effort, ce qui est également une préoccupation de nombreux utilisateurs de SaaS.

Une autre alternative: Imaginez que vous avez des comptes de stockage, la limite est de 100 comptes de stockage par abonnement. Chaque compte de stockage a une table par client.

1. Pour les opérations de demande de table avec la clé de partition, comme insertion, mise à jour, Supprimer ou une requête de point, vous calculez la valeur hachée de la clé de client +, calculez son modulaire de base N (nombre total de comptes de stockage), Recherchez l'index du compte de stockage exact et transférez la demande au bon compte de stockage / table de stockage.

2. Pour les demandes de lecture sans clé de partition, comme une interrogation de plage. Ensuite, vous auriez besoin de diffuser la demande à tous les comptes de stockage et de fusionner les résultats.

   L'une des autres choses à garder à l'esprit spécifiquement autour de la nommer plusieurs comptes de stockage. Évitez de nommer les comptes lexicographiquement, cela les obligera à être servi du même serveur de partition sur le backend d'azur et contre leurs meilleures pratiques de l'évolutivité recommandées. Si vous avez n compte de stockage. Préfixer chaque nom de compte de stockage avec un hachage à 3 chiffres, ils seraient donc uniformément distribués.