Diseño de tablas escalables y eficaces
Sugerencia
El contenido de este artículo se aplica al servicio original Azure Table Storage. Sin embargo, los mismos conceptos se aplican a la versión más reciente de Azure Cosmos DB for Table, que ofrece un mayor rendimiento y disponibilidad, distribución global e índices secundarios automáticos. También está disponible en un modo sin servidor basado en el consumo. Hay varias diferencias en las características entre Table API en Azure Cosmos DB y Azure Table Storage. Para obtener más información, consulte Azure Cosmos DB for Table. Para facilitar el desarrollo, ahora proporcionamos un SDK de Azure Tables unificado que se puede usar para dirigirse tanto al almacenamiento de Azure Table como a Azure Cosmos DB for Table.
Para diseñar tablas escalables y de alto rendimiento, debe tener en cuenta una serie de factores, como el rendimiento, la escalabilidad y el costo. Si anteriormente ha diseñado esquemas de bases de datos relacionales, estas consideraciones le serán familiares, pero aunque hay algunas similitudes entre los modelos relacionales y el modelo de almacenamiento de Azure Table service, también existen diferencias importantes. Normalmente, estas diferencias conducen a diseños diferentes que pueden parecer no intuitivos o incorrectos para alguien que esté familiarizado con las bases de datos relacionales, pero que sí tienen sentido si va a diseñar un almacén de claves/valores de NoSQL como Azure Table service. Muchas de sus diferencias de diseño reflejan el hecho de que Table service está diseñado para admitir aplicaciones de escala de nube que pueden contener miles de millones de entidades (o filas en terminología de bases de datos relacionales) de datos o conjuntos de datos que deben admitir volúmenes elevados de transacciones. Por lo tanto, debe pensar de forma diferente en cómo almacenar los datos y comprender cómo funciona Table service. Un almacén de datos NoSQL bien diseñado puede permitir que su solución se escale mucho más (y a un costo más bajo) que una solución que utiliza una base de datos relacional. Esta guía le ayuda con estos temas.
Acerca de Azure Table service
En esta sección se resaltan algunas de las características clave de Table service que son especialmente importantes para obtener un diseño que confiera rendimiento y escalabilidad. Si no conoce bien Azure Storage y Table service, consulte primero Introducción a Azure Table Storage mediante .NET antes de leer el resto de este artículo. Aunque esta guía se centra en Table service, incluye información sobre los servicios Azure Queue y Blob service, y cómo usarlos con Table service.
¿Qué es Table service? Como cabría esperar por su nombre, Table service usa un formato tabular para almacenar los datos. En la terminología estándar, cada fila de la tabla representa una entidad y las columnas almacenan las distintas propiedades de la entidad. Cada entidad tiene un par de claves que la identifican de forma única, y una columna de marca de tiempo que usa Table service para realizar el seguimiento de cuándo se actualizó la entidad por última vez. La marca de tiempo se aplica automáticamente y no se puede sobrescribir manualmente con un valor arbitrario. Table service usa esta última marca de tiempo modificada (LMT) para administrar la simultaneidad optimista.
Nota
Las operaciones de API REST de Table service también devuelven un valor ETag que se obtiene del LMT. En este documento se usan los términos ETag y LMT indistintamente porque hacen referencia a los mismos datos subyacentes.
En el ejemplo siguiente se muestra el diseño de una tabla sencilla para almacenar las entidades employee y department. Muchos de los ejemplos que se muestran más adelante en esta guía se basan en este diseño simple.
| PartitionKey | RowKey | Timestamp | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Marketing | 00001 | 2014-08-22T00:50:32Z |
| ||||||||
| Marketing | 00002 | 2014-08-22T00:50:34Z |
| ||||||||
| Marketing | department | 2014-08-22T00:50:30Z |
|
||||||||
| Sales | 00010 | 2014-08-22T00:50:44Z |
|
Hasta ahora, estos datos aparecen como en una tabla de una base de datos relacional, siendo las diferencias principales las columnas obligatorias y la posibilidad de almacenar varios tipos de entidad en la misma tabla. Además, cada una de las propiedades definidas por el usuario como FirstName o Age tienen un tipo de datos, como un número entero o una cadena, lo mismo que una columna de una base de datos relacional. Aunque a diferencia de una base de datos relacional, la naturaleza sin esquema de Table service significa que una propiedad no necesita tener los mismos tipos de datos en cada entidad. Para almacenar tipos de datos complejos en una sola propiedad, debe utilizar un formato serializado como JSON o XML. Para obtener más información sobre Table service, como los tipos de datos admitidos, los intervalos de fechas admitidos, las reglas de nomenclatura y las restricciones de tamaño, consulte Introducción al modelo de datos de Table service.
La elección de PartitionKey y RowKey es fundamental para un buen diseño de tabla. Todas las entidades almacenadas en una tabla deben tener una combinación única de PartitionKey y RowKey. Al igual que con las claves de una tabla de base de datos relacional, los valores PartitionKey y RowKey se indexan para crear un índice agrupado para permitir búsquedas rápidas. Sin embargo, Table service no crea índices secundarios, por lo que PartitionKey y RowKey son las únicas propiedades indexadas. Algunos de los patrones descritos en Patrones de diseño de tablas ilustran cómo puede solucionar esta limitación aparente.
Una tabla consta de una o varias particiones, y muchas de las decisiones de diseño que tome estarán relacionadas con la elección de un valor adecuado de PartitionKey y RowKey para optimizar la solución. Una solución puede constar de una única tabla que contenga todas las entidades organizadas en particiones, pero normalmente las soluciones tendrán varias tablas. Tablas le ayuda a organizar las entidades de manera lógica, le ayudará a administrar el acceso a los datos mediante listas de control de acceso y puede quitar una tabla completa mediante una sola operación de almacenamiento.
Particiones de tabla
El nombre de la cuenta, el nombre de la tabla y PartitionKey juntos identifican la partición dentro del servicio de almacenamiento donde Table service almacena la entidad. Además de ser parte del esquema de direccionamiento de las entidades, las particiones definen un ámbito para las transacciones (vea Transacciones de grupo de entidad a continuación) y forman la base de cómo escala Table service. Para más información sobre las particiones, consulte Lista de comprobación de escalabilidad y rendimiento para Table Storage.
En Table service, un nodo individual da servicio a una o más particiones completas y el servicio se escala equilibrando dinámicamente la carga de las particiones entre los nodos. Si un nodo está bajo carga, Table Service puede dividir el intervalo de particiones atendidas por ese nodo en nodos diferentes; cuando el tráfico disminuye, el servicio puede combinar los intervalos de la partición de nodos silenciosos a un único nodo.
Para obtener más información acerca de los detalles internos de Table service y saber en particular cómo administra las particiones, consulte el artículo Microsoft Azure Storage: Un servicio de almacenamiento en nube altamente disponible con gran coherencia.
Transacciones de grupo de entidad
En Table service, las transacciones de grupo de entidad (EGT) son el único mecanismo integrado para realizar actualizaciones atómicas en varias entidades. Las EGT se conocen en ocasiones como transacciones por lotes. Las EGT solo pueden funcionar en entidades almacenadas en la misma partición (es decir, que comparten la misma clave de partición en una tabla determinada). Así que cada vez que necesite un comportamiento de transacciones atómico entre varias entidades, debe asegurarse de que esas entidades estén en la misma partición. Este suele ser un motivo para mantener varios tipos de entidad en la misma tabla (y partición) y no utilizar varias tablas para diferentes tipos de entidad. Una sola EGT puede operar en 100 entidades como máximo. Si envía varias EGT simultáneas para procesamiento, es importante asegurarse de que esas EGT no se usan en las entidades que son comunes a todas las EGT, ya que de lo contrario se puede retrasar el procesamiento.
Las EGT también presentan posibles ventajas e inconvenientes que es necesario evaluar en el diseño. Es decir, usar más particiones aumenta la escalabilidad de la aplicación, porque Azure tiene más oportunidades para equilibrar la carga de solicitudes entre los nodos. Sin embargo, también podría ser un inconveniente al limitar la capacidad de la aplicación para realizar transacciones atómicas y mantener una fuerte coherencia de los datos. Además, existen objetivos de escalabilidad específicos en el nivel de una partición que podrían limitar el rendimiento de las transacciones que se puede esperar de un único nodo. Para obtener más información sobre los objetivos de escalabilidad de cuentas de almacenamiento estándar, consulte Objetivos de escalabilidad para cuentas de almacenamiento estándar. Para más información acerca de los objetivos de escalabilidad de Table service, consulte Objetivos de escalabilidad y rendimiento para Table Storage.
Consideraciones de capacidad
La tabla siguiente describe la capacidad, escalabilidad y los objetivos de rendimiento de Table Storage.
| Recurso | Destino |
|---|---|
| Número de tablas en una cuenta de Azure Storage | Solo limitadas por la capacidad de la cuenta de almacenamiento |
| Número de particiones en una tabla | Solo limitadas por la capacidad de la cuenta de almacenamiento |
| Número de entidades de una partición | Solo limitadas por la capacidad de la cuenta de almacenamiento |
| Tamaño máximo de una tabla individual | 500 TiB |
| Tamaño máximo de una única entidad, incluidos todos los valores de propiedad | 1 MiB |
| Número máximo de propiedades de una entidad de tabla | 255 (incluyendo las tres propiedades de sistema: PartitionKey, RowKey y Timestamp) |
| Tamaño máximo total de una propiedad individual en una entidad | Varía en función del tipo de propiedad. Para obtener más información, consulte los tipos de propiedades en la descripción del modelo de datos del servicio Tabla. |
| Tamaño de la PartitionKey | Una cadena de hasta 1 KB |
| Tamaño de la RowKey | Una cadena de hasta 1 KB |
| Tamaño de una transacción de un grupo de entidades | Una transacción puede incluir como máximo 100 entidades y la carga debe ser inferior a 4 MiB. Una transacción de un grupo de entidades solo puede incluir una actualización de una entidad. |
| Número máximo de directivas de acceso almacenadas por tabla | 5 |
| Tasa de solicitud total por cuenta de almacenamiento | 20 000 transacciones por segundo, lo que supone un tamaño de entidad de 1 KiB |
| Rendimiento de destino de una sola partición de tabla (entidades de 1 KiB) | Hasta 2000 entidades por segundo |
Consideraciones sobre el costo
El almacenamiento en tablas es relativamente económico, pero debe incluir las estimaciones de costos por el uso de capacidad y la cantidad de transacciones, como parte de la evaluación de cualquier solución de Table service. Sin embargo, en muchos escenarios, el almacenamiento de datos duplicados o sin normalizar para mejorar el rendimiento o la escalabilidad de su solución es un enfoque válido. Para obtener más información sobre los precios, consulte Precios de Azure Storage.