Azure Performances du stockage de table à partir de la lecture filaire massivement parallèle

Question

Version courte: Peut-on lire des dizaines ou des centaines de partitions de table de manière multithread pour augmenter les performances de plusieurs ordres de grandeur?

Version longue: Nous travaillons sur un système qui stocke des millions de lignes dans le stockage de table Azure. Nous partitionnons les données en petites partitions, chacune contenant environ 500 enregistrements, ce qui représente un jour de données pour une unité. Comme Azure n'a pas de fonction "somme", pour extraire une année de données, nous devons soit utiliser une pré-mise en cache, soit additionner nous-mêmes les données dans un rôle Web ou de travail Azure.

En supposant que les éléments suivants: - La lecture d'une partition n'affecte pas les performances d'un autre - La lecture d'une partition a un goulot d'étranglement en fonction de la vitesse du réseau et la récupération du serveur

On peut alors faire une supposition que si nous voulions Pour additionner rapidement un grand nombre de données à la volée (1 an, 365 partitions), nous pourrions utiliser un algorithme massivement parallèle et il s'agirait presque parfaitement du nombre de threads. Par exemple, nous pourrions utiliser les extensions parallèles .NET avec plus de 50 threads et obtenir une augmentation de performance énorme.

Nous travaillons sur la mise en place de certaines expériences, mais je voulais voir si cela a déjà été fait. Puisque le côté .NET est essentiellement inactif en attente d'opérations à latence élevée, cela semble parfait pour le multi-threading.

Answer 1

Le nombre de transactions pouvant être effectuées sur un compte de stockage et sur une partition ou un serveur de stockage particulier pendant une période donnée (environ 500 req/s) est limité. Donc, dans ce sens, il y a une limite raisonnable au nombre de requêtes que vous pourriez exécuter en parallèle (avant que cela commence à ressembler à une attaque DoS).

En outre, lors de la mise en œuvre, je me méfierais des limites de connexion simultanées imposées au client, comme par exemple System.Net.ServicePointManager. Je ne suis pas sûr si le client de stockage Azure est soumis à ces limites; ils pourraient nécessiter un ajustement.