Azure Blob Storage es un servicio de almacenamiento de objetos que puede almacenar cualquier forma de datos no estructurados: imagenes, videos, documentos, archivos de registro y mas. Para el examen AZ-204, los temas clave son el uso del SDK, distinguir propiedades vs metadatos, niveles de almacenamiento, politicas de ciclo de vida y politicas de inmutabilidad.
SDK: Tres Clases de Cliente
Para entender el SDK de Blob Storage, lo mas importante es distinguir los roles de tres clases de cliente. Piense en un complejo de apartamentos como ejemplo. Es como la relacion entre la oficina de administracion que gestiona todo el complejo (BlobServiceClient), cada edificio (BlobContainerClient) y cada unidad individual (BlobClient).
| Clase | Rol | Analogia | |-------|-----|---------| | BlobServiceClient | Se conecta a toda la cuenta de almacenamiento | Oficina de administracion del apartamento | | BlobContainerClient | Accede a un contenedor especifico (carpeta) | Gestion de un edificio especifico | | BlobClient | Manipula un archivo blob especifico | Una unidad especifica |
Cada cliente puede obtenerse de su cliente padre o crearse directamente con una URL.
Patrones de Operaciones Principales
Cargar: blob_client.upload_blob(data, overwrite=True) Descargar: blob_client.download_blob().readall() Eliminar: blob_client.delete_blob() Crear contenedor: container_client.create_container() Listar blobs: container_client.list_blobs()
Si no especifica overwrite=True al cargar, ocurre una excepcion al intentar cargar a un blob existente.
Propiedades y Metadatos: Almacenar Informacion Sobre Archivos
Mas alla del archivo blob en si, puede almacenar informacion sobre el archivo de dos maneras. Piense en un libro como ejemplo. Las propiedades del libro (grosor, numero de paginas, color de la portada — caracteristicas fisicas) son diferentes en naturaleza de las etiquetas que pone la biblioteca (numero de llamada, ubicacion en estanteria, disponibilidad).
Propiedades del Sistema
Propiedades administradas automaticamente por Azure, directamente vinculadas a encabezados HTTP.
Content-Type: Formato de archivo (p. ej., image/jpeg, application/pdf) Content-Length: Tamano del archivo en bytes ETag: Identificador de version (usado para control de concurrencia optimista) Last-Modified: Hora de ultima modificacion Content-Encoding, Content-Language, etc.
Estas propiedades se pueden recuperar a traves del SDK o la API REST, y algunas se pueden modificar.
Metadatos Definidos por el Usuario
Pares clave-valor que los desarrolladores definen arbitrariamente. Se administran por separado, no se almacenan directamente en el blob.
Formato: pares clave=valor (p. ej., author=Juan, project=alpha, environment=production) Debe seguir las reglas de nomenclatura de encabezados HTTP (solo letras, numeros, guiones) Recuperar: blob_client.get_blob_properties().metadata Establecer: blob_client.set_blob_metadata({"author": "Juan"})
Las preguntas del examen frecuentemente evaluan si puede distinguir las propiedades del sistema de los metadatos definidos por el usuario.
Niveles de Almacenamiento: Optimizacion de Costos Segun la Frecuencia de Acceso
El nivel de almacenamiento apropiado depende de la frecuencia con que necesita acceder a los datos. Piense en un refrigerador y un cuarto de almacenamiento como ejemplo. Los alimentos que come con frecuencia van en el refrigerador (Hot), los articulos de uso ocasional en el cuarto de almacenamiento (Cool), los raramente usados en un almacenamiento mas profundo (Cold), o almacenamiento a largo plazo (Archive).
| Nivel | Caracteristicas | Duracion Minima de Almacenamiento | Costo de Acceso | Costo de Almacenamiento | |-------|----------------|----------------------------------|-----------------|------------------------| | Hot | Datos de acceso frecuente | Ninguna | Bajo | Mas alto | | Cool | Datos de acceso ocasional | 30 dias | Medio | Medio | | Cold | Datos de acceso poco frecuente | 90 dias | Alto | Bajo | | Archive | Datos de acceso casi nulo | 180 dias | Mas alto | Mas bajo |
Debe recordar las caracteristicas especiales del nivel Archive.
Estado sin conexion: Los blobs en Archive no se pueden leer directamente Rehidratacion: Para leer datos, debe moverlos al nivel Hot o Cool, lo que lleva tiempo Prioridad de rehidratacion: Estandar (varias horas hasta 15 horas), Alta (menos de 1 hora, costo adicional)
Si cambia de nivel o elimina antes de la duracion minima de almacenamiento, se aplican cargos por eliminacion anticipada.
Administracion del Ciclo de Vida
Puede establecer politicas para cambiar automaticamente el nivel de un blob o eliminarlo con el tiempo. Como la politica de retencion de documentos de una empresa: reglas como "archivos de mas de 3 meses se mueven al almacenamiento, archivos de mas de 1 ano se destruyen" se ejecutan automaticamente.
Las politicas de ciclo de vida se definen en formato JSON.
Componentes de la regla: Filtros (seleccionar blobs objetivo) + Acciones (que hacer) Condiciones de filtro: Prefijo del nombre del blob, tipo de blob, fecha de ultima modificacion, etc. Acciones admitidas: tierToCool, tierToCold, tierToArchive, delete Frecuencia de ejecucion: Se ejecuta una vez al dia
Por ejemplo, puede establecer una unica politica: "blobs no modificados por 30+ dias se mueven a Cool, 90+ dias a Archive, 365+ dias se eliminan."
Politica de Inmutabilidad: Prevenir Cambios en los Datos
Una funcion que protege los datos blob de ser modificados o eliminados por requisitos regulatorios u obligaciones legales. Como guardar un contrato notariado en una caja fuerte. Incluso con permisos, no puede cambiarse durante el periodo de retencion.
Politica de Retencion Basada en Tiempo
Los blobs no pueden modificarse ni eliminarse durante un periodo especificado.
Periodo de retencion: 1 dia a 146,000 dias (400 anos) Antes de bloquear: La politica puede modificarse o eliminarse Despues de bloquear (Bloqueado): El periodo de retencion no puede acortarse, la politica no puede eliminarse (solo se permite la extension) Casos de uso: Registros financieros, datos medicos, retencion de documentos legales
Legal Hold
Protege los blobs indefinidamente durante disputas legales o investigaciones para preservar evidencia.
Activado/desactivado mediante etiquetas Mientras Legal Hold esta activo, los blobs no pueden modificarse ni eliminarse Se pueden aplicar multiples etiquetas simultaneamente
| Tipo de Politica | Duracion | Bloqueo | Caso de Uso | |-----------------|---------|---------|-------------| | Retencion Basada en Tiempo | Periodo especificado | Bloqueable | Cumplimiento, retencion legal | | Legal Hold | Indefinida | Liberado mediante etiqueta | Disputas legales, investigaciones |
!Retención basada en tiempo vs Legal Hold
Puntos clave del examen
"Conectar a toda la cuenta de almacenamiento" -- BlobServiceClient
"Acceder a contenedor especifico" -- BlobContainerClient
"Manipular archivo especifico (cargar/descargar/eliminar)" -- BlobClient
"Informacion de archivo administrada mediante encabezados HTTP" -- Propiedades del sistema (Content-Type, ETag, etc.)
"Pares clave-valor definidos por desarrolladores" -- Metadatos definidos por el usuario
"Para leer datos de Archive" -- Rehidratacion requerida (mover a Hot/Cool)
"Almacenamiento minimo: Hot=ninguno, Cool=30 dias, Cold=90 dias, Archive=180 dias"
"Transiciones de nivel automaticas/eliminacion mediante politica JSON" -- Administracion del ciclo de vida
"Bloquear modificacion/eliminacion durante periodo especificado" -- Politica de retencion basada en tiempo
"Bloquear modificacion/eliminacion indefinidamente, liberado mediante etiqueta" -- Legal Hold