login azure management portal

Diseño de particionamiento para Azure Table Storage

Question

Tengo un software que recopila datos durante un período de tiempo grande, aproximadamente 200 lecturas por segundo. Utiliza una base de datos SQL para esto. Estoy buscando usar Azure para mover una gran cantidad de mis datos "archivados" anteriores.

El software usa una arquitectura de tipo multi-tenant, por lo que estoy planeando usar una tabla Azure por inquilino. Cada inquilino quizás esté monitoreando de 10 a 20 métricas diferentes, por lo que estoy planeando usar la ID de métrica (int) como la clave de partición.

Como cada métrica solo tendrá una lectura por minuto (máximo), planeo usar DateTime.Ticks.ToString ("d19") como RowKey.

Sin embargo, me falta un poco de entendimiento sobre cómo se escalará esto; así que esperaba que alguien pudiera aclarar esto:

Para el rendimiento, Azure / podría dividir mi tabla por partición clave para mantener las cosas de forma rápida y agradable. Esto daría como resultado una partición por métrica en este caso.

Sin embargo, mi clave de fila podría representar datos durante aproximadamente 5 años, por lo que estimo aproximadamente 2,5 millones de filas.

¿Azure es lo suficientemente astuto como para dividirse según la clave de fila también, o estoy diseñando en un futuro cuello de botella? Normalmente sé que no debo optimizar prematuramente, ¡pero con algo como Azure que no parece tan sensato como es normal!

Estoy buscando un experto en Azure que me avise si estoy en la línea correcta o si también debería dividir mis datos en más tablas.

Answer 1

Pocos comentarios:

Además de almacenar los datos, es posible que también desee ver cómo desea recuperar los datos, ya que eso puede cambiar su diseño considerablemente. Algunas de las preguntas que quizás quiera hacerse:

• Cuando recupero los datos, ¿siempre recuperaré los datos para una métrica en particular y para un rango de fecha / hora?
• ¿O necesito recuperar los datos de todas las métricas para un rango de fecha / hora en particular? Si este es el caso, entonces está viendo la exploración de tabla completa. Obviamente, podrías evitar esto haciendo múltiples consultas (una consulta / PartitionKey)
• ¿Debo ver los resultados más recientes primero o realmente no me importa? Si es anterior, entonces su estrategia RowKey debería ser algo así como (DateTime.MaxValue.Ticks - DateTime.UtcNow.Ticks).ToString("d19") .

Además, dado que PartitionKey es un valor de cadena, es posible que desee convertir el valor int en un valor de string con un "0" prepading para que todos sus identificadores aparezcan en orden; de lo contrario obtendrá 1, 10, 11, ..., 19, 2 , ... etc.

Según mi leal saber y entender, Windows Azure divide los datos basados ​​en PartitionKey únicamente y no en RowKey . Dentro de una partición, RowKey sirve como clave única. Windows Azure intentará mantener los datos con la misma PartitionKey en el mismo nodo, pero dado que cada nodo es un dispositivo físico (y por lo tanto tiene una limitación de tamaño), los datos también pueden fluir a otro nodo.

Le recomendamos que lea esta publicación del blog del Equipo de almacenamiento de Windows Azure: http://blogs.msdn.com/b/windowsazurestorage/archive/2010/11/06/how-to-get-most-out-of-windows- azure-tables.aspx .

ACTUALIZACIÓN Con base en sus comentarios a continuación y parte de la información anterior, intentemos hacer algunos cálculos matemáticos. Esto se basa en los últimos objetivos de escalabilidad publicados aquí: http://blogs.msdn.com/b/windowsazurestorage/archive/2012/11/04/windows-azure-s-flat-network-storage-and-2012-scalability -targets.aspx . La documentación establece que:

Partición de tabla única: una partición de tabla son todas las entidades en una tabla con el mismo valor de clave de partición, y generalmente las tablas tienen muchas particiones. El objetivo de rendimiento para una sola partición de tabla es:

• Hasta 2,000 entidades por segundo
• Tenga en cuenta que esto es para una sola partición, y no para una sola tabla. Por lo tanto, una tabla con buenas particiones puede procesar hasta 20,000 entidades / segundo, que es el objetivo general de la cuenta descrito anteriormente.

Ahora mencionó que tiene entre 10 y 20 puntos métricos diferentes y para cada punto métrico escribirá un máximo de 1 registro por minuto, lo que significa que escribiría un máximo de 20 entidades / minutos / tabla que está muy por debajo del objetivo de escalabilidad de 2000 entidades / segundo.

Ahora la pregunta queda de leer. Suponiendo que un usuario lea un máximo de 24 horas de datos (es decir, 24 * 60 = 1440 puntos) por partición. Ahora suponiendo que el usuario obtiene los datos para las 20 métricas durante 1 día, cada usuario (y por lo tanto cada tabla) obtendrá un máximo de 28.800 puntos de datos. La pregunta que le queda, supongo, es cuántas solicitudes como esta puede obtener por segundo para cumplir ese umbral. Si de alguna manera podría extrapolar esta información, creo que puede llegar a alguna conclusión sobre la escalabilidad de su arquitectura.

También recomendaría ver este video también: http://channel9.msdn.com/Events/Build/2012/4-004 .

Espero que esto ayude.