Este artigo foi traduzido por máquina.
.style0 { background-color:#E2F4FD;padding:5px; } .style1 { vertical-align:bottom; } .style2 { vertical-align:top; } .style3 { vertical-align:top; } .style4 { vertical-align:top; } .style5 { vertical-align:top; } .style6 { vertical-align:bottom; } .style7 { vertical-align:top; } .style8 { vertical-align:top; } .style9 { vertical-align:top; } .style10 { vertical-align:top; } .style11 { vertical-align:bottom; } .style12 { vertical-align:top; } .style13 { vertical-align:top; } .style14 { vertical-align:top; } .style15 { vertical-align:top; }
Windows Azure Insider
Dados NoSQL na nuvem com tabelas do Windows Azure
Bruno Terkaly
Ricardo Villalobos
O preço de armazenamento de dados em disco caiu tão dramaticamente parece ficção científica, abrindo as comportas para as empresas a armazenar grandes quantidades de dados.Mas ser capaz de armazenar muitos dados economicamente resolve apenas metade do problema.Os dados tornou-se tão grande e complexo que aplicativos de processamento de dados e ferramentas de gerenciamento de banco de dados tradicional são muito insuficientes.Com tantos dados no disco, novas questões surgiram, como ingerindo os dados, realizando pesquisas, compartilhando os dados, analisando-o e, em última análise, visualizando.
O poder da cloud computing reforçou a preencher esta necessidade.A capacidade de executar soluções de software maciçamente paralelo — executando em dezenas, centenas ou mesmo milhares de servidores — é a bala de prata que permite às organizações lidar com todos os dados armazenados.
Microsoft percebeu esta tendência importante há vários anos.Windows Azure Storage (WAS) foi lançado em novembro de 2008 e melhorou drasticamente a capacidade das empresas para obter o valor de enormes quantidades de dados armazenados.
Nas palavras de Brad Calder, um distinguished engineer na Microsoft e o pastor que orientou a construção do sistema foi, "Windows Azure Storage é um sistema de armazenamento de nuvem que oferece aos clientes a capacidade de armazenar quantidades aparentemente ilimitadas de dados por qualquer período de tempo que é altamente disponível e durável.Ao usar o Windows Azure Storage, você tem acesso aos seus dados de qualquer lugar, a qualquer momento e pague apenas o que você usa e armazenar.
FOI usado dentro Microsoft para aplicações tais como a busca de rede social; vídeo, música e conteúdo do jogo; e gerenciamento de registros médicos.Ele também é usado pelo motor de busca Bing para fornecer conteúdo publicamente pesquisável quase imediato de mensagens do Facebook ou Twitter ou atualizações de status.Com cerca de 350 TB de dados, o escopo dos dados do Facebook e Twitter é notável.Quando esses dados está sendo ingeridos, taxa de transferência de transações atinge picos de cerca de 40.000 operações por segundo e totais entre 2 a 3 bilhões de transações por dia.
Este mês exploraremos uma faceta de WAS-Windows Azure tabelas — tanto como ele funciona e como os desenvolvedores podem obtê-lo a trabalhar rapidamente.
A paisagem
O cientista de dados moderno se depara com muitas opções ao selecionar uma plataforma de dados, cada um com suas próprias forças e fraquezas.Por exemplo, muitos dados grandes soluções baseiam-se no conceito de NoSQL, o que significa que não é usado um modelo de RDBMS (sistema) de gestão de banco de dados relacional — existem sem mesas e sem instruções de SQL.Em vez disso, as estruturas de dados são tipicamente uma enorme coleção de pares chave/valor ou matrizes associativas.As escolhas populares são, hoje, MongoDB, Cassandra, HBase, CouchDB, Neo4j e Windows Azure tabelas.Este artigo irá se concentrar no Windows Azure tabelas.
Apesar das grandes diferenças, bancos de dados SQL e NoSQL têm uma coisa em comum: essas tecnologias são oferecidas como um serviço na nuvem, liberando os desenvolvedores precise de servidores de dados manualmente provisão e de-provision.Por exemplo, o Windows Azure tabelas é oferecida como um serviço e um colaborador nunca tem que pensar em termos de servidores físicos separados.
Na coluna deste mês, vamos começar com uma breve discussão sobre algumas das características e recursos do Windows Azure tabelas.Em seguida, nós forneceremos alguns códigos para demonstrar como você pode trabalhar com Windows Azure tabelas em termos de inserção e consulta de dados.E, finalmente, vou dar uma olhada em alguns dos objetivos do projeto e os detalhes de implementação de alto nível da WAS.
Básico
Uma das grandes características do Windows Azure tabelas é que o armazenamento é oferecido em três regiões geograficamente distribuídas, incluindo os Estados Unidos, Europa e Ásia.Cada datacenter da Microsoft está em conformidade com a organização internacional para padronização (ISO) 27001, Epie 16 ISAE 3402, UE modelo cláusulas e negócios Health Insurance Portability and Accountability Act (HIPAA) associam a padrões de acordo (BAA).Outra característica importante é o armazenamento redundante de geo, o que permite replicar seus dados em outro datacenter dentro da mesma região, adicionando mais um nível de recuperação de desastres.
Capacidades e desempenho WAS correlacionadas com contas de armazenamento.Uma conta de armazenamento individual inclui 200 TB de armazenamento.Windows Azure tabelas foram otimizadas para fornecer um desempenho incrivelmente rápido consulta sob cargas de trabalho pesadas de gravação.Você pode ler mais em bit.ly/cMAWsZ.
Figura 1 mostra os alvos de escalabilidade para uma conta de armazenamento único criado após 7 de junho de 2012.
Figura 1 metas de escalabilidade para uma conta de armazenamento único
FOI analytics também estão disponíveis, permitindo que desenvolvedores rastrear solicitações de armazenamento, analisar as tendências de uso e otimizar padrões de acesso a dados em uma conta de armazenamento.Leia mais em bit.ly/XGLtGt.
Esteja ciente de que o sistema WAS inclui outras abstrações, como blobs e filas.Nós focalizaremos aqui em Windows Azure tabelas, que são usados para armazenar dados não-relacionais estruturados e semi-estruturados.A maneira mais sucinta para expressar o valor do Windows Azure tabelas é que eles oferecem suporte a pesquisas de chave-valor de NoSQL em escala e sob cargas de trabalho pesadas de gravação.Do ponto de vista de um desenvolvedor, Windows Azure tabelas são para o armazenamento de grandes coleções de objetos de não-uniforme ou para servir páginas em um site de alto tráfego.
Windows Azure tabelas pode ser acessadas a partir de quase qualquer lugar.O sistema de armazenamento inteiro está habilitado para REST Representational State Transfer, o que significa que qualquer cliente capaz de HTTP pode se comunicar com o sistema WAS.Clientes óbvios incluem iOS, Android, Windows 8 e diferentes distribuições de Linux.O REST API suporta inserções, upserts, atualizações e exclusões e seleciona ou consultas.
Ao trabalhar com Windows Azure tabelas, uma chave de ponto de partida é entender como controlar o esquema de particionamento de dados.Para qualquer determinada tabela de Windows Azure, o arquiteto de dados deve definir (na frente) um PartitionKey e uma RowKey.Esta é talvez a decisão mais importante que você vai fazer ao usar o Windows Azure tabelas.PartionKeys e RowKeys determinar como seus dados automaticamente são particionados, o serviço de armazenamento e a forma como irão realizar suas consultas.Recomenda-se que você entende como seus dados vão ser consultados antes de finalizar suas decisões PartitionKey e RowKey.Mais tarde, nós vai mergulhar a mecânica de consistência transacional e sua relação com PartitionKeys.Por agora, vamos examinar um exemplo simples de como as partições de sistema WAS tabela dados.
Um rápido Tutorial
Imagine que você deseja armazenar e recuperar e-mails do variUOs domínios, como a seguir: bterkaly@Microsoft.com, ricardo.villalobos@microsoft.com, brunoterkaly@hotmail.com e ricardovillalobos@hotmail.com.Esses endereços de e-mail, nomes de domínio são microsoft.com e hotmail.com, enquanto os nomes de email são bterkaly e ricardo.villalobos.Consultas típicas primeiro Pesquisar por nome de domínio e, em seguida, por nome de email.
Neste exemplo simples, a escolha de PartitionKey e RowKey são bastante simples.Nós vai mapear o nome de domínio para o PartitionKey e o nome de email para o RowKey.
O código em Figura 2 deve tornar as coisas um pouco mais claras.Ele ilustra quatro recursos simples:
- Definir uma entidade (EmailAddressEntity)
- Definindo a tabela que irá armazenar as entidades (E-mailAddressTable)
- Inserir a entidade na tabela (Insira o endereço de emailentidade em EmailAddressTable)
- Consultando a tabela para procurar uma entidade específica (procure por bterkaly@microsoft.com)
Figura 2 a entidade EmailAddressEntity
// Our entity derives from TableEntity public class EmailAddressEntity : TableEntity { // Basic information that makes up our entity public string EMailAddress { get; set; } public string PhoneNumber { get; set; } // A necessary default constructor public EmailAddressEntity() { } // A two-parameter constructor public EmailAddressEntity(string email, string phone) { EMailAddress = email; PhoneNumber = phone; SetKeys(email, phone); } // A method that initializes the partition key and row key public void SetKeys(string email, string phone) { int startIndex = email.IndexOf("@"); // Extract the mailname from the e-mail address string mailname = email.Substring(0, startIndex); // Extract the domain from the e-mail address string domain = email.Substring(startIndex + 1); // Perform the mandatory assignments to the partition key and row key PartitionKey = domain; RowKey = mailname; PhoneNumber = phone; } }
Primeiro, definimos a estrutura de entidade, EmailAddressEntity, conforme Figura 2. Tabela atual (um recipiente para entidades) será definida mais tarde, quando inserimos EmailAddressEntity na tabela. Uma entidade pode ser pensada como um objeto individual; é a menor unidade de dados que podem ser armazenados em uma tabela do Windows Azure. Como mencionado anteriormente, uma entidade é uma coleção de pares de nome-valor digitados, muitas vezes referida como propriedades. Tabelas são coleções de entidades, e cada entidade pertence a uma tabela, tal como uma linha em uma tabela de banco de dados relacional. Mas tabelas no Windows Azure armazenamento de tabela não tem uma esquema fixa. Não há nenhuma exigência de que todas as entidades em uma tabela são estruturalmente idênticos, como é o caso de uma tabela de banco de dados relacional.
Existem quatro principais partes de informações em Figura 2. Os dois primeiros, EMailAddress e PhoneNumber, são simplesmente duas seqüências de caracteres que deseja armazenar. Os outros dois são as propriedades PartitionKey e RowKey, que discutimos anteriormente. Uma terceira Propriedade necessária de todas as entidades é Timestamp, que é usado internamente pelo sistema para facilitar a simultaneidade otimista.
A coluna Timestamp difere as colunas PartitionKey e RowKey porque é preenchido automaticamente pelo sistema WAS. Em contraste, os desenvolvedores devem inserir as propriedades PartitionKey e RowKey.
Para resumir, a importância de PartitionKey e RowKey é principalmente sobre o desempenho da consulta e consistência transacional. Explicámos anteriormente o desempenho da consulta e é largamente dependente da forma que os dados são particionados em nós de armazenamento. Mas PartitionKeys também permitem que você faça alterações para várias entidades, como em parte da mesma operação, permitindo que os desenvolvedores reverter alterações caso qualquer operação única. A exigência é que entidades fazem parte do mesmo grupo de entidade, o que realmente significa que entidades compartilham o mesmo PartitionKey. As transações são suportadas em um único PartitionKey.
O código em Figura 3 ilustra a instanciação de uma entidade do tipo EmailAddressEntity (de Figura 2) e, em seguida, inserir essa entidade no EmailAddressTable. Note que estamos usando o emulador de armazenamento local. Isso nos permite executar e testar o nosso código e dados localmente sem uma conexão com um data center.
Figura 3 inserindo um EmailAddressEntity
try { // Use the local storage emulator var storageAccount = CloudStorageAccount.DevelopmentStorageAccount; // Create a cloud table client object CloudTableClient tableClient = storageAccount.CreateCloudTableClient(); // Create an e-mail address table object CloudTable emailAddressTable = tableClient.GetTableReference("EmailAddressTable"); // Create the table if it does not exist // Only insert a new record once for this demo if (emailAddressTable.CreateIfNotExists() == true) { // Create a new EmailAddressEntity entity EmailAddressEntity emailaddress = new EmailAddressEntity("bterkaly@microsoft.com", "555-555-5555"); // Create an operation to add the new e-mail and phone number to // the emailAddressTable TableOperation insertEmail = TableOperation.Insert(emailaddress); // Submit the operation to the table service emailAddressTable.Execute(insertEmail); } } catch (Exception ex) { // Put the message in the Web page title (for testing purposes) // Real error messages should go to a proper log file this.Title = ex.Message.ToString(); throw; }
Você pode exibir seus dados no painel Gerenciador de servidores no Visual Studio 2012, conforme mostrado no Figura 4, que torna o processo de escrita e teste o código muito mais fácil. Você também pode anexar Gerenciador de servidor para uma instância real do seu Windows Azure tabelas em um datacenter.
.png)
Figura 4 Server Explorer
O código em Figura 5 ilustra como consultar os dados.
Figura 5 consultar Windows azuis tabelas
// Use the local storage emulator var storageAccount = CloudStorageAccount.DevelopmentStorageAccount; try { // Create the table client CloudTableClient tableClient = storageAccount.CreateCloudTableClient(); CloudTable emailAddressTable = tableClient.GetTableReference("EmailAddressTable"); // Retrieve the entity with partition key of "microsoft.com" // and row key of "bterkaly" TableOperation retrieveBrunoEmail = TableOperation.Retrieve<EmailAddressEntity>( "microsoft.com", "bterkaly"); // Retrieve entity EmailAddressEntity specificEntity = (EmailAddressEntity)emailAddressTable.Execute(retrieveBrunoEmail).Result; TableResult result = emailAddressTable.Execute(TableOperation.Retrieve<EmailAddressEntity>( "microsoft.com", "bterkaly")); // Pull the data out that you searched for // Do something with emailAddress and phoneNumber string emailAddress = specificEntity.EMailAddress; string phoneNumber = specificEntity.PhoneNumber; } catch (Exception ex) { // Put the message in the Web page title (for testing purposes) // Real error messages should go to a proper log file this.Title = ex.Message.ToString(); throw; }
O código executa uma consulta simples usando PartitionKey e RowKey. Observe que você pode construir consultas bastante complexas usando estes filtros, porque você pode juntá-las de forma ad hoc. Devemos construir um objeto de consulta usando o filtro combinado. A etapa final é simplesmente executar a consulta e fazer tudo o que for necessário com o EmailAddressEntity. O WAS biblioteca cliente simplifica as operações de Create/Read/Update/Delete (CRUD), bem como as consultas necessárias.
O que está dentro
Pensamos que pode ser útil olhar um pouco mais profundo a arquitetura interna do sistema WAS, mostrado em Figura 6. Grande parte da narrativa seguinte baseia-se no papel de Brad Calder referenciado neste artigo.
.png)
Figura 6 Windows Azure Storage Internals
FOI é composta por uma série de selos de armazenamento por seus oito datacenters. Um selo de armazenamento é um aglomerado de cerca de 10 a 20 cremalheiras de nós de armazenamento. Cada rack situa-se em um domínio separado da culpa. Cada rack vem com poder e redes redundantes. Cada selo de armazenamento contém aproximadamente 30PBs de armazenamento de cru.
Para manter os custos baixos, é importante manter esses selos de armazenamento em execução acima de 70% de utilização, que é medido em termos de capacidade, transações e largura de banda. Ir acima de 90 por cento é considerado muito alto, porém, deixa pouco espaço em caso de falhas de cremalheira, quando o sistema precisa de fazer mais com menos.
Serviço de localização de armazenamento
O desenvolvedor não tem nenhum controle direto sobre o serviço de localização de armazenamento (SLS). A nível de conta, não só faz o SLS mapa namespaces conta com todos os selos, é também responsável pela recuperação de desastres, alocação de conta de armazenamento e balanceamento de carga. O SLS simplifica bastante a capacidade de adicionar novo armazenamento em um datacenter. Ele pode alocar novas contas de armazenamento para os novos selos para clientes como também carregar saldo contas de armazenamento existentes de selos antigos para os novos selos. Todas essas operações, o SLS são feitas automaticamente.
Vamos olhar um pouco mais de três camadas que compõem um carimbo de armazenamento — fluxo, partição e front end (FE) — a partir do fundo.
A camada de fluxo fornece uma interface interna que a camada de partição usa para ler e gravar arquivos grandes e é responsável pela funcionalidade de replicação do núcleo. A camada de fluxo também manipula abrindo, fechando, excluir, renomear, lendo, acrescentando e concatenar esses arquivos grandes. Ele não preocupa-se com a semântica de objetos que estão no fluxo de dados.
A camada de partição fornece o modelo de dados para os diferentes tipos de objetos armazenados (tabelas, blobs, filas); a lógica e semântica para processar diferentes tipos de objetos; um namespace massivamente escalável para objetos; balanceamento para objetos de acesso entre os servidores de partição disponível; pedido de transação e consistência forte para acesso aos objetos; e a geo-replicação de objetos de dados do primário à região secundária.
A camada de partição também engloba uma estrutura de dados interno importante chamada um objeto de tabela. Existem várias versões da tabela de objeto, incluindo a tabela de entidade, que armazena todas as linhas da entidade para todas as contas no carimbo. Ele é usado para expor publicamente a abstração de dados de tabela do Windows Azure. A tabela de objetos também interage com a camada de partição para garantir a consistência dos dados por encomendas transações com blobs, contos e filas.
A camada de FE é composta por um conjunto de servidores sem monitoração de estado que levam as solicitações de entrada. Ao receber uma solicitação, um FE procura o AccountName, autentica e autoriza a solicitação e encaminha a solicitação para o servidor apropriado partição na partição camada (baseado na PartitionName). Para melhorar o desempenho, a FE mantém e armazena em cache um mapa de partição, para que o roteamento para o servidor apropriado partição é acelerado em dados acessados com freqüência.
Conclusão
Neste artigo, fornecemos algumas orientações de alto nível, acionáveis, bem como alguns dos detalhes arquitectónicos sobre como o sistema foi foi projetado, e em particular como Windows Azure tabelas pode ajudar você gerenciar os dados. Gostaríamos de agradecer a Brad Calder para algumas de suas idéias compartilhadas em "Windows Azure Storage: Um altamente disponível Cloud Storage Service com Strong consistência,"um livro recentemente publicado a 23 Simpósio ACM sobre princípios de sistemas operacionais (SOSP). Você pode baixar o seu papel no bit.ly/tMIPus.
Biblioteca de cliente do Windows Azure Storage 2.0
No final de outubro de 2012, a Microsoft lançou uma nova biblioteca de cliente de armazenamento — biblioteca de cliente do Windows Azure Storage (WAS) 2.0 — que dramaticamente melhora a usabilidade, desempenho e extensibilidade ao interagir com o Windows Azure tabelas. Você pode instalar o WAS cliente biblioteca 2.0 com NuGet de bit.ly/YFeHuw. Isso pode ser feito dentro do Visual Studio 2012. Para um olhar detalhado em algumas das grandes novidades, visite bit.ly/VQSaUv.
A nova biblioteca inclui algumas novas abordagens que melhoram a funcionalidade em relação à usabilidade, desempenho e extensibilidade. Um recurso interessante você evita o incômodo de se preocupar com lógica de serialização e desserialização quando trabalhando com Plain Old c# objetos (POCO). Outro recurso interessante é o EntityResolver, que lhe permite realizar projeções do lado do cliente, assim você pode criar objetos dinamicamente com base em apenas as informações que você está interessado em. Em suma, você pode converter diretamente a partir de dados de entidade da tabela para um tipo de objeto de cliente sem um tipo de classe de entidade tabela separada que desserializa individualmente a cada propriedade. Outra tecnologia poderosa é a interface IQueryable, que lhe dá uma forma expressiva para definir consultas LINQ complexas.
Bruno Terkaly is a developer evangelist for Microsoft. Seu profundo conhecimento é fruto de anos de experiência no campo, escrevendo código com uma grande quantidade de plataformas, linguagens, estruturas, SDKs, bibliotecas e APIs. Ele gasta tempo escrevendo código, blogar e fazer apresentações ao vivo na construção de aplicativos baseados em nuvem, especificamente usando a plataforma Windows Azure. Terkaly é também o autor de dois apps Windows Store, ensinar crianças carro cores e ensinar música de crianças. Você pode ler seu blog em blogs.msdn.com/brunoterkaly.
Ricardo Villalobos is a seasoned software architect with more than 15 years of experience designing and creating applications for companies in the supply chain management industry. Detentor de diferentes certificações técnicas, e mestre em administração pela Universidade de Dallas, ele trabalha como arquiteto de nuvem no grupo de incubação do Windows Azure CSV para a Microsoft.
Terkaly e Villalobos conjuntamente apresentar conferências da indústria em geral. Eles encorajam os leitores a contatá-los para disponibilidade. Terkaly pode ser contatado em bterkaly@microsoft.com e Villalobos pode ser contatado em Ricardo.Villalobos@microsoft.com.
Agradecemos aos seguintes especialistas técnicos pela revisão deste artigo: Brad Calder (Microsoft) e Jai Haridas (Microsoft)