¿Cuándo debería usar Sql Azure y cuándo debo usar Table Storage?

Question

¿Cuándo debería usar Sql Azure y cuándo debo usar Table Storage? Estaba pensando, utilice el almacenamiento de tablas para escenarios de procesamiento de transacciones, p. el escenario de cuentas de crédito de débito y usa Sql Azure cuando los datos no se utilizarán con fines transaccionales, por ejemplo, informes. ¿Qué opinas?

Answer 1

Esta es una pregunta excelente y una de las decisiones más difíciles y más difíciles de revertir que los arquitectos de soluciones tienen que hacer al diseñar para Azure.

hay dimensiones mutliple a considerar: En el lado negativo, SQL Azure es relativamente caro para gigabyte de almacenamiento, no escala muy bien y se limita a 150gigs/base de datos, sin embargo, y esto es muy importante, hay no hay tarifas de transacción contra SQL Azure y sus desarrolladores ya saben cómo codificar contra esto.

ATS es un animal diferente todos juntos. Capaz de mega-escalabilidad, es muy barato de almacenar, pero se vuelve costoso para acceder con frecuencia. También requiere una cantidad significativa de potencia de CPU de sus nodos para manipular. Básicamente obliga a los nodos de cálculo a convertirse en servidores mini-db a medida que se les transfiere la delegación de toda la actividad relacional.

Por lo tanto, en mi opinión, los datos a los que se accede con frecuencia y que no requieren gran escalabilidad y no son de gran tamaño deberían destinarse a SQL Azure; de ​​lo contrario, Azure Table Services.

Su ejemplo específico, los datos transaccionales de transacciones financieras son un lugar perfecto para ATS, mientras que la metainformación (perfiles de cuenta, nombres, direcciones, etc.) es perfecta para SQL Azure.

Answer 2

Cuando se trata de transacciones, es al revés: SQL Azure admite transacciones; el almacenamiento de tabla no.

SQL Azure es básicamente de SQL Server se ejecuta dentro de Windows Azure, así que si usted tiene una aplicación existente que utiliza SQL Server, SQL Azure proporciona una ruta de migración buena. Sin embargo, existen límites para la cantidad de una base de datos que puede tener en SQL Azure (actualmente 150 GB), por lo que hay límites en cuanto a la escala.

El almacenamiento de tablas, por otro lado, es extremadamente escalable, pero requiere una forma diferente de pensar. Es no una base de datos relacional. Ver p. este artículo para una buena introducción: http://msdn.microsoft.com/en-us/magazine/ff796231.aspx

Answer 3

Igor y Mark dieron excelentes respuestas. Permítanme agregar un poco más ...

Con SQL Database (anteriormente llamado SQL Azure), ahora puede tener bases de datos de hasta 500 GB. Para ir más allá, necesitarás dividir tus datos. Nota: Originalmente sugerí fragmentos con Federaciones SQL, pero esta característica se ha retirado desde entonces.

ATS ofrece transacciones a nivel de partición (transacciones de grupo de entidades). Vea this MSDN article para más información. Esto no es tan robusto como las transacciones de SQL Azure, pero permite operaciones por lotes en una sola transacción.

