precios - Rendimiento-Servicio de tabla, SQL Azure-insertar. Velocidad de consulta en una gran cantidad de datos

manage azure

Question

Había leído muchas publicaciones y artículos sobre la comparación de SQL Azure y Table Service, y la mayoría de ellos me dijeron que Table Service es más escalable que SQL Azure.

• http://www.silverlight-travel.com/blog/2010/03/31/azure-table-storage-sql-azure/
• http://www.intertech.com/Blog/post/Windows-Azure-Table-Storage-vs-Windows-SQL-Azure.aspx
• Almacenamiento de Microsoft Azure vs. Azure SQL Database
• https://social.msdn.microsoft.com/Forums/en-US/windowsazure/thread/2fd79cf3-ebbb-48a2-be66-542e21c2bb4d
• https://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-azure-storage-abstractions-and-their-scalability-targets.aspx
• https://stackoverflow.com/questions/2711868/azure-performance
• http://vermorel.com/journal/2009/9/17/table-storage-or-the-100x-cost-factor.html
• Azure Tables o SQL Azure?
• http://www.brentozar.com/archive/2010/01/sql-azure-frequently-asked-questions/
• https://code.google.com/p/lokad-cloud/wiki/FatEntities

Lo siento por http, soy nuevo usuario> _ <Pero http://azurescope.cloudapp.net/BenchmarkTestCases/ benchmark muestra una imagen diferente.

Mi caso. Usando SQL Azure: una tabla con muchas inserciones, aproximadamente 172,000,000 por día (2000 por segundo). ¿Puedo esperar un buen rendimiento para las inserciones y seleccionar cuándo tengo 2 millones de registros o 9999 ... 9 mil millones de registros en una sola tabla?

Usando el servicio de tabla: una tabla con algunas particiones. El número de particiones puede ser grande, muy grande.

Pregunta n. ° 1: ¿el servicio de tabla tiene algunas limitaciones o mejores prácticas para crear muchas, muchas, muchas particiones en una sola tabla?

Pregunta n. ° 2: en una sola partición tengo una gran cantidad de entidades pequeñas, como en el ejemplo anterior de SQL Azure. ¿Puedo esperar un buen rendimiento para las inserciones y seleccionar cuándo tengo 2 millones de registros o 9999 millones de entidades en una partición?

Sé acerca de las soluciones de fragmentación o partición, pero es un servicio en la nube, ¿la nube no es potente y todo funciona sin mis conocimientos de código?

Pregunta n. ° 3: ¿Alguien puede mostrarme puntos de referencia para cuestionar una gran cantidad de datos para SQL Azure y Table Service?

Pregunta # 4: Puede ser que pueda sugerir una mejor solución para mi caso.

Answer 1

Respuesta corta

1. No he visto muchas particiones causar problemas con Azure Tables (AZT), pero no tengo este volumen de datos.
2. Cuantos más elementos haya en una partición, más lentas serán las consultas en esa partición
3. Lo siento, no, no tengo los puntos de referencia
4. Vea abajo

Respuesta larga

En su caso, sospecho que SQL Azure no funcionará para usted, simplemente debido a los límites en el tamaño de una base de datos SQL Azure. Si cada una de esas filas que está insertando son 1K con índices, alcanzará el límite de 50 GB en aproximadamente 300 días. Es cierto que Microsoft está hablando de bases de datos de más de 50 GB, pero no han dado ningún marco de tiempo sobre eso. SQL Azure también tiene un límite de rendimiento que no puedo encontrar en este momento (estoy bastante seguro de que es menos de lo que necesita). Es posible que pueda evitar esto dividiendo sus datos en más de una base de datos SQL Azure.

Sin embargo, la ventaja que tiene SQL Azure es la capacidad de ejecutar consultas agregadas. En AZT, ni siquiera puede escribir un select count(*) from customer sin cargar a cada cliente.

AZT también tiene un límite de 500 transacciones por segundo por partición y un límite de "varios miles" por segundo por cuenta .

Descubrí que elegir qué usar para su clave de partición (PK) y clave de fila depende (RK) de cómo va a consultar los datos. Si desea acceder a cada uno de estos elementos individualmente, simplemente dele a cada fila su propia clave de partición y una clave de fila constante. Esto significará que tiene mucha partición.

A modo de ejemplo, si estas filas que estaba insertando son órdenes y las órdenes pertenecen a un cliente. Si fuera más común que liste pedidos por cliente, tendría PK = CustomerId, RK = OrderId. Esto significaría encontrar pedidos para un cliente que simplemente debe consultar en la clave de partición. Para obtener un pedido específico, debe conocer CustomerId y OrderId. Cuantos más pedidos tenía un cliente, más lenta era la búsqueda de un pedido en particular.

Si solo necesita acceder a los pedidos solo por OrderId, entonces usaría PK = OrderId, RK = string.Empty y colocaría CustomerId en otra propiedad. Si bien aún puede escribir una consulta que devuelve todos los pedidos para un cliente, porque AZT no admite índices que no sean PartitionKey y RowKey si su consulta no utiliza una PartitionKey (y, a veces, incluso si lo hace según cómo escriba ellos) causará un escaneo de tabla. Con la cantidad de registros de los que habla, sería muy malo.

En todos los escenarios que he encontrado, tener muchas particiones no parece preocupar demasiado a AZT.

Otra forma de dividir los datos en AZT que no se menciona a menudo es colocar los datos en tablas diferentes. Por ejemplo, es posible que desee crear una tabla para cada día. Si desea ejecutar una consulta para la semana pasada, ejecute la misma consulta en comparación con las 7 tablas diferentes. Si está preparado para trabajar un poco en el extremo del cliente, incluso puede ejecutarlos en paralelo.