Rendimiento de almacenamiento de tablas Azure a partir de lectura paralela masiva paralela

Question

Versión corta: ¿Podemos leer docenas o cientos de particiones de tablas de múltiples hilos para aumentar el rendimiento en órdenes de magnitud?

Versión larga: Estamos trabajando en un sistema que almacena millones de filas en el almacenamiento de tablas Azure. Particionamos los datos en particiones pequeñas, cada una contiene alrededor de 500 registros, lo que representa un día de datos para una unidad.

Dado que Azure no tiene una función de "suma", para extraer datos de un año, o bien tenemos que usar algo de precaching, o sumar los datos en una red Azure o rol de trabajador.

Suponiendo lo siguiente: - Lectura de una partición no afecta al rendimiento de otro - Lectura de una partición tiene un cuello de botella en base a la velocidad de la red y la recuperación del servidor

Entonces podemos tomar una conjetura que si queríamos para sumar rápidamente una gran cantidad de datos sobre la marcha (1 año, 365 particiones), podríamos usar un algoritmo masivamente paralelo y se escalaría casi perfectamente a la cantidad de hilos. Por ejemplo, podríamos usar las extensiones paralelas de .NET con más de 50 hilos y obtener un ENORME aumento de rendimiento.

Estamos trabajando en la configuración de algunos experimentos, pero quería ver si esto se ha hecho antes. Como el lado .NET está básicamente inactivo en espera en operaciones de alta latencia, esto parece perfecto para multi-threading.

Answer 1

Existen límites impuestos a la cantidad de transacciones que se pueden realizar contra una cuenta de almacenamiento y una partición o servidor de almacenamiento en particular en un período de tiempo determinado (alrededor de 500 req/s). Entonces, en ese sentido, existe un límite razonable para la cantidad de solicitudes que puede ejecutar en paralelo (antes de que empiece a parecer un ataque DoS).

Además, en la implementación, desconfiaría de los límites de conexión simultáneos impuestos al cliente, como por System.Net.ServicePointManager. No estoy seguro de si el cliente de almacenamiento de Azure está sujeto a esos límites; pueden requerir un ajuste.