Pregunta

Estoy en la etapa de planificación de una aplicación web que tendrá lugar en Azure con ASP.NET para el sitio web y Silverlight dentro del sitio para una rica experiencia de usuario. ¿Debo usar las tablas de Azure o SQL Azure para almacenar los datos de mi solicitud?

¿Fue útil?

Solución

Azure Storage Table parece ser menos caro que SQL Azure. También es más altamente escalable que SQL Azure.

SQL Azure es más fácil trabajar con si usted ha estado haciendo mucho trabajo de base de datos relacional. Si estaba transfiriendo una aplicación que ya estaba utilizando una base de datos SQL, y luego moverlo a SQL Azure sería la opción obvia, pero esa es la única situación en la que se lo recomendaría.

La principal limitación en las tablas de Azure es la falta de índices secundarios. Esto fue anunciado en el PDC '09 y actualmente aparece como muy pronto, pero no ha habido ningún tipo de anuncio-marco de tiempo. (Ver http :? ref = //windowsazure.uservoice.com/forums/34192-windows-azure-feature-voting/suggestions/396314-support-secondary-indexes título)

he visto el uso propuesto de un sistema híbrido en el que utiliza la tabla y el almacenamiento de blob para la mayor parte de sus datos, pero el uso de SQL Azure para los índices, búsqueda y filtrado. Sin embargo, no he tenido la oportunidad de probar que la solución aún a mí mismo.

Una vez que los índices secundarios se añaden al almacenamiento de tablas, que será esencialmente una nube basado NoSQL sistema y será mucho más útil de lo que es ahora.

Otros consejos

A pesar de nombres similares Tablas SQL Azure y almacenamiento de tablas tienen muy poco en común.

Aquí hay dos enlaces que pueden ayudarle a:

Básicamente, la primera pregunta que debe preguntarse acerca es ¿Mi aplicación realmente necesita a escala? Si no, entonces ir para SQL Azure.

Para aquellos que tratan de decidir entre las dos opciones, asegúrese de requisitos de presentación de informes de los factores en la ecuación. SQL Azure Reporting y otros productos de informes de soporte de SQL Azure fuera de la caja. Si necesita generar informes complejos o flexibles, es probable que desee para evitar la tabla de almacenamiento.

mesas de Azure son más baratos, más simple y la escala mejor que SQL Azure. SQL Azure es un entorno SQL administrado, múltiples usuarios en la naturaleza, por lo que debe analizar si sus requisitos de rendimiento son aptos para SQL Azure. Una versión de pago de SQL Azure se ha anunciado y está en la vista previa de este escrito (ver AQUÍ ).

Creo que los factores decisivos para decidir entre las tablas de Azure SQL Azure y son los siguientes:

  • ¿Es necesario hacer complejo se une y utilizar índices secundarios? En caso afirmativo, SQL Azure es la mejor opción.
  • ¿Necesita procedimientos almacenados? En caso afirmativo, SQL Azure.
  • ¿Necesita capacidades de auto-escala? tablas de Azure es la mejor opción.
  • Las filas dentro de una tabla de Azure no puede exceder 4 MB de tamaño. Si necesita almacenar grandes cantidades de datos dentro de una fila, es mejor almacenarlo en el almacenamiento de blob y hacer referencia URI de la burbuja en la fila de tabla.
  • ¿Es necesario almacenar grandes cantidades de datos semi-estructurados? En caso afirmativo, tablas de Azure son ventajosas.

A pesar de tablas de Azure son tremendamente beneficioso en términos de simplicidad y rentabilidad, hay algunas limitaciones que deben ser tenidas en cuenta. Por favor, vea AQUÍ para una orientación inicial.

Otra consideración es la latencia. No solía ser un sitio que Microsoft corrió con microbenchmarks sobre el rendimiento y la latencia de varios tamaños de objetos con tienda de mesa y SQL Azure. Desde ese sitio es ya no está disponible, sólo te voy a dar una aproximación de lo que recuerdo. tienda de la tabla tiende a tener mucho más alto rendimiento de SQL Azure. SQL Azure tiende a tener menor latencia (por tanto como 1 / quinto).

