Este artigo foi traduzido por máquina.

Pontos de dados

Armazenamento de tabela Azure Windows – não banco de dados do seu pai.

Julie Lerman

Baixe o código de exemplo

Armazenamento de tabela de Azure Windows causa muito de um cabeçalho de uma pequena entre os desenvolvedores. A maioria das suas experiências com o armazenamento de dados é com bancos de dados relacionais com várias tabelas, cada uma contendo um conjunto predefinido de colunas, um ou mais do que normalmente são designados como chaves de identidade. Tabelas usam essas chaves para definir relações entre um another.Windows Azure armazena informações de várias maneiras, mas as duas que enfocam a persistência de dados estruturados são SQL Azure e o Windows Azure tabela de armazenamento. A primeira é um banco de dados relacional e alinha bem em conjunto com o SQL Server. Ele possui tabelas com definidas de esquemas, chaves, relacionamentos e outras restrições, e você conectá-lo usando uma seqüência de conexão, exatamente como faria com o SQL Server e outros bancos de dados.

Armazenamento de tabela de Azure do Windows, por outro lado, parece um pouco misterioso para aqueles de nós que são tão usadas para trabalhar com bancos de dados relacionais. Enquanto você encontrará muitas orientações excelentes para a criação de aplicativos que usam o armazenamento de tabela de Azure do Windows, muitos desenvolvedores ainda se vêem forçados a fazer saltos de fé sem realmente entender o que se trata.

Esta coluna ajudará aqueles presos na ponte de modo relacional salto de fé com aterramento sólido, explicando alguns conceitos básicos do armazenamento de tabela de Azure do Windows sob a perspectiva de pensar relacional. Além disso, eu vai tocar em algumas das estratégias importantes para estruturar as tabelas, dependendo de como você espera que consultar e atualizar seus dados.

Armazenando dados para recuperação eficiente e persistência

Por padrão, serviços do Windows Azure tabela fornece a possibilidade de armazenar enormes quantidades de dados, permitindo o acesso eficiente e persistência. Os serviços de simplificam o armazenamento, evitando que você saltar por meio de todos os hoops necessárias para trabalhar com um banco de dados relacional, as restrições, modos de exibição, índices, relacionamentos e procedimentos armazenados. Assim, você lida com dados, dados, dados. Windows Azure tabelas usam as chaves que permitem a consulta eficiente e você pode empregar uma — o PartitionKey — para balanceamento quando o serviço tabela decide é o momento de distribuir sua tabela através de vários servidores. Uma tabela não tem um esquema especificado. É simplesmente um estruturado contêiner de linhas (ou entidades) que não se preocupar com a aparência de uma linha. Você pode ter uma tabela que armazena um tipo específico, mas você também pode armazenar linhas com estruturas variáveis em uma única tabela, conforme mostrado no do Figura 1.

Figura 1 de um único Windows Azure tabela pode conter linhas representando semelhantes ou diferentes entidades

Está tudo começa com as classes de domínio

Nosso procedimento de desenvolvimento típico com bancos de dados é criá-las, definir tabelas e, em seguida, para cada tabela, definir uma estrutura específica — colunas específicas, cada qual com um tipo de dados especificado — bem como as relações com outras tabelas. Nossos aplicativos, em seguida, enviar dados e extrair dados de tabelas.

No entanto, com os serviços do Windows Azure tabela, você Don criar um banco de dados, apenas as classes. Definir um recipiente (tabela) que uma ou mais classes pertencem, em seguida, você poderá salvar objetos instanciados e de suas classes de volta para o armazenamento como linhas.

Além das propriedades que você precisa de suas classes, cada classe deve ter três propriedades que são importantes na determinação de como os serviços do Windows Azure tabela fazem seu trabalho: PartitionKey RowKey e TimeStamp. PartitionKey e RowKey são as duas cadeias de caracteres e não há uma arte (ou talvez uma ciência) para defini-los, assim, obter o melhor equilíbrio entre eficiência transacionais e de consulta, juntamente com a escalabilidade em tempo de execução. Para uma boa compreensão de como definir PartitionKeys e RowKeys para o máximo benefício, recomendo enfaticamente a sessão PDC09 Dive (Aprofundamento “ Windows Azure Tables e filas do Deep), ” apresentada por Jai Haridas, que você pode assistir ao microsoftpdc.com/sessions/svc09 de .

Unidade de PartitionKeys e RowKeys desempenho e escalabilidade

Muitos desenvolvedores são usados para um sistema de chaves primárias, chaves externas e as restrições entre os dois. Com o armazenamento de tabela de Azure do Windows, você precisa deixar ir esses conceitos ou terá dificuldade em segurando o seu sistema de chaves.

