Criar tabelas escaláveis e de desempenho

Para projetar tabelas escaláveis e de desempenho, você deve considerar fatores como desempenho, escalabilidade e custo. Se você criou esquemas anteriormente para bancos de dados relacionais, essas considerações são familiares, mas embora haja algumas semelhanças entre o modelo de armazenamento do serviço de Tabela do Azure e os modelos relacionais, também há diferenças importantes. Essas diferenças geralmente levam a designs diferentes que podem parecer contraintuitivos ou errados para alguém familiarizado com bancos de dados relacionais, mas fazem sentido se você estiver projetando para um armazenamento de chave/valor NoSQL, como o serviço de Tabela do Azure. Muitas de suas diferenças de design refletem o fato de que o serviço Tabela foi projetado para oferecer suporte a aplicativos em escala de nuvem que podem conter bilhões de entidades (ou linhas na terminologia de banco de dados relacional) de dados ou para conjuntos de dados que devem suportar altos volumes de transações. Portanto, você deve pensar de forma diferente sobre como armazenar seus dados e entender como o serviço de tabela funciona. Um armazenamento de dados NoSQL bem projetado pode permitir que sua solução seja dimensionada muito mais longe e a um custo menor do que uma solução que usa um banco de dados relacional. Este guia ajuda-o com estes tópicos.

Sobre o serviço de Tabela do Azure

Esta seção destaca alguns dos principais recursos do serviço Tabela que são especialmente relevantes para projetar desempenho e escalabilidade. Se você é novo no Armazenamento do Azure e no serviço Tabela, primeiro leia Introdução ao Armazenamento de Tabela do Azure usando .NET antes de ler o restante deste artigo. Embora o foco deste guia esteja no serviço Tabela, ele inclui discussão sobre os serviços de Fila e Blob do Azure e como você pode usá-los com o serviço Tabela.

O que é o serviço de mesa? Como você pode esperar do nome, o serviço Tabela usa um formato tabular para armazenar dados. Na terminologia padrão, cada linha da tabela representa uma entidade e as colunas armazenam as várias propriedades dessa entidade. Cada entidade tem um par de chaves para identificá-la exclusivamente e uma coluna de carimbo de data/hora que o serviço Tabela usa para controlar quando a entidade foi atualizada pela última vez. O carimbo de data/hora é aplicado automaticamente e você não pode substituir manualmente o carimbo de data/hora por um valor arbitrário. O serviço Tabela usa esse carimbo de data/hora (LMT) da última modificação para gerenciar simultaneidade otimista.

O exemplo a seguir mostra um design de tabela simples para armazenar entidades de funcionários e departamentos. Muitos dos exemplos mostrados posteriormente neste guia são baseados neste design simples.

Até agora, esses dados parecem semelhantes a uma tabela em um banco de dados relacional, com as principais diferenças sendo as colunas obrigatórias e a capacidade de armazenar vários tipos de entidade na mesma tabela. Além disso, cada uma das propriedades definidas pelo usuário, como FirstName ou Age , tem um tipo de dados, como inteiro ou string, assim como uma coluna em um banco de dados relacional. Embora diferente de um banco de dados relacional, a natureza sem esquema do serviço Table significa que uma propriedade não precisa ter o mesmo tipo de dados em cada entidade. Para armazenar tipos de dados complexos em uma única propriedade, você deve usar um formato serializado, como JSON ou XML. Para obter mais informações sobre o serviço de tabela, como tipos de dados suportados, intervalos de datas suportados, regras de nomenclatura e restrições de tamanho, consulte Noções básicas sobre o Modelo de Dados do Serviço de Tabela.

Sua escolha de PartitionKey e RowKey é fundamental para um bom design de mesa. Cada entidade armazenada em uma tabela deve ter uma combinação exclusiva de PartitionKey e RowKey. Como acontece com as chaves em uma tabela de banco de dados relacional, os valores PartitionKey e RowKey são indexados para criar um índice clusterizado para permitir pesquisas rápidas. No entanto, o serviço Table não cria nenhum índice secundário, portanto , PartitionKey e RowKey são as únicas propriedades indexadas. Alguns dos padrões descritos em Padrões de design de tabela ilustram como você pode contornar essa limitação aparente.