Ha sido ya mencionado esa tienda tabla es fácil de escala. Sin embargo, SQL Azure puede escalar, así como con Federaciones . Tenga en cuenta que las federaciones (efectivamente sharding ) añade mucha complejidad a su aplicación. También estoy seguro de cómo mucho Federaciones afecta al rendimiento, pero me imagino que hay algo de sobrecarga.

Si la continuidad del negocio es una prioridad, tenga en cuenta que con Azure de almacenamiento se obtiene barato geo-replicación por defecto. Con SQL Azure, se puede lograr algo similar pero con un mayor esfuerzo con SQL Data Sync . Tenga en cuenta que SQL Data Sync rendimiento también incurre en gastos generales, ya que requiere disparadores en todas sus tablas para observar los cambios de datos.

Me di cuenta que es una vieja pregunta, pero sigue siendo una muy válida, así que estoy añadiendo mi respuesta a la misma.

CoderDennis y otros han señalado algunos de los hechos - Tablas Azure es más barato, y las tablas de Azure puede ser mucho más grande, más eficiente, etc. Si no está 100% seguro de que se quede con Azure, ir con las tablas.

Sin embargo, esto presupone que ya ha decidido sobre Azure. Mediante el uso de las tablas de Azure, está fijando a sí mismo en la plataforma Azure. Esto significa que escribir código muy específica a las tablas de Azure que no es sólo ir a puerto a través de Amazon, tendrá que volver a escribir esas áreas de su código. Por otro lado la programación de una base de datos SQL con el puerto voluntad sobre LINQ mucho más fácilmente a otro servicio en la nube.

Esto no puede ser un problema si ya ha decidido sobre su plataforma en la nube.

Sugiero mirar Azure caché en combinación con Azure tabla. Tabla solo tiene 200-300ms latencias, con picos ocasionales más altas, que puede tiempos de respuesta de manera significativa lentos / UI de interactividad. Cache + Tabla parece ser una combinación ganadora, para mí.

En su pregunta, yo quiero hablar de cómo decidir con la lógica elija Tabla SQL y el que tenga que utilizar Azure tabla.

Como sabemos tabla de SQL es un motor de base de datos relacional. pero si usted tiene unos grandes volúmenes de datos en una tabla de la tabla de SQL no es aplicable, ya que SQL de consulta GET grandes volúmenes de datos es lenta.

En este momento se puede elegir Azure tabla, la consulta Azure tabla es tan rápido, entonces la tabla de SQL para grandes volúmenes de datos, por ejemplo, en nuestra página web, alguien suscrito muchos artículos, hacemos el artículo como alimentación para el usuario, cada usuario tiene una copia del título del artículo y descripción, por lo que en la tabla de artículos hay un montón de datos, si utilizamos la tabla de SQL, cada ejecución de la consulta tal vez toma más de 30 segundos. Pero en Azure Tabla conseguir que los usuarios artículo de alimentación por PartitionKey y rowKey es tan rápido.

A partir de este ejemplo, es posible saber cómo elegir entre en la tabla de SQL Azure y la tabla.

Me pregunto si vamos a terminar con algunas librerías API "nube proveedor independiente" a su debido tiempo?

Creo que tiene en primer lugar definir cuáles son sus embudos de uso de aplicaciones son. ¿Su modelo de datos se somete a cambios frecuentes o que es estable? Tienes que ser capaz de realizar inserciones ultra rápidos y las lecturas no son tan complicadas? ¿Necesita avanzar Google como búsqueda? Almacenar BLOBS?

Estas son las preguntas (y no sólo) que usted tiene que hacer y responder a sí mismo con el fin de decidir si está más probable que va a utilizar NoSQL o SQL enfoque en el almacenamiento de datos.

Por favor, considere que ambos enfoques pueden coexistir fácilmente y se puede ampliar con el almacenamiento BLOB también.

Los dos Tablas Azure y SQL Azure son dos diferentes beasts.Both están destinados para diferentes escenarios, uno con azul de mesa es que no se puede pasar de azul a cualquier otra plataforma, a menos que se escribe proveedores en su código que puede manejar tales cambios .

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top