No Windows Azure tabelas, a cadeia de caracteres PartitionKey e RowKey propriedades trabalho juntos como um índice para a sua tabela, portanto, ao defini-los, você deve considerar como seus dados são consultados. Juntas, as propriedades também servem para exclusividade, que atua como uma chave primária para a linha. Cada entidade em uma tabela deve ter uma combinação exclusiva de PartitionKey/RowKey.

Mas você precisa considerar a mais de consulta ao definir um PartitionKey porque ele também é usado para particionar fisicamente as tabelas, que fornece para o balanceamento de carga e dimensionamento. Por exemplo, considere uma tabela que contém informações sobre a comida e tem PartitionKeys correspondem aos tipos de comida, tais como pigmento, frutas e granulado. No verão, as linhas na partição theVegetable podem ser muito ocupadas (tornando-se a uma partição “ hot ” chamada). O serviço pode as muitas solicitações feitas para a partição de lidar com a tabela de comida, movendo-se a partição pigmento para um servidor diferente como 
better de balanceamento de carga.

Se você previr mais atividade nessa partição que um único servidor pode manipular, você deve considerar a criação de partições mais granulares, como Vegetable_Root e Vegetable_Squash. Isso ocorre porque a unidade de granularidade para balanceamento de carga é o PartitionKey. Todas as linhas com o mesmo valor PartitionKey são mantidas juntos quando o balanceamento de carga. Você mesmo pode criar sua tabela, de modo que cada entidade única da tabela tem uma partição diferente.

Compreendendo mais fundo PartitionKeys e consultando

Observe que quando eu sugerido ajuste fino do PartitionKeys pigmento, coloquei pigmento no início da chave, e não no final. Esse é outro mecanismo para permitir consultas mais eficientes. Consultas para Windows Azure tabelas do Microsoft .NET Framework usam LINQ para um contexto que deriva de System.Data.Services.Client.DataServiceContext de serviços de dados do WCF e REST. Se você desejar localizar qualquer squash verde, você pode pesquisar na partição Vegetable_Squash sem desperdiçar recursos de toda a tabela de pesquisa:

var query = _serviceContext.FoodTable.AsTableServiceQuery()
.Where(c => c.PartitionKey=="Vegetable_Squash"&& c.Color == "Green");

Uma grande diferença entre consultando OData (retornado pelos serviços de dados do WCF) e consultas em relação a Windows Azure Tables é que não há suporte para funções de cadeia de caracteres. Se você quiser pesquisar parte de uma seqüência de caracteres, você deve usar String.CompareTo para inspecionar os caracteres do início da cadeia de caracteres. No entanto, se você deseja consultar a categoria inteira de pigmento, você pode usar o método CompareTo para realizar uma pesquisa de prefixo sobre o início do PartitionKey:

var query = _serviceContext.FoodTable.AsTableServiceQuery()
            .Where(c => c.PartitionKey.CompareTo("Vegetable")>=0
            && c.PartitionKey.CompareTo("Vegetablf")<0
            && c.Color == "Green");

Isso limitaria a pesquisa somente as partições que começam com pigmento — nada menos e nada mais. (Usar Vegetablf em vez de pigmento no predicado da segundo define o limite superior, impedindo que os alimentos em partições, como Yogurt ou VegetableLike que estão sendo devolvidos.) O código de exemplo que acompanha este artigo, você verá como eu fiz essa substituição dinamicamente.

Verificações consultando paralela para a tabela inteira

Se você estava procurando todos os alimentos de verde, independentemente do tipo? Windows Azure precisaria examinar a tabela inteira. Se for uma tabela grande, o Windows Azure lança na chave inglesa outra: Ele pode retornar somente 1000 linhas em uma hora (ou o processo de 5 segundos). Windows Azure irá retornar os resultados juntamente com uma chave de continuação de , em seguida, volte para obter mais informações. Isso pode ser um tedioso processo síncrono.

Em vez disso, você pode executar um número de consultas, talvez a iteração por meio de uma lista conhecida de categorias, em seguida, a criação de cada consulta:

_serviceContext.FoodTable.AsTableServiceQuery()
.Where(c => c.PartitionKey == _category && c.Color == "Green");

Em seguida, você pode enviar desativar todas as consultas sejam executados em paralelo.

Obter mais considerações de design para consultar

A propriedade RowKey serve várias finalidades.Em combinação com PartitionKey, ele pode definir a exclusividade dentro de uma tabela para cada linha.Por exemplo, eu sei que outro Lerman de Julie (realmente fazer).Assim, será fundamental para diferenciar nós quando compartilha um PartitionKey de lerman_julie o RowKey.Você também pode usar RowKey para ajudá-lo com a classificação, porque ele atua como parte de um índice.Assim, em seguida, o que seria útil RowKeys para Julie Lerman o elder (ou seja, me) e Julie Lerman o mais jovem?Um GUID, certamente, fará o truque para a identidade, mas ele não faz nada para pesquisas ou de classificação.Nesse caso, uma combinação de valores provavelmente será melhor.

