¿Es mejor tener muchos contenedores pequeños de blobs de Azure Storage (cada uno con algunos blobs) o un contenedor realmente grande con toneladas de blobs?
Así que 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 más antiguos se procesarán y luego se eliminarán.
Tengo dos opciones:
Opción 1
Hago un contenedor llamado" blobs " (por ejemplo) y luego almaceno todos los blogs en ese contenedor. Cada blob usará un nombre de estilo de directorio con el nombre del directorio siendo la hora en que fue recibido (por ejemplo, "hr0min0/data.bin", " hr0min0 / data2.bin", " hr0min30 / data3.bin", " hr1min45 / data.recipiente", ... , "hr23min0 / dataN.bin", etc - un nuevo directorio cada X minutos). La cosa que procesa estos blobs procesará primero blobs hr0min0, luego hr0minX y así sucesivamente (y los blobs todavía se están escribiendo cuando se procesan).
Opción 2
Tengo muchos contenedores cada uno con un nombre basado en la hora de llegada (así que primero será un contenedor llamado blobs_hr0min0 luego blobs_hr0minX, etc.) y todos los blobs en el contenedor son aquellos blobs que llegaron a la hora nombrada. Lo que procesa estos blogs procesará un contenedor a la vez.
Así que mi pregunta es, ¿qué opción es mejor? La opción 2 me da una mejor paralelización (ya que un contenedor puede estar en diferentes servidores) o la opción 1 es mejor porque muchos contenedores pueden causar otros desconocido problemas?
4 answers
No creo que realmente importe (desde una perspectiva de escalabilidad/paralelización), porque la partición en Win Azure blobs storage se realiza a nivel de blob, no en el contenedor. Las razones para repartir entre diferentes contenedores tienen más que ver con el control de acceso (por ejemplo, SAS) o el tamaño total del almacenamiento.
Vea aquí para 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 se reduce al nombre del blob, podemos cargar equilibrar el acceso a diferentes blobs a través de tantos servidores con el fin de escalen el acceso a ellos. Esto permite que los contenedores crezcan tan grandes a medida que lo necesite (dentro del límite de espacio de la cuenta de almacenamiento). El la compensación es que no proporcionamos la capacidad de hacer transacciones a través de múltiples blobs.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-11-16 22:10:01
Todo el mundo te ha dado excelentes respuestas para acceder directamente a los 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 compañía que ha estado almacenando un gran número de manchas en un solo contenedor. Con frecuencia listan los objetos en el contenedor y luego realizan acciones contra un subconjunto de esos blobs. Están viendo un éxito de rendimiento, ya que el tiempo para recuperar un listado completo ha sido creciente.
Esto podría no aplicarse a su escenario, pero es algo a considerar...
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-11-16 23:40:14
Teóricamente hablando, no debería haber diferencia entre lotes de contenedores o menos contenedores con más blobs. Los contenedores adicionales pueden ser agradables 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 hacer que la limpieza sea un poco más fácil al podar (eliminar un solo contenedor en lugar de apuntar a cada blob). Tiendo a usar más contenedores por estas razones (no por rendimiento).
Teóricamente, el el impacto en el desempeño 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 balanceará de carga desde un servidor de particiones. Por lo tanto, podría (y a menudo 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é podría ser el caso, pero yo sospecharía de otros factores (como el tamaño, la duración de la prueba, etc.) para explicar cualquier discrepancia.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-11-16 22:11:30
También hay un factor más que entra en esto. ¡Price!
Actualmente la lista de operaciones y el contenedor Create tienen el mismo precio: 0,054 US calls / 10.000 llamadas
El mismo precio es en realidad para escribir el blob.
Así que en extreme cause puedes pagar mucho más, si creas y eliminas muchos contenedores
- delete is free
Puedes ver la calculadora aquí: https://azure.microsoft.com/en-us/pricing/calculator /
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-10-13 09:46:16