EDIT Ha pasado más de un año desde que se hizo esta pregunta (y se respondió). Un punto de comparación fue el precio. Si bien SQL Azure sigue siendo más costoso que ATS, el costo de SQL Azure ha disminuido significativamente en el último año. Las bases de datos ahora tienen precios escalonados, comenzando en $ 4.99 de 100 MB, lo que aumenta a $ 225 para 150 GB (una gran caída de los $ 9.99/precios GB desde el año pasado. Los detalles completos de precios son here.

EDITAR Aug 2014 Un año más tarde, otra actualización. Mientras que los niveles web/negocio continúan existiendo, están en extinción (y SQL Federations ya no está disponible). Los nuevos niveles básicos, estándar y Premium ahora están disponibles (vea here para más detalles)

Answer 4

Algunas de estas respuestas no parecen completas , así que agregaré mis 2 centavos.

Puntos buenos de la mesa azul:

• El punto fuerte es su capacidad para almacenar gran cantidad de datos; La tabla Azure se basa en Azure Blob, pero está orientada a datos más pequeños
• Mucho más barato que Azure SQL Server
• Cada vez que conoce tanto la clave de partición como la clave de fila, el acceso a los datos es muy rápido.
• Entity transactions son posibles si coloca dos "esquemas" diferentes en la misma clave de partición.
• Cuando el tamaño total de la fila es MENOS DE 980K (SQL fila)
• Donde cada propiedad está a menos de 64 K (Columna SQL)
• Puede actuar como SQL de un hombre pobre.

malos puntos de la tabla de Azure:

• SQL es el punto débil. No espere usar esto en ninguna tabla grande de SQL o sufrirá problemas de rendimiento.
• Limited SQL está disponible, no espere que se une de cualquier tipo, además de lo que se implementa en LINQ
• Azure tabla de SQL no escala, así como su capacidad de almacenar una cantidad infinita de datos
• Cada vez que se no especifique una clave de partición y una clave de fila en una cláusula WHERE, espere que se produzca una exploración de tabla lenta
• Espere que el rendimiento de exploración de tabla se degrade a medida que agregue más filas
• No espere que las consultas de Azue Table sean rápidas a medida que agrega más filas
• En pocas palabras, si está utilizando Azure Table para que funcione como SQL, no agregue muchas d ata Si tiene muchos datos (gigabytes), simplemente no planea obtener consultas SQL de alto rendimiento en su contra. Ahorrará dinero si no necesita esas características regulares de SQL.

Answer 5

La respuesta real es: "Intenta realmente no utilizar Azure Table Storage". Cada vez que pasa de una base de datos relacional a una base de datos no sql, tendrá que cambiar la forma en que piensa sobre su arquitectura de almacenamiento. Pero los problemas con ATS van mucho más allá de la necesidad de "pensar diferente". Como han señalado otras personas, no es solo un almacén de datos "sin SQL", es una instancia especialmente raquítica, discapacitada y con muy pocas características de una tienda sin SQL. No se trata de una necesidad de "pensar diferente" sobre ATS; es una cuestión de que ATS no le brinda las herramientas que necesita para hacer su trabajo, herramientas que le proporcionan otros almacenamientos de datos no sql .

Lo único bueno de ATS es que puede poner muchos datos en él muy rápidamente y con un mínimo de costos de almacenamiento.Sin embargo, básicamente no puede esperar recuperar esos datos nuevamente a menos que tenga la suerte de tener un caso de uso que coincida mágicamente con su modelo de almacenamiento Partition-Key/Row-Key. Si no lo hace, y sospecho que muy poca gente lo hace, hará muchos escaneos de particiones y procesará los datos usted mismo.

Más allá de eso, Azure Table Storage parece estar en un callejón sin salida en términos de desarrollo. Si mira la solicitud "Apoyar índices secundarios" en los foros de comentarios de Azure (http://feedback.windowsazure.com/forums/217298-storage/suggestions/396314-support-secondary-indexes), puede ver que la compatibilidad con los índices secundarios se prometió ya en 2011, pero no se ha realizado ningún progreso. Tampoco se ha progresado en ninguna de las otras solicitudes principales de almacenamiento de tabla.

Ahora, sé que Scott Guthrie es un chico de calidad, así que espero que todo este estancamiento en el frente de Table Storage sea un prefacio de Azure que lo arregle y proponga algo realmente genial. Esa es mi esperanza (aunque tengo cero evidencia de que es el caso). Pero por ahora, a menos que no tenga otra opción, lo recomiendo encarecidamente contra Azure Table Storage. Use Azure SQL; use su propia instancia de MongoDB o alguna otra base de datos sin SQL; o use Amazon DynamoDB. Pero no use Azure Table Storage.