O que mais diferencia nos?Vivemos em oposto extremidades dos Estados Unidos, mas locais podem mudar, portanto, não é útil para uma chave.Certamente, nossa data de nascimento é diferente (por mais de 20 anos) e é um valor estático.Mas, sempre há a possibilidade de que existe em algum lugar do mundo de outro Lerman de Julie com minha data de nascimento e poderia pousar em meu banco de dados — altamente implausible, mas não impossível.Afinal de contas deliberation que eu poderia passar por, data de nascimento pode ainda não ser um valor no qual meu aplicativo está procurando ou classificação.Assim, neste caso, RowKey talvez não seja parte de consultas, e um GUID antigo simples seria suficiente.Você terá de fazer esses tipos de decisões de todas as suas tabelas de Azure do Windows.

Há muito mais para saber sobre a definição de chaves e fatores como a recuperação de dados, armazenamento de dados, escalabilidade e o balanceamento de carga todos entram em cena.

Repensando relacionamentos

Em um banco de dados relacional, contamos com chaves externas e restrições para definir relacionamentos.Nós certamente poderia definir uma propriedade de chave externa em uma classe que se refere a uma outra classe, mas não há nada no armazenamento de tabela de Azure do Windows para impor os relacionamentos.Ainda será responsável por que seu código.

Isso tem impacto sobre como executar consultas e atualizações (incluindo inserções e exclusões) de tabelas.

Ao consultar, não é possível executar associações entre tabelas.E quando a persistência de dados, você não pode ter transacionado comandos que incluam as partições ou tabelas.No entanto, há um mecanismo para trabalhar com dados em gráficos, que é algo que eu apontado no início desta coluna — você pode armazenar as linhas de esquemas diferentes em uma única tabela.

Se seu aplicativo exigir que os usuários trabalham com os contatos e endereços juntos, você pode armazenar os endereços na mesma tabela como os contatos.É importante garantir que os endereços têm a mesma PartitionKey — por exemplo, “ lerman_julie ”. Além disso, o RowKey deve conter um valor que especifica o tipo ou o tipo de entidade, como, por exemplo, “ address_12345 ”, portanto, você pode facilmente diferenciar os tipos de contatos e tipos de endereço ao consultar.

O PartitionKey comum garante que as linhas serão sempre permaneçam juntas para tirar proveito de um recurso chamado EGT (transações de grupo de entidade).Isso permite que uma única transação para executar operações atomicamente entre várias entidades, desde que todas as entidades têm o mesmo valor de PartitionKey.Um dos benefícios de EGT com relação aos dados relacionados é que você pode executar uma atualização transacionada em todas as entidades em uma única transação.

Uma base das noções básicas sobre a partir dos quais aprender mais

Windows Azure tabelas ao vivo na nuvem, mas para mim começou em uma sombra.Tive muitos problemas para fazer minha cabeça disposta ao redor delas por causa da minha compreensão preconcebida de bancos de dados relacionais.Foi uma grande quantidade de trabalho (e pestered muitas pessoas) para permitir que eu mesmo solte as âncoras RDBMS para que eu poderia adotar e realmente apreciar a beleza de Windows Azure Tables.Espero que minha jornada fará com que seu menor.

Não há muito mais para saber mais sobre os serviços do Windows Azure Table.A equipe da Microsoft possui algumas excelentes orientações no MSDN.Juntamente com o vídeo PDC09 mencionado anteriormente, marque esta página de recursos no blog da equipe do Windows Azure Storage em blogs.msdn.com/windowsazurestorage/archive/2010/03/28/windows-azure-storage-resources de .A equipe continuará a adicionar detalhadas e informativas postagens no blog e eu sei que no momento ou até mesmo quando publicada nesta coluna, eu encontrará respostas às minhas perguntas uma infinidade.Estou ansioso para fornecer alguns exemplos concretos em uma futura coluna pontos de dados.

Julie Lerman é um MVP do Microsoft .net mentor e consultor de quem mora nas Montanhas de Vermont. Você pode encontrar a sua apresentação no acesso a dados e outros tópicos do Microsoft .net em grupos de usuários e conferências em todo o mundo. Blogs de Lerman em thedatafarm.com/blog de e é autor do livro altamente aclamado pacote, “ Programming Estrutura de Entidade ” (O’Reilly Media, 2009). Execute a ela em Twitter.com: julielerman.

Graças aos seguintes especialistas técnicos para revisão deste artigo: Brad Calder and*** Jai Haridas***