/Infra

voltar
/Infra

Utilizando Tables no Microsoft Azure Storage

PorAlex Tochetto em

O Microsoft Azure Storage é uma solução para aplicações modernas que são pensadas por sua durabilidade, performance e escalabilidade no armazenamento das informações.

O Storage permite o armazenamento massivo de informações. Além disso, dependendo da quantidade de acessos (aumento de usuários) da sua aplicação, você pode escalar o serviço para um nível maior de performance e armazenamento.

Tables

O Storage permite a utilização de quatro serviços: Blob Storage, Table Storage, Queue Storage e File Storage. Neste artigo, falaremos sobre o Table Storage.

O Table Storage é uma estrutura como a de um DataSet, porém configurada como NoSQL, que naturalmente possui uma chave que permite o rápido desenvolvimento e acesso a uma quantidade considerável de informação.

Armazenamento

Existem 5 tipos de armazenamento e eles variam a forma como as informações são armazenadas e copiadas. O mais simples e acessível é o LRS (Armazenamento com Redundância Local), significa que serão feitas cópias dos dados dentro de um único datacenter.

  • ZRS (Armazenamento com Redundância de Zona): Realiza 3 cópias dos dados em datacenters distintos, considerando apenas os Blobs;
  • GRS (Armazenamento com Redundância Geográfica): Funciona como o LRS, porém são milhares de cópias em datacenters distantes fisicamente;
  • RA-GRS (Armazenamento com Redundância Geográfica no Acesso de Leitura): Mesmo funcionamento do GRS, porém permite a leitura como se fosse um load balance.

Preços/Custos

Falando especificamente das Tables os preços (simulador) são bem atrativos. A cobrança é feita em várias faixas de transferência de informação a cada 100.000 transações.

Configuração

Dentro do Microsoft Azure eu particularmente prefiro separar o Storage em um Resorce Group específico para ele, com um nome fácil de ser lembrado como “Default-Storage-EastUS2”. O “East US 2” é a região de armazenamento das informações.

Acesso

Após criado o Storage, através das configurações teremos acesso às “Access Keys”, as chaves de acesso, são duas, a “Key1” e a “Key2”. Para matar a curiosidade, geralmente utilizamos a Key1 para nosso trabalho diário. Se por ventura você instalar algo em algum cliente que envie informações ao Storage, minha sugestão é utilizar a Key2, assim caso ocorra algum problema você pode substituir a atual por uma nova sem afetar as aplicações que eventualmente utilizam a Key1. Mas é apenas uma sugestão de uso. A imagem a seguir demonstra onde estão as chaves de acesso.

01

NuGet

Configure o seu projeto e adicione a referência do “WindowsAzure.Storage” via NuGet conforme demonstrado na imagem a seguir.

02

Conexão

<connectionStrings>  
    <add name="StorageConnectionString" connectionString="DefaultEndpointsProtocol=https;AccountName=storage;AccountKey=L43uEWSiVqfKiCs9aVOOyfCwdHmWkGxNDbOVn1qAvNoea"/>
</connectionStrings>

Quando vimos sobre as chaves de acesso, ao clicar ao lado de uma das chaves (no …) ele já monta a string de conexão completa para uso.
Eu gosto de utilizá-la como uma connection string, pois, se você quiser executar o comando de criptografia RSA do .net framework vai estar seguro (papo para outro momento).

Codificação

Crie uma aplicação qualquer, neste exemplo estou utilizando Windows Forms, o que for mais apropriado para seu caso, visto que a maneira de uso não muda. Utilize os using’s a seguir.

using System.Configuration;  
using Microsoft.WindowsAzure.Storage;  
using Microsoft.WindowsAzure.Storage.Table;

Crie uma classe para podermos ter um objeto que fará o papel de uma entidade.

O mais importante aqui é que esta classe herde de “TableEntity”.

No construtor da classe foram inicializados as propriedades “PartitionKey” e “RowKey”, vamos à definição de cada uma delas.

A PartitionKey é a definição utilizada para separar os dados como se fosse uma pasta. Dentro desta “pasta” existem diversos registros sendo que cada um deles é identificado através do RowKey.

