¿Es mejor tener muchos contenedores de blobs de almacenamiento de Azure pequeños (cada uno con algunos blobs) o un contenedor realmente grande con toneladas de blobs?

Entonces el escenario es el siguiente:

Tengo varias instancias de un servicio web que escribe un blob de datos en Azure Storage. Necesito poder agrupar blobs en un contenedor (o un directorio virtual) dependiendo de cuándo se recibió. De vez en cuando (todos los días en el peor de los casos), los blobs antiguos se procesarán y luego se eliminarán.

Tengo dos opciones:

Opción 1

Hago un contenedor llamado "blobs" (por ejemplo) y luego guardo todos los blogs en ese contenedor. Cada blob utilizará un nombre de estilo de directorio y el nombre del directorio será la hora en que se recibió (por ejemplo, "hr0min0 / data.bin", "hr0min0 / data2.bin", "hr0min30 / data3.bin", "hr1min45 / data.bin ", ...," hr23min0 / dataN.bin ", etc - un nuevo directorio cada X minutos). Lo que procesa estos blobs procesará primero los blobs hr0min0, luego hr0minX y así sucesivamente (y los blobs todavía se están escribiendo durante el procesamiento).

opcion 2

Tengo muchos contenedores, cada uno con un nombre basado en la hora de llegada (por lo que primero será un contenedor llamado blobs_hr0min0, luego blobs_hr0minX, etc.) y todos los blobs en el contenedor son esos blobs que llegaron a la hora indicada. Lo que procesa estos blogs procesará un contenedor a la vez.

Entonces mi pregunta es, ¿qué opción es mejor? ¿La opción 2 me brinda una mejor paralelización (ya que los contenedores pueden estar en servidores diferentes) o es mejor la opción 1 porque muchos contenedores pueden causar otros problemas desconocidos?

No creo que realmente importe (desde una perspectiva de escalabilidad / paralelización), porque la partición en el almacenamiento de blobs de Win Azure se realiza en el nivel de blobs, no en el contenedor. Las razones para distribuirse en diferentes contenedores tienen más que ver con el control de acceso (por ejemplo, SAS) o el tamaño total del almacenamiento.

Consulte aquí para obtener más detalles: http://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-azure-storage-abstractions-and-their-scalability-targets.aspx

(Desplácese hacia abajo hasta "Particiones").

Citando:

Blobs: dado que la clave de partición depende del nombre del blob, podemos equilibrar la carga del acceso a diferentes blobs en tantos servidores para escalar el acceso a ellos. Esto permite que los contenedores crezcan tanto como los necesite (dentro del límite de espacio de la cuenta de almacenamiento). La desventaja es que no brindamos la capacidad de realizar transacciones atómicas en múltiples blobs.

Todo el mundo le ha dado excelentes respuestas sobre cómo acceder a blobs directamente. Sin embargo, si necesita enumerar blobs en un contenedor, probablemente verá un mejor rendimiento con el modelo de muchos contenedores. Acabo de hablar con una empresa que ha estado almacenando una gran cantidad de blobs en un solo contenedor. Con frecuencia, enumeran los objetos en el contenedor y luego realizan acciones contra un subconjunto de esos blobs. Están experimentando un impacto en el rendimiento, ya que ha aumentado el tiempo para recuperar una lista completa.

Es posible que esto no se aplique a su escenario, pero es algo a considerar ...

En teoría, no debería haber diferencia entre muchos contenedores o menos contenedores con más manchas. Los contenedores adicionales pueden ser útiles como límites de seguridad adicionales (para el acceso público anónimo o diferentes firmas SAS, por ejemplo). Los contenedores adicionales también pueden facilitar un poco la limpieza al podar (eliminar un solo contenedor en lugar de apuntar a cada gota). Tiendo a usar más contenedores por estas razones (no por rendimiento).

En teoría, el impacto en el rendimiento no debería existir. El blob en sí (URL completa) es la clave de partición en Windows Azure (lo ha sido durante mucho tiempo). Eso es lo más pequeño que se equilibrará la carga de un servidor de particiones. Por lo tanto, podría (y con frecuencia lo hará) tener dos blobs diferentes en el mismo contenedor que son servidos por diferentes servidores.

Jeremy indica que hay una diferencia de rendimiento entre más y menos contenedores. No he profundizado en esos puntos de referencia lo suficiente como para explicar por qué ese podría ser el caso, pero sospecho que otros factores (como el tamaño, la duración de la prueba, etc.) explican cualquier discrepancia.

También hay un factor más que influye en esto. ¡Precio!

Actualmente la operación List y Create container tienen el mismo precio: 0,054 US $ / 10.000 llamadas

El mismo precio es en realidad por escribir el blob.

Entonces, en casos extremos, puede pagar mucho más si crea y elimina muchos contenedores

• eliminar es gratis

puedes ver la calculadora aquí: https://azure.microsoft.com/en-us/pricing/calculator/