microsoft - porta azure

¿Cuándo debería usar Sql Azure y cuándo debería usar Table Storage? (5)

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

Puntos buenos de Azure Table:

El punto fuerte es su capacidad de almacenar muchos datos pequeños; 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 la partición como la clave de la 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.
Donde el tamaño total de la fila es MENOR A 980K (Fila de SQL)
Donde cada propiedad es MENOR A 64K (Columna SQL)
Puede actuar como SQL de un hombre pobre.

Puntos malos de la tabla azul:

SQL es el punto débil. No espere usar esto en ninguna tabla grande de SQL o sufrirá problemas de rendimiento.
SQL limitado está disponible, no esperes combinaciones de ningún tipo, además de lo que implementas en Linq
Azure Table SQL no escala tan bien como su capacidad para almacenar una cantidad infinita de datos
Cada vez que no especifique una clave de partición y una clave de fila en una cláusula WHERE, se espera que ocurra un escaneo lento de tabla
Espere que el rendimiento de escaneo de la tabla se degrade a medida que agrega 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 actuar como SQL, no agregue muchos datos. 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.

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

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

SQL Azure es básicamente SQL Server ejecutándose dentro de Windows Azure, por lo que si tiene una aplicación existente que usa SQL Server, SQL Azure proporciona una buena ruta de migración . 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. No es una base de datos relacional . Ver, por ejemplo, este artículo para una buena introducción: http://msdn.microsoft.com/en-us/magazine/ff796231.aspx

Esta es una excelente pregunta 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 varias dimensiones a considerar: en el lado negativo, SQL Azure es relativamente caro para el gigabyte de almacenamiento, no escala muy bien y está limitado a 150gigs / base de datos, sin embargo, y esto es muy importante, no hay costos de transacción en contra de SQL Azure y tus desarrolladores ya saben cómo codificarlo.

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 una gran escalabilidad y no son de gran tamaño deberían estar destinados a SQL Azure, de lo contrario los Servicios de tabla Azure.

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

Igor y Mark dieron excelentes respuestas. Déjame 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 retiró desde entonces.

ATS ofrece transacciones a nivel de partición (transacciones de grupo de entidades). Vea este artículo de MSDN 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.

EDITAR 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 por 100MB, aumentando a $ 225 por 150GB (una gran caída de los precios de $ 9.99 / GB del año pasado. Los detalles completos de precios están here .

EDITAR Aug 2014 Otro año después, otra actualización. Si bien los niveles web / empresariales continúan existiendo, se están cancelando (y las Federaciones SQL ya no están disponibles). Los nuevos niveles básicos, estándar y Premium ahora están disponibles (ver here para más detalles).

La verdadera respuesta es: "Intenta realmente no usar 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 otros almacenes de datos no-sql le ofrecen.

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 ese soporte para Los índices secundarios se prometieron ya en 2011, pero no se han realizado progresos. 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 que Azure 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.