Uma tabela é composta por uma ou mais partições, e muitas das decisões de design que você toma serão em torno da escolha de uma PartitionKey e RowKey adequadas para otimizar sua solução. Uma solução pode consistir em uma única tabela que contém todas as suas entidades organizadas em partições, mas normalmente uma solução tem várias tabelas. As tabelas ajudam você a organizar logicamente suas entidades, ajudam a gerenciar o acesso aos dados usando listas de controle de acesso e você pode soltar uma tabela inteira usando uma única operação de armazenamento.

Partições da tabela

O nome da conta, o nome da tabela e a PartitionKey juntos identificam a partição dentro do serviço de armazenamento onde o serviço de tabela armazena a entidade. Além de fazerem parte do esquema de endereçamento para entidades, as partições definem um escopo para transações (consulte Transações de Grupo de Entidades abaixo) e formam a base de como o serviço de tabela é dimensionado. Para obter mais informações sobre partições, consulte Lista de verificação de desempenho e escalabilidade para armazenamento de tabelas.

No serviço Tabela, um nó individual atende uma ou mais partições completas e o serviço é dimensionado balanceando dinamicamente a carga de partições entre nós. Se um nó estiver sob carga, o serviço de tabela pode dividir o intervalo de partições atendidas por esse nó em nós diferentes, quando o tráfego diminui, o serviço pode mesclar os intervalos de partição de nós silenciosos de volta para um único nó.

Para obter mais informações sobre os detalhes internos do serviço Tabela e, em particular, como o serviço gerencia partições, consulte o documento Microsoft Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency.

Transações de Grupo de Entidades

No serviço Tabela, as Transações de Grupo de Entidades (EGTs) são o único mecanismo interno para executar atualizações atômicas em várias entidades. As EGTs às vezes também são chamadas de transações em lote. Os EGTs só podem operar em entidades armazenadas na mesma partição (ou seja, compartilhar a mesma chave de partição em uma determinada tabela). Portanto, sempre que você precisar de comportamento transacional atômico em várias entidades, você deve garantir que essas entidades estejam na mesma partição. Isso geralmente é um motivo para manter vários tipos de entidade na mesma tabela (e partição) e não usar várias tabelas para diferentes tipos de entidade. Uma única EGT pode operar em, no máximo, 100 entidades. Se submeter vários EGTs simultâneos para processamento, é importante garantir que esses EGTs não operam em entidades que são comuns em EGTs; caso contrário, o processamento pode ser atrasado.

Os EGTs também introduzem um compromisso potencial para você avaliar em seu projeto. Ou seja, usar mais partições aumenta a escalabilidade do seu aplicativo, porque o Azure tem mais oportunidades para solicitações de balanceamento de carga entre nós. Mas usar mais partições pode limitar a capacidade do seu aplicativo de executar transações atômicas e manter uma forte consistência para seus dados. Além disso, existem destinos de escalabilidade específicos no nível de uma partição que podem limitar a taxa de transferência de transações que você pode esperar para um único nó. Para obter mais informações sobre destinos de escalabilidade para contas de armazenamento padrão do Azure, consulte Destinos de escalabilidade para contas de armazenamento padrão. Para obter mais informações sobre metas de escalabilidade para o serviço Tabela, consulte Metas de escalabilidade e desempenho para armazenamento de tabela.

Considerações de capacidade

A tabela seguinte descreve os objetivos de capacidade, escalabilidade e desempenho para o armazenamento de Tabelas.

Considerações de custos

O armazenamento de tabelas é relativamente barato, mas você deve incluir estimativas de custo para o uso da capacidade e a quantidade de transações como parte de sua avaliação de qualquer solução de serviço de tabela. No entanto, em muitos cenários, armazenar dados desnormalizados ou duplicados para melhorar o desempenho ou a escalabilidade da sua solução é uma abordagem válida. Para obter mais informações sobre preços, consulte Preços do Armazenamento do Azure.

Próximos passos

• Padrões de design de tabela
• Modelando relacionamentos
• Design para consulta
• Criptografando dados da tabela
• Design para modificação de dados