Design da modificação de dados

Este artigo centra-se nas considerações de design para otimizar inserções, atualizações e eliminações. Em alguns casos, terá de avaliar o compromisso entre designs que otimizam a consulta em relação a designs que otimizam a modificação de dados, tal como acontece em designs para bases de dados relacionais (embora as técnicas para gerir as compensações de design sejam diferentes numa base de dados relacional). A secção Padrões de Estrutura da Tabela descreve alguns padrões de conceção detalhados para o serviço Tabela e realça algumas destas trocas. Na prática, verá que muitos designs otimizados para consultar entidades também funcionam bem para modificar entidades.

Otimizar o desempenho das operações de inserção, atualização e eliminação

Para atualizar ou eliminar uma entidade, tem de conseguir identificá-la com os valores PartitionKey e RowKey . A este respeito, a sua escolha de PartitionKey e RowKey para modificar entidades deve seguir critérios semelhantes à sua escolha para suportar consultas de ponto porque pretende identificar entidades da forma mais eficiente possível. Não quer utilizar uma partição ou análise de tabela ineficiente para localizar uma entidade para detetar os valores PartitionKey e RowKey de que precisa para atualizá-la ou eliminá-la.

Os seguintes padrões na secção Padrões de estrutura da tabela abordam a otimização do desempenho ou das operações de inserção, atualização e eliminação:

• Padrão de eliminação de volume elevado – ative a eliminação de um volume elevado de entidades ao armazenar todas as entidades para eliminação simultânea na sua própria tabela separada; elimine as entidades ao eliminar a tabela.
• Padrão de série de dados – armazene séries de dados completas numa única entidade para minimizar o número de pedidos efetuados.
• Padrão de entidades alargadas – utilize várias entidades físicas para armazenar entidades lógicas com mais de 252 propriedades.
• Padrão de entidades grandes – utilize o armazenamento de blobs para armazenar valores de propriedades grandes.

Garantir a consistência nas entidades armazenadas

O outro fator-chave que influencia a sua escolha de chaves para otimizar modificações de dados é como garantir a consistência através de transações atómicas. Só pode utilizar um EGT para operar em entidades armazenadas na mesma partição.

Os seguintes padrões no artigo Padrões de estrutura de tabela abordam a gestão da consistência:

• Padrão de índice secundário da intra partição – armazene várias cópias de cada entidade com valores RowKey diferentes (na mesma partição) para permitir pesquisas rápidas e eficientes e sequências de ordenação alternativas com diferentes valores RowKey .
• Padrão de índice secundário entre partições – armazene várias cópias de cada entidade com valores RowKey diferentes em partições separadas ou em tabelas separadas para permitir pesquisas rápidas e eficientes e sequências de ordenação alternativas com valores RowKey diferentes.
• Padrão de transações eventualmente consistente – ative um comportamento eventualmente consistente entre limites de partições ou limites do sistema de armazenamento com as filas do Azure.
• Padrão de entidades de índice – mantenha as entidades de índice para permitir pesquisas eficientes que devolvem listas de entidades.
• Padrão de desnormalização – combine dados relacionados numa única entidade para que possa obter todos os dados de que precisa com uma consulta de ponto único.
• Padrão de série de dados – armazene séries de dados completas numa única entidade para minimizar o número de pedidos efetuados.

Para obter informações sobre transações de grupos de entidades, veja a secção Transações do grupo de entidades.

Certifique-se de que a sua conceção para modificações eficientes facilita consultas eficientes

Em muitos casos, uma estrutura para uma consulta eficiente resulta em modificações eficientes, mas deve sempre avaliar se é esse o caso para o seu cenário específico. Alguns dos padrões no artigo Padrões de Estrutura da Tabela avaliam explicitamente as desvantagens entre consultar e modificar entidades e deve ter sempre em conta o número de cada tipo de operação.

Os padrões seguintes no artigo Padrões de conceção de tabelas abordam compromissos entre a conceção de consultas eficientes e a conceção de modificações de dados eficientes:

• Padrão de chave composta – utilize valores RowKey compostos para permitir que um cliente procure dados relacionados com uma consulta de ponto único.
• Padrão de cauda de registo – obtenha as n entidades adicionadas mais recentemente a uma partição com um valor RowKey que ordena por ordem inversa de data e hora.