Est-il préférable d'avoir plusieurs petits conteneurs d'objets blob de stockage Azure (chacun avec quelques objets blob) ou un très grand conteneur avec des tonnes d'objets blob?
Le scénario est donc le suivant:
J'ai plusieurs instances d'un service Web qui écrit un blob de données dans Azure Storage. J'ai besoin de pouvoir regrouper des objets blob dans un conteneur (ou un répertoire virtuel) selon le moment où il a été reçu. De temps en temps (tous les jours au pire), les blobs plus anciens seront traités puis supprimés.
J'ai deux options:
Option 1
Je crée un conteneur appelé "blobs" (par exemple), puis je stocke tous les blogs dans ce conteneur. Chaque objet blob utilisera un nom de style de répertoire, le nom du répertoire étant l'heure à laquelle il a été reçu (par exemple, "hr0min0/data.bin", "hr0min0/data2.bin", "hr0min30/data3.bin", "hr1min45/data.bin ", ...," hr23min0/dataN.bin ", etc - un nouveau répertoire toutes les [~ # ~] x [~ # ~] minutes ). La chose qui traite ces blobs traitera d'abord les blobs hr0min0, puis hr0minX et ainsi de suite (et les blobs sont toujours en cours d'écriture lors du traitement).
Option 2
J'ai de nombreux conteneurs dont chacun a un nom basé sur l'heure d'arrivée (donc sera d'abord un conteneur appelé blobs_hr0min0 puis blobs_hr0minX, etc.) et tous les blobs dans le conteneur sont les blobs qui sont arrivés à l'heure indiquée. La chose qui traite ces blogs traitera un conteneur à la fois.
Donc ma question est, quelle option est la meilleure? L'option 2 me donne-t-elle une meilleure parallélisation (puisqu'un conteneur peut se trouver sur différents serveurs) ou l'option 1 est-elle meilleure parce que de nombreux conteneurs peuvent provoquer d'autres problèmes inconnus?
Je ne pense pas que cela soit vraiment important (du point de vue de l'évolutivité/parallélisation), car le partitionnement dans le stockage d'objets blob Win Azure se fait au niveau de l'objet blob, pas au niveau du conteneur. Les raisons de se répartir sur différents conteneurs ont plus à voir avec le contrôle d'accès (par exemple SAS) ou la taille totale du stockage.
Voir ici pour plus de détails: http://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-Azure-storage-abstractions-and-their-scalability-targets.aspx
(Faites défiler jusqu'à "Partitions").
Citant:
Blobs - Étant donné que la clé de partition dépend du nom du blob, nous pouvons équilibrer l'accès aux différents blobs sur autant de serveurs afin d'en étendre l'accès. Cela permet aux conteneurs de grandir autant que vous en avez besoin (dans la limite d'espace du compte de stockage). Le compromis est que nous n'offrons pas la possibilité d'effectuer des transactions atomiques sur plusieurs objets blob.
Tout le monde vous a donné d'excellentes réponses concernant l'accès direct aux blobs. Cependant, si vous devez répertorier les objets blob dans un conteneur, vous verrez probablement de meilleures performances avec le modèle à plusieurs conteneurs. Je viens de parler avec une entreprise qui stocke un grand nombre de gouttes dans un seul conteneur. Ils répertorient fréquemment les objets dans le conteneur, puis effectuent des actions contre un sous-ensemble de ces objets blob. Ils voient un impact sur les performances, car le temps de récupérer une liste complète a augmenté.
Cela peut ne pas s'appliquer à votre scénario, mais c'est quelque chose à considérer ...
Théoriquement, il ne devrait pas y avoir de différence entre beaucoup de conteneurs ou moins de conteneurs avec plus de taches. Les conteneurs supplémentaires peuvent être Nice en tant que limites de sécurité supplémentaires (pour un accès public anonyme ou différentes signatures SAS par exemple). Les conteneurs supplémentaires peuvent également faciliter un peu l'entretien lors de l'élagage (supprimer un seul conteneur par rapport au ciblage). chaque blob). J'ai tendance à utiliser plus de conteneurs pour ces raisons (pas pour les performances).
Théoriquement, l'impact sur les performances ne devrait pas exister. Le blob lui-même (URL complète) est la clé de partition dans Windows Azure (depuis longtemps). C'est la plus petite chose qui sera équilibrée en charge à partir d'un serveur de partition. Ainsi, vous pourriez (et aurez souvent) deux blobs différents dans le même conteneur, servis par des serveurs différents.
Jeremy indique qu'il existe une différence de performances entre plus et moins de conteneurs. Je n'ai pas suffisamment creusé ces repères pour expliquer pourquoi cela pourrait être le cas, mais je soupçonnerais d'autres facteurs (comme la taille, la durée du test, etc.) pour expliquer toute divergence.
Il y a aussi un autre facteur qui entre en jeu. Prix!
La liste des opérations et le conteneur de création sont actuellement au même prix: 0,054 $ US/10 000 appels
Le même prix est en fait pour l'écriture de la goutte.
Donc, dans des cas extrêmes, vous pouvez payer beaucoup plus si vous créez et supprimez de nombreux conteneurs
- la suppression est gratuite
vous pouvez voir la calculatrice ici: https://Azure.Microsoft.com/en-us/pricing/calculator/