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

Question

Por lo tanto, el escenario es el siguiente:

Tengo varias instancias de un servicio web que escribe un bloque de datos en Azure Storage. Necesito poder agrupar blobs en un contenedor (o directorio virtual) dependiendo de cuándo fue recibido. De vez en cuando (todos los días en el peor), los blobs más antiguos se procesan y luego se eliminan.

que tienen dos opciones:

Opción 1

hago un contenedor llamado "manchas" (por ejemplo) y luego almacenar todos los blogs en ese contenedor. Cada blob usará un nombre de estilo de directorio con el nombre del directorio como 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á hr0min0 blobs primero, luego hr0minX y así sucesivamente (y los blobs aún se escriben cuando se procesan).

Opción 2

Tengo muchos contenedores cada uno con un nombre basado en el tiempo de llegada (por lo que primero será un contenedor llamado blobs_hr0min0 entonces blobs_hr0minX, etc) y todas las manchas en el contenedor son aquellas manchas que llegó 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 da 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?

Answer 1

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

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

(vaya a "particiones").

Citando:

Blobs - Dado que la clave de partición es abajo hasta el nombre de nota, podemos cargar equilibrar el acceso a las diferentes gotas a través de tantos servidores con el fin de escala a cabo el acceso a ellos. Esto permite que los contenedores crezcan tan grandes como como los necesite (dentro del límite de espacio de la cuenta de almacenamiento). La compensación de es que no brindamos la capacidad de realizar transacciones atómicas en múltiples blobs.

Answer 2

En teoría, no debería haber diferencia entre lotes de contenedores o menos contenedores con más burbujas. Los contenedores adicionales pueden ser agradables como límites de seguridad adicionales (para 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 orientar cada blob). Tiendo a usar más contenedores por estas razones (no por rendimiento).

Teóricamente, 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). Esa es la cosa más pequeña que se equilibrará de carga desde un servidor de partición. Por lo tanto, podría (y con frecuencia tendrá) dos blobs diferentes en el mismo contenedor atendidos 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 las discrepancias.

Answer 3

Todo el mundo le ha dado respuestas excelentes para acceder directamente a blobs. Sin embargo, si necesita listar blobs en un contenedor, es probable que vea 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 viendo un golpe de rendimiento, ya que el tiempo para recuperar una lista completa ha estado creciendo.

Esto podría no aplicarse a su situación, pero es algo a tener en cuenta ...

Answer 4

Hay también es un factor más que obtener de en esto. ¡Precio!

Actualmente operación List y el contenedor Crear son por el mismo precio: 0054 US $/10.000 llamadas

mismo precio es en realidad para la escritura de la burbuja.

Así que en la causa extrema que puede pagar mucho más, si se crea y eliminar muchos contenedores

• eliminar es libre

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