Diseño de una estrategia de organización de almacenamiento
Al diseñar una aplicación que necesita almacenar datos, es importante pensar en cómo la aplicación va a organizarlos en blobs, contenedores y cuentas de almacenamiento.
Cuentas de almacenamiento
Una sola cuenta de almacenamiento es lo suficientemente flexible como para organizar los blobs. Sin embargo, debe usar más cuentas de almacenamiento conforme sea necesario para separar costes y acceso de control a datos de forma lógica.
Contenedores y blobs
La naturaleza de la aplicación y los datos que almacena deben impulsar la estrategia de nomenclatura y organización de contenedores y blobs.
Las aplicaciones que usan blobs como parte de un esquema de almacenamiento que incluye una base de datos a menudo no necesitan depender en gran medida de la organización, la nomenclatura o los metadatos para indicar algo sobre sus datos. Normalmente, esas aplicaciones utilizan identificadores como GUID como los nombres de blob y hacen referencia a estos identificadores en los registros de la base de datos. La aplicación usa la base de datos para determinar dónde se almacenan los blobs y el tipo de datos que contienen.
Otras aplicaciones usan Azure Blob Storage más como un sistema de archivos personal. Los nombres de contenedor y blob indican el significado y la estructura. Los nombres de blobs de estos tipos de aplicaciones suelen parecerse a los nombres de archivo tradicionales. Pueden incluir extensiones de nombre de archivo como .jpg para indicar qué tipo de datos contienen. Estas aplicaciones usan directorios virtuales para organizar los blobs. Suelen usar etiquetas de metadatos para almacenar información sobre los blobs y contenedores.
Hay algunos conceptos clave que hay que considerar al decidir cómo organizar y almacenar blobs y contenedores.
Limitaciones sobre nomenclatura
Los nombres de contenedores y blobs deben seguir una serie de reglas, como las limitaciones de longitud y las restricciones de caracteres. Para obtener información más específica sobre las reglas de nomenclatura, vea la sección Lecturas adicionales del final de este módulo.
Acceso público y contenedores como límites de seguridad
De forma predeterminada, todos los blobs requieren autenticación para acceder. Sin embargo, pueden configurarse contenedores individuales para permitir la descarga pública de sus blobs sin autenticación. La descarga pública es compatible con muchos de los casos de uso, como el hospedaje de recursos de sitio web estáticos y el uso compartido de archivos. Este enfoque funciona porque la descarga del contenido del blob funciona de la misma manera que la lectura de cualquier otro dato a través de la web. Simplemente apunte un explorador o cualquier cosa que pueda realizar una solicitud GET en la dirección URL del blob.
La habilitación del acceso público es importante para la escalabilidad. Los datos descargados directamente desde Blob Storage no generan tráfico en la aplicación del lado servidor. Planee usar contenedores independientes para los datos que desea que estén disponibles públicamente, aunque no permita inmediatamente el acceso público o use una base de datos para controlar el acceso a los datos.
Precaución
Cualquiera que conozca las direcciones URL de almacenamiento puede descargar los blobs de un contenedor configurado con acceso público, sin ningún tipo de autenticación o auditoría. Nunca coloque datos de blob en un contenedor público si no desea compartirlos públicamente.
Además del acceso público, Azure tiene una característica de firma de acceso compartido que permite el control de permisos más específico en los contenedores. El control de acceso de precisión permite escenarios que mejoran aún más la escalabilidad, por lo que resulta útil pensar en los contenedores como límites de seguridad.
Prefijos de nombres de blob (directorios virtuales)
Los contenedores son planos. No admiten ningún tipo de anidamiento ni jerarquía. Sin embargo, si asigna a los blobs nombres jerárquicos que se parecen a las rutas de acceso a archivos, como finance/budgets/2017/q1.xls, la operación de enumeración de la API puede filtrar los resultados de los prefijos específicos. Este enfoque le permite navegar por la lista como si se tratara de un sistema jerárquico de archivos y carpetas.
Algunas herramientas y bibliotecas cliente usan este enfoque para visualizar y navegar por Blob Storage como si fuera un sistema de archivos. La navegación en cada carpeta desencadena una llamada independiente para enumerar los blobs de dicha carpeta. Esta característica se suele denominar directorios virtuales.
Nota:
Si habilita la característica de espacio de nombres jerárquico de la cuenta, los directorios ya no serán virtuales. En su lugar, se convierten en objetos concretos e independientes en los que puede operar directamente. Un directorio puede existir sin contener ningún archivo. En este módulo solo se describen las cuentas que no tienen habilitada la característica de espacio de nombres jerárquico.
Tipos de blobs
Existen tres tipos diferentes de blobs en los que se pueden almacenar datos:
- Los blobs en bloques están compuestos por bloques de diferentes tamaños que se pueden cargar de forma independiente y en paralelo. La escritura en un blob en bloque conlleva cargar los datos en bloques y confirmarlos en el blob.
- Los blobs anexos son blobs en bloque especializados que solo permiten anexar datos nuevos, no actualizar ni eliminar los datos existentes. Son eficaces para este propósito. Los blobs en anexos son ideales para escenarios como el almacenamiento de registros o la escritura de datos en streaming.
- Los blobs en páginas admiten escenarios que implican lecturas y escrituras de acceso aleatorio. Los blobs en páginas se usan para almacenar los archivos de disco duro virtual (VHD) usados por Azure Virtual Machines. Son excelentes para cualquier escenario que implique acceso aleatorio.
Los blobs en bloques son la mejor opción para la mayoría de los escenarios que no requieren específicamente blobs en anexos o en páginas. Su estructura basada en bloques admite cargas y descargas rápidas y un acceso eficaz a elementos concretos de un blob. La mayoría de las bibliotecas cliente administran y confirman automáticamente los bloques. Algunos también controlan cargas y descargas paralelas para maximizar el rendimiento.