La gran mayoría de las veces no es necesario conocer los límites de la tecnología con la cual estamos montando una solución, sobre todo porque ese límite es modificado con gran velocidad proporcionando cada vez una mayor capacidad y velocidad. Sin embargo, existen otros casos, en donde conocer estos límites es importante.

Les dejo aquí algunos datos que pueden ayudarnos a determinar algunas consideraciones de arquitectura.

En todos los casos, la tasa de requests y ancho de banda de la cuenta de Azure Storage depende del tamaño de los objetos almacenados, los patrones de acceso utilizados, y el tipo de carga que realiza la aplicación. Evite los picos repentinos de tráfico y garantizar que está bien distribuido en varias particiones.

Cuando una solicitud llega al límite de lo que una partición puede manejar, Azure Storage empezará a devolver códigos de error 503 (Servidor ocupado) o 500 (Timeout). Cuando esto ocurre, la aplicación debe utilizar una política de reintentos o distribuir la carga de mejor manera.

Región de estados unidos

Capacidad total de la cuenta Cantidad de Requests (Asumiendo 1K por objeto) Ancho de Banda para Storage Geo-Redundante Ancho de Banda para Storage Localmente Redundante
500 TB 20.000 entidades o mensajes por segundo Entrada: Hasta 10GB por segundo.

Salida: Hasta 20GB por segundo.

Entrada: Hasta 20GB por segundo.

Salida: Hasta 30GB por segundo.

Europa y Asia

Capacidad total de la cuenta Cantidad de Requests (Asumiendo 1K por objeto) Ancho de Banda para Storage Geo-Redundante Ancho de Banda para Storage Localmente Redundante
500 TB 20.000 entidades o mensajes por segundo Entrada: Hasta 5GB por segundo.

Salida: Hasta 10GB por segundo.

Entrada: Hasta 10GB por segundo.

Salida: Hasta 15GB por segundo.

Rendimiento para una partición de cada servicio de Storage

Un blob: Hasta 60MB o 500 request por segundo.

Una cola (Mensajes de 1K): Hasta 2000 mensajes por segundo.

Una tabla (Entidades de 1K): Hasta 2000 mensajes por segundo.

Cada objeto que se almacena en Azure Storage (Blobs, Mensajes y Entidades) se encuentra en un Partition Key, y se identifica por este mismo. El Partition Key determina cómo Azure Storage balancea la carga entre blobs, mensajes y entidades a través de servidores. El Partition Key es único dentro de la cuenta de almacenamiento y se utiliza para localizar un blob, mensaje, o entidad.

Para las tablas, todas las entidades con el mismo valor de Partition Key se agrupan en la misma partición y se almacenan en el mismo servidor de particiones. Este es un punto importante para el diseño de la aplicación. Su aplicación debe equilibrar la escalabilidad a través de múltiples particiones con las ventajas de agrupar datos en una sola partición. Una ventaja clave de tener entidades en una misma partición es la posibilidad de realizar operaciones atómicas en todas las entidades que pertenecen a dicha partición.

Los Partition Key afectan al balanceo de carga y escalabilidad para cada uno de los servicios.

Blobs: El Partition Key para un blob es nombre del contenedor + nombre blob. Esto significa que cada blob tiene su propia partición. Por lo tanto, los Blobs se puede distribuir a través de muchos servidores con el fin de escalar el acceso. Al mismo tiempo los blobs pueden ser agrupados lógicamente en contenedores (Containers) pero no hay implicaciones de particiones en esta agrupación.

Colas: El Partition Key de un mensaje es el nombre de la cola, por lo que todos los mensajes en una cola se agrupan en una sola partición y son atendidos por un solo servidor. Diferentes colas pueden ser tratadas por diferentes servidores para equilibrar la carga para. El que los mensajes se encuentren todos en un único servidor no implica que el mismo no tenga copias para respaldar los datos.

Tablas: para el caso de las entidades en una tabla existe la propiedad Partition Key que determina la partición donde se encontrará la misma. Distintas entidades dentro de una tabla se pueden encontrar en la misma partición. Una aplicación puede realizar operaciones atómicas sobre las entidades dentro de una misma partición, ya que se encuentran en el mismo servidor. Las entidades que están en la misma tabla, pero que pertenecen a diferentes particiones puede equilibrar la carga entre los distintos servidores, por lo que es posible tener una gran cantidad de entidades con una mayor escalabilidad.