Desempeño de almacenamiento de tablas Azure: REST vs. StorageClient

Question

Estoy trabajando con Azure Table Storage y tratando de encontrar la mejor manera de aumentar el rendimiento. Las consultas que realizo son muy simples, ya sea una selección exacta usando la tecla de partición y la clave de fila, o una cláusula where con una lista (por ejemplo, WHERE x == 1 o x == 2 o x == 3, etc.). Una vez que recupero los datos, no los sigo en un contexto de datos (no es necesario el seguimiento de cambios, etc.). También guardo los datos, así que solo lo agrego al contexto para permitir el guardado.

Por el momento, estoy usando la biblioteca .NET (cliente de almacenamiento). Como no utilizo el seguimiento de cambios y otras características de TableServiceContext, estoy pensando en usar la API HTTP directamente. ¿Alguien ha probado ambas opciones? Si es así, ¿qué tipo de diferencia de rendimiento viste?

Gracias, Erick

Answer 1

de almacenamiento de tabla puede ser un poco de una bestia caprichosa para optimizar el rendimiento. Hay una variedad de factores que lo afectarán. Aquí están solo algunos de la cabeza:

1. Usar una clave de partición en cada consulta es imprescindible. Si no estás haciendo esto, lo estás haciendo mal. Si usa PK único y RK individual (y solo esos dos), ya no es una consulta, sino un recurso GET y debe ser relativamente instantáneo.
2. No utilice consultas basadas en O. Esto causará un escaneo completo de la tabla y su rendimiento será horrible. En cambio, paralelice esas consultas dentro de la instrucción OR.
3. La estrategia de partición tendrá un gran impacto. Cuántas particiones tiene y con qué frecuencia las golpea (para calentarlas y hacer que los servidores de particiones subyacentes equilibren la carga) provocará diferencias dramáticas. El tamaño de la partición también tiene un gran impacto aquí. Las claves de partición secuenciales a menudo son una mala idea.
4. Pequeñas solicitudes pueden beneficiarse de apagar el llanto (como se mencionó anteriormente).
5. Desactive el seguimiento de contexto y 100 continuar (see here) puede ayudar también.

Supongo que hay muchas más que dependen de su aplicación. Sin embargo, los que menciono son generalmente con los que empiezo.

Answer 2

¿Ha empezado Nagle fuera?

• Nagle’s Algorithm is Not Friendly towards Small Requests

De Interés:

• Maximizing Throughput in Windows Azure – Part 1