public class Cliente : TableEntity  
{
    public Cliente()
    {
        this.PartitionKey = nameof(Cliente);
        this.RowKey = Guid.NewGuid().ToString();
    }
    public string Email { get; set; }
    public string Telefone { get; set; }
    public int Ler { get; set; } = 0;
}

O trecho de código a seguir vai criar uma table (tabela) chamada “Clientes” dentro do storage. Nesta tabela estão as “pastas” (PartitionKey) com seus respectivos registros (RowKey) que vimos anteriormente.

var storageAccount = CloudStorageAccount.Parse(ConfigurationManager.ConnectionStrings["StorageConnectionString"].ConnectionString);  
var tableClient = storageAccount.CreateCloudTableClient();  
var table = tableClient.GetTableReference("Clientes");  
table.CreateIfNotExists();

O código a seguir vai preencher os valores da entidade e persistir os dados dentro do storage.

var cliente = new Cliente  
{
    Email = "cliente@cliente.com.br",
    Telefone = "44888110000"
};
var insertOperation = TableOperation.Insert(cliente);  
table.Execute(insertOperation);

Processamento em batch

O Microsoft Azure Storage possui uma característica bem particular no processamento das informações dentro das tables. Você pode enviar uma lista com 99 objetos de uma única vez que ele considerará apenas uma única transação.

    Email = "cliente1@cliente.com.br",
    Telefone = "44888110001"
};
var cliente2 = new Cliente  
{
    Email = "cliente2@cliente.com.br",
    Telefone = "44888110002"
};

var batchOperation = new TableBatchOperation();  
batchOperation.Insert(cliente1);  
batchOperation.Insert(cliente2);

table.ExecuteBatch(batchOperation);

Para facilitar todo o trabalho eu prefiro visualizar as informações através do Microsoft Azure Storage Explorer conforme a imagem a seguir.

03

Monitoramento

Por fim dentro da visão geral do storage dentro do Microsoft Azure é possível monitorar o tráfego e a quantidade de informação que está armazenada. A imagem a seguir demonstra como esta informação é exibida ao usuário.
04

Conclusão

Para concluir eu gostaria de contribuir com algumas percepções de uso baseado em experiências do meu dia-a-dia como profissional.

Caso me perguntem sobre uma aplicação real eu recomendaria o uso para o armazenamento de informações relacionadas a log ou auditoria, como queiram chamar. Já trabalhei com sistemas em que eram armazenadas informações de execuções de queries (querys), auditoria de ações executadas por usuários, log de integração, etc dentro do banco de dados ou até mesmo em arquivos. Para esses casos minha sugestão é a utilização do storage.

Inicialmente não tiraríamos proveito da performance que fica aquém do banco de dados, mas com o aumento das informações armazenadas é notório a diferença de performance, consequentemente haveria uma diminuição drástica no número de transações, log e tamanho do banco de dados.

Outra recomendação de utilização é na troca de informações entre sistemas (integração), não havendo necessidade de exposição do banco de dados de nenhum dos aplicativos envolvidos. Por fim, ainda poderíamos utilizar as tables para armazenar informações de pesquisa com indexação, ainda não explorei muito esse assunto, mas um bom começo para ter uma idéia da ferramenta é dar uma olhada no Search Service do Microsoft Azure.

Dicas

  • O Storage Tables ignora o tipo primitivo “decimal”, sendo assim, utilize “double”;
  • Não utilize lista dentro do objeto, ele só aceita tipos primitivos. Não vai gerar nenhum erro, mas ele não vai persistir os dados;
  • Um bom link para começar a ver a dinâmica de funcionamento em uma sequência entendível é do próprio Microsoft Azure;
  • Utilize o Microsoft Azure Storage Explorer para facilitar a visualização dos dados. Ele é simples e fácil de usar;
  • Veja também um post bem completo sobre o Microsoft Azure Storage.
  • Trabalhando com 154 milhões de registros no Microsoft Azure Storage Explorer

Deixe um comentário! 0

0 comentário

Comentários

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Comentando como Anônimo

leia mais
Este projeto é mantido e patrocinado pelas empresas: