Microservicios es la tendencia de arquitectura para muchos proyectos, ya sea corporativos, empresariales e incluso ampliamente aceptado por startups. Este estilo de arquitectura está enfocado en la independencia, y uno de los principios para garantizar esto es el principio de “cada microservicio debe tener su propia base de datos”. En la práctica, este es uno de los principios que más cuesta cumplir, ya sea por motivos de dependencia con repositorios de datos heredados, complejidad técnica y costos (que es una de las principales razones). Para poder abordar este principio en la práctica, muchos equipos recurren a estrategias válidas como tener una base de datos física compartida que se organiza por esquema, y cada esquema le pertenece a un microservicio de acuerdo a su dominio de negocio.

Aquí es donde entra Azure Table Storage, ya que puede ayudarte a cumplir ese principio de una forma más “natural” y económica.

Azure Table Storage es un servicio de Azure que se le puede considerar un servicio de base de datos NoSQL, con un estilo de almacenamiento “semi-estructurado”, ya que maneja un modelo “clave-valor” con propiedades flexibles. En detalle, la estructura de Table Storage se describe de la siguiente manera:

• Cada tabla almacena “entidades”, que vienen a ser el análogo de una fila en un esquema SQL o un documento en un esquema tipo MongoDB.
• Las entidades tienen una “clave única” obligatoria. Esta clave está conformada por el “PartitionKey” y “RowKey”.
• Cada entidad es flexible en cuanto a las “propiedades” (campos) en las que almacena valores o datos. Aquí es bastante parecido al estilo documental, pero con la limitante de que no soporta jerarquías ni anidamientos.
• No hay un concepto de “claves foráneas” para relacionar tablas y mantener integridad; por lo tanto, en la línea NoSQL esa integridad debe ser velada por la aplicación.

¿Por qué Table Storage es buen candidato para microservicios?

Una tabla de Table Storage es independiente en capacidad de almacenamiento, alta disponibilidad y escalabilidad. Todas estas capacidades se alinean con el principio de independencia de microservicios y permitirían cumplir con el principio de base de datos única. Por otro lado, en microservicios frecuentemente se necesita trabajar con un esquema flexible de datos semi-estructurado/no estructurado, y Table Storage ya está diseñado para esto, lo cual lo hace un gran candidato. Y, por último, pero no menos importante, el almacenamiento es muy económico. El costo sería por las consultas o lecturas, pero en un escenario bien controlado este coste debería ser bajo o moderado.

¿Qué consideraciones se deben tener para una buena implementación?

Table Storage es una buena opción, pero como todo en tecnología, se deben tener en cuenta algunas consideraciones y limitantes para las implementaciones:

• Algo clave es diseñar correctamente el PartitionKey y el RowKey. En términos generales, Azure Table Storage implementa sharding y cada PartitionKey representa un nodo dentro de su “cluster” de almacenamiento. En ese sentido, se debe buscar un balance para que el tamaño de las particiones no sea muy grande ni muy pequeño.
• Table Storage soporta hasta 20,000 solicitudes/segundo dentro de un mismo Account Storage. Este límite se debe tener en cuenta para la concurrencia, ya que será suficiente para la mayoría de cargas de trabajo e incluso altas cargas. Pero para cargas de trabajo de escala global y masiva, esto seguramente no será suficiente. Para este tipo de cargas se puede optar por Azure Cosmos DB API Tables.
• El RowKey representa la clave única dentro del PartitionKey y juntos representan la clave única a nivel de tabla. Una consulta de PartitionKey + RowKey es muy rápida, por el orden de los milisegundos. Algo clave a tener en cuenta sobre el RowKey es que Azure Tables devuelve los resultados ordenados alfabéticamente por el valor de RowKey, por lo cual en muchos casos se recomienda que sean valores que representen un orden lógico para el usuario, por ejemplo fechas/tiempo o códigos secuenciales.
• En Azure Tables se deben evitar los “Hot Partitions”. Esto quiere decir que el diseño de una partición puede hacer que todas las consultas vayan a una sola partición; esto puede saturar el motor incluso por valores menores del rango de 20,000 sol/segundo.
• En la práctica, un microservicio puede utilizar más de una tabla; esto va a depender de su propia lógica y del dominio que gestiona el microservicio.

Ejemplo práctico

En este ejemplo busco representar una API o servicio de incidentes. Estos incidentes son almacenados en un Table Storage. El PartitionKey es la fecha de captura del incidente y el RowKey es un código generado que incluye la fecha y un número secuencial. Este código puede servirte como referencia para saber cómo conectar tu aplicación con Azure Table Storage. Además, incluyo un benchmark que demuestra la velocidad de consulta de PartitionKey + RowKey.

Añado enlace a repositorio de código fuente. En este repositorio puedes encontrar, además, un archivo CSV “incidents_1m.csv”, que contiene un millón de registros para este caso de ejemplo. Puedes subir esta data fácilmente con Azure Data Factory y probar este caso de ejemplo.

Repositorio de ejemplo:dotnet API con Azure Table Storage :)

Por último dejo un diagrama de referencia de microservicios usando Azure Table Storage:

Conclusión

1. Azure Table Storage es una gran alternativa para microservicios; sus características lo hacen un gran candidato para cumplir con el principio de “base de datos única”, pero siempre se debe tener en cuenta los matices de nuestro propio caso de uso.
2. Si tu necesidad o solución te demanda el uso de relaciones estrictas, data estructurada y familiaridad SQL, Table Storage no es candidato para ese problema o solución.

---

Sígueme en Linkedin para estar al tanto de mis publicaciones y novedades

Referencias

• ¿Qué es Azure Table Storage?