Clique aqui para ler essa revista em PDF.
Trabalhando com Azure Blobs
Começamos duas edições atrás a conhecer o Windows Azure. Já vimos o Azure hosting e começamos a tratar do Azure Storage na edição passada, onde examinamos o Azure Tables com mais detalhes. Nesta edição vamos conhecer o Azure Blobs.
O Azure Blobs, parte do Azure Storage, é a tecnologia utilizada para armazenar dados binários na nuvem. Com ele você pode armazenar qualquer arquivo, acompanhado de informações sobre estes dados (metadados), nos servidores da Microsoft na nuvem. Você pode ainda controlar todo o acesso, dando permissões de acesso, ou deixando-os públicos. O acesso aos dados, assim como todo o contato com o Azure Storage, é baseado em REST, e no .Net é feito com ajuda do ADO.Net Data Services (antigo Astoria).
Conceitos básicos do Azure Storage
O Azure Storage permite armazenar até 50 gigabytes de informações por blob. Caso o blob ultrapasse 64 megabytes ele deve ser enviado em blocos, que são pedaços menores do dado, e depois outro comando é utilizado para informar com que blocos devem ser utilizados para compor o blob, e em que ordem. A divisão do blob em blocos é útil especialmente em casos de quebra de conexão. Um upload de 1 gigabyte pode demorar alguns minutos para completar, e, caso quebre nos segundos finais do upload todos os dados enviados seriam perdidos. Com o envio em blocos apenas os dados daquele bloco são perdidos e devem ser reenviados em caso de quebra de conexão.
Blobs são armazenados de maneira estruturada. Uma conta do Azure Storage tem acesso a contêineres de blobs. Um blob sempre estará dentro de um contêiner. Pense que um contêiner é como uma pasta, onde você coloca seus blobs. É nos contêineres que você determina os níveis de acesso de um blob (público – sem autenticação e autorização, ou privado), e não nos blobs, individualmente.
Você pode ainda associar metadados aos contêineres. Estes metadados podem ter até 8 kilobytes de informações. Metadados são sempre associados em forma de chave/valor, tanto para os contêineres, quanto para os blobs.
A hierarquia de armazenamento determina não só o acesso, mas também a url em que o blob será disponibilizado. A Figura 1 mostra como essa url é determinada, utilizando a hierarquia conta/contêiner/blob para formação do nome. Note que o domínio utilizado é sempre “.blob.core.windows.net”, seguido pelo nome do contêiner, e então pelo nome do blob.
Figura 1. Estrutura de armazenamento de blobs
A Figura 2 mostra um exemplo aplicado a esta estrutura. Neste caso, a conta “giggio” possui dois contêineres, “musicas” e “filmes”. E o contêiner “musicas” possui os blobs “one.mp3” e “battery.mp3”, e o contêiner “filmes” possui somente o blob “snatch.avi”. O acesso ao blob de nome “one.mp3”, caso o contêiner “musicas” fosse público, seria feito com um simples GET, que poderia ser colocado em um link simples, da seguinte forma:
http://giggio.blob.core.windows.net/musicas/one.mp3
Se o contêiner fosse privado, você precisaria se autenticar para acessar o blob, neste caso, ainda que fosse um GET, algumas informações de autenticação teriam que ser passados ao Azure, na forma de headers do request HTTP.
Figura 2. Estrutura de armazenamento de blobs aplicada a um exemplo prático
Envio em blocos
Como mencionado antes, se um blob é maior que 64 megabytes, ele deve ser enviado em blocos. Veja na Figura 3 como isso aconteceria em um exemplo aplicado. Foram enviados ao servidor do Azure Blobs 5 blocos, identificados como “Bloco 1”, “Bloco 2”, “Bloco 3”, “Bloco 4” e “Bloco 2”. Os blocos foram enviados nesta ordem. Note que o bloco identificado como “Bloco 2” foi enviado duas vezes, e o segundo envio do “Bloco 2” foi feito após o “Bloco 4”. Ao final, um comando é enviado ao Azure Blobs, informando-o como compor o blob, utilizando os blocos. Neste caso, o comando avisa para utilizar os blocos 1, 2 e 4, nesta ordem. E esse é o resultado final do blob, que será acessível ao usuário. O “Bloco 3” foi ignorado, apesar de ter sido enviado ao servidor do Azure. O primeiro envio do “Bloco 2” também foi ignorado, porque este bloco foi enviado duas vezes, e somente o último envio é válido.
...
