Azure, architecture de la aplicación web MVC: ¿cómo dividir los datos entre SQL Azure y Azure Table Storage?

Estoy en la fase de planificación del tipo de networking social típico de una aplicación web. Tendrá perfiles, posts, chat instantáneo, álbumes, grupos, regalos virtuales, etc.

¿Cuáles son los factores decisivos que determinan qué datos deben almacenarse en SQL Azure y qué datos deben almacenarse en el Almacenamiento de tablas?

Antes de Azure, todos los datos relacionales se almacenaban en el server SQL y, a continuación, se usaba el almacenamiento en memory caching con objects de datos y el almacenamiento en caching de resultados de páginas para el performance y para facilitar la carga del server SQL.

¿Cómo encaja Azure Table Storage / cambia este enfoque?

SQL Azure

En el lado positivo de SQL Azure, es de libre acceso (sin costo para las transactions de almacenamiento) y es fácil trabajar con él (relacional, familiar para los desarrolladores, se puede modelar sin preocuparse por cómo funcionarán las consultas futuras, etc.)

En el lado negativo, SQL Azure no es mega escalable: incluso con Federaciones, cada database o miembro federado aún vive en un entorno multi-tenant con otras bases de datos y compiten entre sí en el mismo server para disco, CPU, RAM, etc. .

Desde la perspectiva de los precios, es más caro almacenar datos en SQL Azure que en Azure Table Storage, pero acceder a ellos es gratis (sin costo para las llamadas realizadas en la database de SQL Azure)

Azure Table Storage (ATS)

Lo positivo de Azure Storage: es mega-escalable y puede admitir montos de datos muy grandes. Básicamente, no hay un "cerebro relacional" detrás de ATS como si hubiera un cerebro detrás de SQL Server. Debido a esto, no está obligado por las limitaciones de tener un solo cerebro y delega todas las actividades relacionales en sus propios serveres / instancias, de los cuales puede tener tantos como desee. Esto le da la capacidad de mega escala.

En el lado negativo, ATS es más difícil de trabajar, porque tiene que modelar sus keys (PartitionKey y RowKey) muy particularmente en anticipación a sus consultas. Incluso podría necesitar duplicar datos de múltiples forms para que el acceso futuro a esos datos pueda ser muy optimizado y usar PartitionKey / RowKey de manera adecuada.

Desde la perspectiva de los precios, ATS es muy barato para almacenar datos, pero cobra por cada vez que accede (hay una tarifa por transacción). El precio se networkingujo recientemente en 10 veces, pero aún debe considerarse, como parte de su presupuesto

Sugerencia

Use ATS cuando necesite mega escala. Por ejemplo, si tiene un sitio social como Facebook, el lugar más importante para proporcionar la escala sería con el componente News Feed, ya que se accede a los datos con frecuencia y debe ser muy rápido.

utilice SQL Azure para el almacenamiento de datos jerárquico, donde las relaciones son más importantes y no se accede a ellas con demasiada frecuencia. Por ejemplo, información de perfil de sus usuarios (correo electrónico / dirección / inicio de session / preferences / etc.).

SO es más para preguntas de progtwigción específicas. Primero evalúe todo en SQL y vea cuánto costará. Si tiene muchos datos, Azure Table Storage (ATS) es más económico. ATS no tiene uniones. Un file de logging con una gran cantidad de datos es un candidato para ATS.

Intereting Posts