Estratégias de particionamento de dados

Armazenamento de Tabelas do Azure

Este artigo descreve algumas estratégias para particionar dados em vários armazenamentos de dados do Azure. Para obter orientações gerais sobre quando particionar dados e práticas recomendadas, consulte de particionamento de dados .

Particionando o Banco de Dados SQL do Azure

Um único banco de dados SQL tem um limite para o volume de dados que ele pode conter. A taxa de transferência é limitada por fatores de arquitetura e pelo número de conexões simultâneas suportadas.

Pools Elásticos suportam o dimensionamento horizontal para um banco de dados SQL. Usando pools elásticos, você pode particionar seus dados em fragmentos espalhados por vários bancos de dados SQL. Você também pode adicionar ou remover fragmentos à medida que o volume de dados que você precisa manipular cresce e diminui. Os pools elásticos também podem ajudar a reduzir a contenção distribuindo a carga entre bancos de dados.

Cada fragmento é implementado como um banco de dados SQL. Um fragmento pode conter mais de um conjunto de dados (chamado de deshardlet). Cada banco de dados mantém metadados que descrevem os shardlets que ele contém. Um shardlet pode ser um único item de dados ou um grupo de itens que compartilham a mesma chave de shardlet. Por exemplo, em um aplicativo multilocatário, a chave do shardlet pode ser a ID do locatário e todos os dados de um locatário podem ser mantidos no mesmo shardlet.

Os aplicativos cliente são responsáveis por associar um conjunto de dados a uma chave shardlet. Um Banco de Dados SQL separado atua como um gerenciador de mapa de estilhaços global. Esta base de dados contém uma lista de todos os fragmentos e shardlets (subfragmentos) do sistema. A aplicação conecta-se à base de dados do gestor de mapa de fragmentos para obter uma cópia do mapa de fragmentos. Ele armazena em cache o mapa de estilhaços localmente e usa o mapa para rotear solicitações de dados para o fragmento apropriado. Essa funcionalidade está oculta por trás de uma série de APIs contidas na biblioteca de cliente do Elastic Database, que está disponível para Java e .NET.

Para obter mais informações sobre pools elásticos, consulte Dimensionamento com o Banco de Dados SQL do Azure.

Para reduzir a latência e melhorar a disponibilidade, pode replicar a base de dados global do gestor de mapas de fragmentos. Com os níveis de preços Premium, você pode configurar a replicação geográfica ativa para copiar dados continuamente para bancos de dados em diferentes regiões.

Como alternativa, use de Sincronização de Dados SQL do Azure ou do Azure Data Factory para replicar o banco de dados do gerenciador de mapas de estilhaços entre regiões. Essa forma de replicação é executada periodicamente e é mais adequada se o mapa de estilhaços mudar com pouca frequência e não exigir a camada Premium.

O Elastic Database fornece dois esquemas para mapear dados para shardlets e armazená-los em fragmentos:

• Um mapa de estilhaços de lista associa uma única chave a um shardlet. Por exemplo, em um sistema multilocatário, os dados de cada locatário podem ser associados a uma chave exclusiva e armazenados em seu próprio shardlet. Para garantir o isolamento, cada subfragmento pode ser mantido dentro do seu próprio fragmento.

  

  Baixe um arquivo Visio deste diagrama.

• Um mapa de estilhaços de intervalo de associa um conjunto de valores-chave contíguos a um shardlet. Por exemplo, você pode agrupar os dados de um conjunto de locatários (cada um com sua própria chave) dentro do mesmo shardlet. Este esquema é menos dispendioso do que o primeiro, porque os inquilinos partilham armazenamento de dados, mas tem menos isolamento.

  

  Baixe um arquivo Visio deste diagrama

Um único fragmento pode conter os dados de vários sub-fragmentos. Por exemplo, é possível usar fragmentos de lista para armazenar dados de diferentes clientes não contíguos no mesmo fragmento. Você também pode misturar shardlets de alcance e shardlets de lista no mesmo fragmento, embora eles sejam abordados através de mapas diferentes. O diagrama a seguir mostra essa abordagem:

Baixe um arquivo Visio deste diagrama.

Os pools elásticos possibilitam adicionar e remover fragmentos à medida que o volume de dados diminui e cresce. Os aplicativos cliente podem criar e excluir fragmentos dinamicamente e atualizar de forma transparente o gerenciador de mapas de estilhaços. No entanto, a remoção de um fragmento é uma operação destrutiva que também requer a exclusão de todos os dados desse fragmento.

Se um aplicativo precisar dividir um fragmento em dois fragmentos separados ou combinar fragmentos, use a ferramenta de mesclagem dividida. Essa ferramenta é executada como um serviço Web do Azure e migra dados com segurança entre fragmentos.

O esquema de particionamento pode afetar significativamente o desempenho do seu sistema. Também pode afetar a taxa na qual os fragmentos devem ser adicionados ou removidos, ou que os dados devem ser reparticionados entre fragmentos. Considere os seguintes pontos:

• Agrupe dados usados juntos no mesmo fragmento e evite operações que acessam dados de vários fragmentos. Um fragmento é um banco de dados SQL por si só, e as junções entre bancos de dados devem ser executadas no lado do cliente.

  Embora o Banco de dados SQL não ofereça suporte a junções entre bancos de dados, você pode usar as ferramentas do Banco de Dados Elástico para executar consultas de vários estilhaços. Uma consulta com múltiplos shards envia consultas individuais para cada banco de dados e consolida os resultados.

• Não projete um sistema que tenha dependências entre fragmentos. Restrições de integridade referencial, gatilhos e procedimentos armazenados em um banco de dados não podem fazer referência a objetos em outro.

• Se você tiver dados de referência usados com freqüência por consultas, considere replicar esses dados entre fragmentos. Essa abordagem pode eliminar a necessidade de unir dados entre bancos de dados. Idealmente, esses dados devem ser estáticos ou lentos, para minimizar o esforço de replicação e reduzir as chances de se tornarem obsoletos.

• Os shardlets que pertencem ao mesmo mapa de estilhaços devem ter o mesmo esquema. Essa regra não é imposta pelo Banco de dados SQL, mas o gerenciamento e a consulta de dados se tornam muito complexos se cada shardlet tiver um esquema diferente. Em vez disso, crie mapas de estilhaços separados para cada esquema. Lembre-se de que os dados pertencentes a diferentes shardlets podem ser armazenados no mesmo fragmento.

• As operações transacionais são suportadas apenas para dados dentro de um fragmento, e não entre fragmentos. As transações podem abranger shardlets, desde que façam parte do mesmo fragmento. Portanto, se sua lógica de negócios precisa realizar transações, armazene os dados no mesmo fragmento ou implemente uma eventual consistência.

• Coloque fragmentos perto dos usuários que acessam os dados nesses fragmentos. Essa estratégia ajuda a reduzir a latência.

• Evite ter uma mistura de fragmentos altamente ativos e relativamente inativos. Tente distribuir a carga uniformemente pelos estilhaços. Isso pode exigir hashing das chaves de fragmentação. Se você estiver localizando geograficamente fragmentos, certifique-se de que as chaves com hash sejam mapeadas para shardlets mantidos em fragmentos armazenados perto dos usuários que acessam esses dados.

Particionando o armazenamento de tabela do Azure

O Armazenamento de Tabela do Azure é um armazenamento de chave-valor projetado em torno do particionamento. Todas as entidades são armazenadas em uma partição e as partições são gerenciadas internamente pelo armazenamento de Tabela do Azure. Cada entidade armazenada em uma tabela deve fornecer uma chave de duas partes que inclui:

• A chave de partição. Este é um valor de cadeia de caracteres que determina a partição onde o armazenamento de Tabela do Azure colocará a entidade. Todas as entidades com a mesma chave de partição são armazenadas na mesma partição.

• A chave de linha. Este é um valor de cadeia de caracteres que identifica a entidade dentro da partição. Todas as entidades dentro de uma partição são classificadas lexicamente, em ordem crescente, por esta chave. A combinação de chave de partição/chave de linha deve ser exclusiva para cada entidade e não pode exceder 1 KB de comprimento.

Se uma entidade for adicionada a uma tabela com uma chave de partição não utilizada anteriormente, o Armazenamento de Tabela do Azure criará uma nova partição para essa entidade. Outras entidades com a mesma chave de partição serão armazenadas na mesma partição.

Este mecanismo implementa efetivamente uma estratégia de expansão automática. Cada partição é armazenada no mesmo servidor em um datacenter do Azure para ajudar a garantir que as consultas que recuperam dados de uma única partição sejam executadas rapidamente.

A Microsoft publicou metas de escalabilidade para o Armazenamento do Azure. Se for provável que o seu sistema exceda esses limites, considere dividir as entidades em várias tabelas. Use o particionamento vertical para dividir os campos nos grupos com maior probabilidade de serem acessados juntos.

O diagrama a seguir mostra a estrutura lógica de uma conta de armazenamento de exemplo. A conta de armazenamento contém três tabelas: Informações do cliente, Informações do produto e Informações do pedido.

Cada tabela tem várias partições.

• Na tabela Informações do cliente, os dados são particionados de acordo com a cidade onde o cliente está localizado. A chave de linha contém o ID do cliente.
• Na tabela Informações do produto, os produtos são particionados por categoria de produto e a chave de linha contém o número do produto.
• Na tabela Informações do pedido, os pedidos são particionados por data do pedido, e a chave de linha especifica a hora em que o pedido foi recebido. Todos os dados são ordenados pela chave de linha em cada partição.

Considere os seguintes pontos ao projetar suas entidades para o armazenamento de tabela do Azure:

• Selecione uma chave de partição e uma chave de linha de acordo com a forma como os dados são acessados. Escolha uma combinação de chave de partição/chave de linha que suporte a maioria das suas consultas. As consultas mais eficientes recuperam dados especificando a chave de partição e a chave de linha. As consultas que especificam uma chave de partição e um intervalo de chaves de linha podem ser concluídas verificando uma única partição. Isso é relativamente rápido porque os dados são mantidos em ordem de chave de linha. Se as consultas não especificarem qual partição examinar, todas as partições deverão ser verificadas.

• Se uma entidade tiver uma chave natural, use-a como a chave de partição e especifique uma cadeia de caracteres vazia como a chave de linha. Se uma entidade tiver uma chave composta que consiste em duas propriedades, selecione a propriedade de alteração mais lenta como a chave de partição e a outra como a chave de linha. Se uma entidade tiver mais de duas propriedades de chave, use uma concatenação de propriedades para fornecer as chaves de partição e linha.

• Se você executar regularmente consultas que pesquisam dados usando campos diferentes das chaves de partição e linha, considere implementar o padrão Tabela de Índice ou considere usar um armazenamento de dados diferente que ofereça suporte à indexação, como o Azure Cosmos DB.

• Se você gerar chaves de partição usando uma sequência monotônica (como "0001", "0002", "0003") e cada partição contiver apenas uma quantidade limitada de dados, o armazenamento de Tabela do Azure poderá agrupar fisicamente essas partições no mesmo servidor. O Armazenamento do Azure pressupõe que o aplicativo tem maior probabilidade de executar consultas em um intervalo contíguo de partições (consultas de intervalo) e é otimizado para esse caso. No entanto, esta abordagem pode conduzir a centros de registo, uma vez que é provável que todas as inserções de novas entidades se concentrem num extremo da gama contígua. Também pode reduzir a escalabilidade. Para distribuir a carga de forma mais uniforme, considere hashing da chave de partição.

• O Armazenamento de Tabela do Azure dá suporte a operações transacionais para entidades que pertencem à mesma partição. Um aplicativo pode executar várias operações de inserção, atualização, exclusão, substituição ou mesclagem como uma unidade atômica, desde que a transação não inclua mais de 100 entidades e a carga útil da solicitação não exceda 4 MB. As operações que abrangem várias partições não são transacionais e podem exigir que você implemente uma eventual consistência. Para obter mais informações sobre armazenamento de tabelas e transações, consulte Executando transações de grupo de entidades.

• Considere a granularidade da chave de partição:

  • Usar a mesma chave de partição para cada entidade resulta em uma única partição mantida em um servidor. Isso impede que a partição seja dimensionada e concentra a carga em um único servidor. Como resultado, essa abordagem só é adequada para armazenar um pequeno número de entidades. No entanto, garante que todas as entidades possam participar em transações de grupos de entidades.

  • O uso de uma chave de partição exclusiva para cada entidade faz com que o serviço de armazenamento de tabelas crie uma partição separada para cada entidade, possivelmente resultando em um grande número de partições pequenas. Essa abordagem é mais escalável do que usar uma única chave de partição, mas as transações de grupo de entidades não são possíveis. Além disso, as consultas que buscam mais de uma entidade podem envolver a leitura de mais de um servidor. No entanto, se o aplicativo executar consultas de intervalo, usar uma sequência monotônica para as chaves de partição pode ajudar a otimizar essas consultas.

  • O compartilhamento da chave de partição em um subconjunto de entidades torna possível agrupar entidades relacionadas na mesma partição. As operações que envolvem entidades relacionadas podem ser executadas usando transações de grupo de entidades, e consultas que buscam um conjunto de entidades relacionadas podem ser satisfeitas acessando um único servidor.

Para obter mais informações, consulte guia de design de tabela do Armazenamento do Azure e Estratégia de particionamento escalável.

Particionando o Armazenamento de Blobs do Azure

O Armazenamento de Blobs do Azure torna possível armazenar grandes objetos binários. Use blobs de bloco em cenários em que você precisa carregar ou baixar grandes volumes de dados rapidamente. Use blobs de página para aplicativos que exigem acesso aleatório em vez de serial a partes dos dados.

Cada blob (bloco ou página) é mantido em um contêiner em uma conta de Armazenamento do Azure. Você pode usar contêineres para agrupar blobs relacionados que tenham os mesmos requisitos de segurança. Este agrupamento é lógico e não físico. Dentro de um contêiner, cada blob tem um nome exclusivo.

A chave de partição para um blob é nome da conta + nome do contêiner + nome do blob. A chave de partição é usada para particionar dados em intervalos e esses intervalos são balanceados de carga em todo o sistema. Os blobs podem ser distribuídos em vários servidores para expandir o acesso a eles, mas um único blob só pode ser servido por um único servidor.

Se o seu esquema de nomenclatura usa carimbos de data/hora ou identificadores numéricos, isso pode levar a um tráfego excessivo indo para uma partição, limitando o sistema de balanceamento de carga eficaz. Por exemplo, se você tiver operações diárias que usam um objeto blob com um carimbo de data/hora, como aaaa-mm-dd, todo o tráfego dessa operação irá para um único servidor de partição. Em vez disso, considere prefixar o nome com um hash de três dígitos. Para obter mais informações, consulte Convenção de Nomenclatura de Partições.

As ações de escrever um único bloco ou página são atômicas, mas as operações que abrangem blocos, páginas ou blobs não são. Se você precisar garantir a consistência ao executar operações de gravação em blocos, páginas e blobs, retire um bloqueio de gravação usando uma concessão de blob.

Particionando filas de Armazenamento do Azure

As filas de Armazenamento do Azure permitem implementar mensagens assíncronas entre processos. Uma conta de Armazenamento do Azure pode conter qualquer número de filas e cada fila pode conter qualquer número de mensagens. A única limitação é o espaço disponível na conta de armazenamento. O tamanho máximo de uma mensagem individual é de 64 KB. Se você precisar de mensagens maiores do que isso, considere usar filas do Barramento de Serviço do Azure.

Cada fila de armazenamento tem um nome exclusivo dentro da conta de armazenamento que a contém. Filas de partições do Azure com base no nome. Todas as mensagens para a mesma fila são armazenadas na mesma partição, que é controlada por um único servidor. Filas diferentes podem ser gerenciadas por servidores diferentes para ajudar a equilibrar a carga. A alocação de filas para servidores é transparente para aplicativos e usuários.

Em um aplicativo de grande escala, não use a mesma fila de armazenamento para todas as instâncias do aplicativo porque essa abordagem pode fazer com que o servidor que está hospedando a fila se torne um ponto de acesso. Em vez disso, use filas diferentes para diferentes áreas funcionais do aplicativo. As filas do Armazenamento do Azure não dão suporte a transações, portanto, direcionar mensagens para filas diferentes deve ter pouco efeito na consistência das mensagens.

Uma fila de Armazenamento do Azure pode lidar com até 2.000 mensagens por segundo. Se você precisar processar mensagens em uma taxa maior do que essa, considere a criação de várias filas. Por exemplo, em um aplicativo global, crie filas de armazenamento separadas em contas de armazenamento separadas para lidar com instâncias de aplicativos que estão sendo executadas em cada região.

Particionando o Barramento de Serviço do Azure

O Barramento de Serviço do Azure usa um agente de mensagens para manipular mensagens enviadas para uma fila ou tópico do Barramento de Serviço. Por padrão, todas as mensagens enviadas para uma fila ou tópico são tratadas pelo mesmo processo do agente de mensagens. Essa arquitetura pode colocar uma limitação na taxa de transferência geral da fila de mensagens. No entanto, você também pode particionar uma fila ou tópico quando ele é criado. Para fazer isso, defina a propriedade EnablePartitioning da fila ou descrição do tópico como true.

Uma fila ou tópico particionado é dividido em vários fragmentos, cada um dos quais é apoiado por um armazenamento de mensagens separado e um agente de mensagens. O Service Bus assume a responsabilidade de criar e gerenciar esses fragmentos. Quando um aplicativo posta uma mensagem em uma fila ou tópico particionado, o Service Bus atribui a mensagem a um fragmento para essa fila ou tópico. Quando um aplicativo recebe uma mensagem de uma fila ou assinatura, o Barramento de Serviço verifica cada fragmento em busca da próxima mensagem disponível e, em seguida, a passa para o aplicativo para processamento.

Essa estrutura ajuda a distribuir a carga entre agentes de mensagens e armazenamentos de mensagens, aumentando a escalabilidade e melhorando a disponibilidade. Se o agente de mensagens ou o armazenamento de mensagens de um fragmento estiver temporariamente indisponível, o Service Bus poderá recuperar mensagens de um dos fragmentos restantes disponíveis.

O Service Bus atribui uma mensagem a um fragmento da seguinte maneira:

• Se a mensagem pertencer a uma sessão, todas as mensagens com o mesmo valor para a propriedade SessionId serão enviadas para o mesmo fragmento.

• Se a mensagem não pertencer a uma sessão, mas o remetente tiver especificado um valor para a propriedade PartitionKey, todas as mensagens com o mesmo valor PartitionKey serão enviadas para o mesmo fragmento.

  Observação

  Se as propriedades SessionId e PartitionKey forem especificadas, elas deverão ser definidas com o mesmo valor ou a mensagem será rejeitada.

• Se as propriedades SessionId e PartitionKey de uma mensagem não forem especificadas, mas a deteção de duplicados estiver habilitada, a propriedade MessageId será usada. Todas as mensagens com o mesmo MessageId serão direcionadas para o mesmo fragmento.

• Se as mensagens não incluírem um SessionId, PartitionKey, ou propriedade MessageId, o Service Bus atribuirá mensagens a fragmentos sequencialmente. Se um fragmento não estiver disponível, o Service Bus passará para o próximo. Isso significa que uma falha temporária na infraestrutura de mensagens não faz com que a operação de envio de mensagens falhe.

Considere os seguintes pontos ao decidir se ou como particionar uma fila ou tópico de mensagens do Service Bus:

• Filas e tópicos do Barramento de Serviço são criados dentro do escopo de um namespace do Barramento de Serviço. Atualmente, o Service Bus permite até 100 filas ou tópicos particionados por namespace.

• Cada namespace do Service Bus impõe cotas aos recursos disponíveis, como o número de assinaturas por tópico, o número de solicitações simultâneas de envio e recebimento por segundo e o número máximo de conexões simultâneas que podem ser estabelecidas. Essas cotas estão documentadas em cotas do Service Bus. Se você espera exceder esses valores, crie namespaces adicionais com suas próprias filas e tópicos e espalhe o trabalho por esses namespaces. Por exemplo, em um aplicativo global, crie namespaces separados em cada região e configure instâncias de aplicativo para usar as filas e tópicos no namespace mais próximo.

• As mensagens que são enviadas como parte de uma transação têm de especificar uma chave de partição. Pode ser um SessionId, PartitionKeyou propriedade MessageId. Todas as mensagens enviadas como parte da mesma transação devem especificar a mesma chave de partição porque devem ser manipuladas pelo mesmo processo de agente de mensagens. Não é possível enviar mensagens para filas ou tópicos diferentes dentro da mesma transação.

• Filas e tópicos particionados não podem ser configurados para serem excluídos automaticamente quando ficam ociosos.

• No momento, filas e tópicos particionados não podem ser usados com o AMQP (Advanced Message Queuing Protocol) se você estiver criando soluções híbridas ou multiplataforma.

Particionando o Azure Cosmos DB

Azure Cosmos DB para NoSQL é um banco de dados NoSQL para armazenar documentos JSON. Um documento em um banco de dados do Azure Cosmos DB é uma representação serializada em JSON de um objeto ou outra parte dos dados. Nenhum esquema fixo é aplicado, exceto que cada documento deve conter uma ID exclusiva.

Os documentos estão organizados em coleções. Você pode agrupar documentos relacionados em uma coleção. Por exemplo, em um sistema que mantém postagens de blog, você pode armazenar o conteúdo de cada postagem de blog como um documento em uma coleção. Você também pode criar coleções para cada tipo de assunto. Como alternativa, em um aplicativo multilocatário, como um sistema em que diferentes autores controlam e gerenciam suas próprias postagens de blog, você pode particionar blogs por autor e criar coleções separadas para cada autor. O espaço de armazenamento alocado para coleções é elástico e pode diminuir ou crescer conforme necessário.

O Azure Cosmos DB dá suporte ao particionamento automático de dados com base em uma chave de partição definida pelo aplicativo. Um de partição lógica é uma partição que armazena todos os dados para um único valor de chave de partição. Todos os documentos que compartilham o mesmo valor para a chave de partição são colocados dentro da mesma partição lógica. O Azure Cosmos DB distribui valores de acordo com o hash da chave de partição. Uma partição lógica tem um tamanho máximo de 20 GB. Portanto, a escolha da chave de partição é uma decisão importante em tempo de design. Escolha um imóvel com uma ampla gama de valores e até mesmo padrões de acesso. Para obter mais informações, consulte particionar e dimensionar no Azure Cosmos DB.

Observação

Cada banco de dados do Azure Cosmos DB tem um nível de desempenho que determina a quantidade de recursos que recebe. Um nível de desempenho está associado a uma unidade de solicitação de (RU) limite de taxa. O limite de taxa de RU especifica o volume de recursos reservados e disponíveis para uso exclusivo por essa coleção. O custo de uma coleção depende do nível de desempenho selecionado para essa coleção. Quanto maior o nível de desempenho (e limite de taxa de RU) maior a carga. Você pode ajustar o nível de desempenho de uma coleção usando o portal do Azure. Para obter mais informações, consulte unidades de solicitação no Azure Cosmos DB.

Se o mecanismo de particionamento que o Azure Cosmos DB fornece não for suficiente, talvez seja necessário fragmentar os dados no nível do aplicativo. As coleções de documentos fornecem um mecanismo natural para particionar dados dentro de um único banco de dados. A maneira mais simples de implementar a fragmentação é criar uma coleção para cada fragmento. Os contêineres são recursos lógicos e podem abranger um ou mais servidores. Os contêineres de tamanho fixo têm um limite máximo de 20 GB e taxa de transferência de 10.000 RU/s. Os contêineres ilimitados não têm um tamanho máximo de armazenamento, mas devem especificar uma chave de partição. Com a fragmentação de aplicativos, o aplicativo cliente deve direcionar solicitações para o fragmento apropriado, geralmente implementando seu próprio mecanismo de mapeamento com base em alguns atributos dos dados que definem a chave de estilhaço.

Todos os bancos de dados são criados no contexto de uma conta de banco de dados do Azure Cosmos DB. Uma única conta pode conter vários bancos de dados e especifica em quais regiões os bancos de dados são criados. Cada conta também impõe seu próprio controle de acesso. Você pode usar contas do Azure Cosmos DB para localizar geograficamente fragmentos (coleções em bancos de dados) perto dos usuários que precisam acessá-los e impor restrições para que apenas esses usuários possam se conectar a eles.

Considere os seguintes pontos ao decidir como particionar dados com o Azure Cosmos DB para NoSQL:

• Os recursos disponíveis para um banco de dados do Azure Cosmos DB estão sujeitos às limitações de cota da conta. Cada banco de dados pode conter várias coleções, e cada coleção está associada a um nível de desempenho que rege o limite de taxa de RU (taxa de transferência reservada) para essa coleção. Para obter mais informações, consulte limites, cotas e restrições de assinaturas e serviços do Azure.

• Cada documento deve ter um atributo que possa ser usado para identificar exclusivamente esse documento dentro da coleção na qual ele é mantido. Esse atributo é diferente da chave de estilhaço, que define qual coleção contém o documento. Uma coleção pode conter um grande número de documentos. Em teoria, é limitado apenas pelo comprimento máximo do ID do documento. O ID do documento pode ter até 255 caracteres.

• Todas as operações em relação a um documento são realizadas dentro do contexto de uma transação. As transações têm como escopo a coleção na qual o documento está contido. Se uma operação falhar, o trabalho que ela executou será revertido. Embora um documento esteja sujeito a uma operação, todas as alterações feitas estão sujeitas ao isolamento no nível de instantâneo. Esse mecanismo garante que, se, por exemplo, uma solicitação para criar um novo documento falhar, outro usuário que estiver consultando o banco de dados simultaneamente não verá um documento parcial que será removido.

• As consultas de banco de dados também têm como escopo o nível de coleta. Uma única consulta pode recuperar dados de apenas uma coleção. Se você precisar recuperar dados de várias coleções, deverá consultar cada coleção individualmente e mesclar os resultados no código do aplicativo.

• Azure Cosmos DB dá suporte a itens programáveis que podem ser armazenados em uma coleção junto com documentos. Isso inclui procedimentos armazenados, funções definidas pelo usuário e gatilhos (escritos em JavaScript). Esses itens podem acessar qualquer documento dentro da mesma coleção. Além disso, esses itens são executados dentro do escopo da transação ambiente (no caso de um gatilho que é acionado como resultado de uma operação de criação, exclusão ou substituição executada em um documento) ou iniciando uma nova transação (no caso de um procedimento armazenado que é executado como resultado de uma solicitação explícita do cliente). Se o código em um item programável gerar uma exceção, a transação será revertida. Você pode usar procedimentos armazenados e gatilhos para manter a integridade e a consistência entre documentos, mas todos esses documentos devem fazer parte da mesma coleção.

• É improvável que as coleções que você pretende manter nos bancos de dados excedam os limites de taxa de transferência definidos pelos níveis de desempenho das coleções. Para obter mais informações, consulte unidades de solicitação no Azure Cosmos DB. Se você prevê atingir esses limites, considere dividir coleções entre bancos de dados em contas diferentes para reduzir a carga por coleção.

Particionando a Pesquisa de IA do Azure

A capacidade de pesquisar dados é muitas vezes o principal método de navegação e exploração que é fornecido por muitas aplicações web. Ele ajuda os usuários a encontrar recursos rapidamente (por exemplo, produtos em um aplicativo de comércio eletrônico) com base em combinações de critérios de pesquisa. O serviço AI Search fornece recursos de pesquisa de texto completo sobre conteúdo da Web e inclui recursos como digitação antecipada, consultas sugeridas com base em correspondências próximas e navegação facetada. Para obter mais informações, consulte O que é AI Search?.

O AI Search armazena conteúdo pesquisável como documentos JSON em um banco de dados. Você define índices que especificam os campos pesquisáveis nesses documentos e fornece essas definições para o AI Search. Quando um usuário envia uma solicitação de pesquisa, o AI Search usa os índices apropriados para encontrar itens correspondentes.

Para reduzir a contenção, o armazenamento usado pelo AI Search pode ser dividido em 1, 2, 3, 4, 6 ou 12 partições, e cada partição pode ser replicada até 6 vezes. O produto do número de partições multiplicado pelo número de réplicas é chamado de unidade de pesquisa (SU). Uma única instância do AI Search pode conter um máximo de 36 SUs (um banco de dados com 12 partições suporta apenas um máximo de 3 réplicas).

Você é cobrado por cada SU alocado ao seu serviço. À medida que o volume de conteúdo pesquisável aumenta ou a taxa de solicitações de pesquisa aumenta, você pode adicionar SUs a uma instância existente do AI Search para lidar com a carga extra. O próprio AI Search distribui os documentos uniformemente pelas partições. Nenhuma estratégia de particionamento manual é suportada no momento.

Cada partição pode conter um máximo de 15 milhões de documentos ou ocupar 300 GB de espaço de armazenamento (o que for menor). Você pode criar até 50 índices. O desempenho do serviço varia e depende da complexidade dos documentos, dos índices disponíveis e dos efeitos da latência da rede. Em média, uma única réplica (1 SU) deve ser capaz de lidar com 15 consultas por segundo (QPS), embora recomendemos a realização de benchmarking com seus próprios dados para obter uma medida mais precisa de taxa de transferência. Para obter mais informações, consulte Limites de serviço no AI Search.

Observação

Você pode armazenar um conjunto limitado de tipos de dados em documentos pesquisáveis, incluindo cadeias de caracteres, booleanos, dados numéricos, dados de data/hora e alguns dados geográficos. Para obter mais informações, consulte a página Tipos de dados suportados (AI Search) no site da Microsoft.

Você tem controle limitado sobre como o AI Search particiona dados para cada instância do serviço. No entanto, em um ambiente global, você poderá melhorar o desempenho e reduzir ainda mais a latência e a contenção particionando o próprio serviço usando uma das seguintes estratégias:

• Crie uma instância do AI Search em cada região geográfica e garanta que os aplicativos cliente sejam direcionados para a instância disponível mais próxima. Essa estratégia exige que todas as atualizações de conteúdo pesquisável sejam replicadas em tempo hábil em todas as instâncias do serviço.

• Crie duas camadas de Pesquisa de IA:

  • Um serviço local em cada região que contém os dados acessados com mais frequência pelos usuários nessa região. Os usuários podem direcionar solicitações aqui para obter resultados rápidos, mas limitados.
  • Um serviço global que engloba todos os dados. Os usuários podem direcionar solicitações aqui para obter resultados mais lentos, mas mais completos.

Essa abordagem é mais adequada quando há uma variação regional significativa nos dados que estão sendo pesquisados.

Particionando o Cache do Azure para Redis

O Cache Redis do Azure fornece um serviço de cache compartilhado na nuvem baseado no armazenamento de dados chave-valor do Redis. Como o próprio nome indica, o Cache Redis do Azure destina-se a ser uma solução de cache. Use-o apenas para armazenar dados transitórios e não como um armazenamento de dados permanente. Os aplicativos que usam o Cache Redis do Azure devem poder continuar funcionando se o cache não estiver disponível. O Cache Redis do Azure dá suporte à replicação primária/secundária para fornecer alta disponibilidade, mas atualmente limita o tamanho máximo do cache a 53 GB. Se precisar de mais espaço do que isso, você deve criar caches adicionais. Para obter mais informações, veja Azure Cache for Redis (Cache do Azure para Redis).

O particionamento de um armazenamento de dados Redis envolve a divisão dos dados entre instâncias do serviço Redis. Cada instância constitui uma única partição. O Cache do Azure para Redis abstrai os serviços do Redis por trás de uma fachada e não os expõe diretamente. A maneira mais simples de implementar o particionamento é criar várias instâncias do Cache do Azure para Redis e distribuir os dados entre elas.

Você pode associar cada item de dados a um identificador (uma chave de partição) que especifica qual cache armazena o item de dados. A lógica do aplicativo cliente pode usar esse identificador para rotear solicitações para a partição apropriada. Esse esquema é muito simples, mas se o esquema de particionamento for alterado (por exemplo, se instâncias adicionais do Cache do Azure para Redis forem criadas), os aplicativos cliente talvez precisem ser reconfigurados.

O Redis nativo (não o Cache do Azure para Redis) dá suporte ao particionamento do lado do servidor com base no cluster Redis. Nessa abordagem, você pode dividir os dados uniformemente entre servidores usando um mecanismo de hash. Cada servidor Redis armazena metadados que descrevem o intervalo de chaves hash que a partição mantém e também contém informações sobre quais chaves hash estão localizadas nas partições em outros servidores.

Os aplicativos cliente simplesmente enviam solicitações para qualquer um dos servidores Redis participantes (provavelmente o mais próximo). O servidor Redis examina a solicitação do cliente. Se puder ser resolvido localmente, ele executa a operação solicitada. Caso contrário, ele encaminha a solicitação para o servidor apropriado.

Esse modelo é implementado usando o cluster Redis e é descrito com mais detalhes na página do tutorial do cluster do Redis no site do Redis. O clustering Redis é transparente para aplicativos cliente. Servidores Redis adicionais podem ser adicionados ao cluster (e os dados podem ser reparticionados) sem exigir que você reconfigure os clientes.

Importante

Atualmente, o Cache do Azure para Redis dá suporte ao clustering Redis somente na camada Premium.

A página Particionamento: como dividir dados entre várias instâncias do Redis no site do Redis fornece mais informações sobre como implementar o particionamento com o Redis. O restante desta seção pressupõe que você esteja implementando particionamento do lado do cliente ou assistido por proxy.

Considere os seguintes pontos ao decidir como particionar dados com o Cache do Azure para Redis:

• O Cache Redis do Azure não se destina a atuar como um armazenamento de dados permanente, portanto, seja qual for o esquema de particionamento implementado, o código do aplicativo deve ser capaz de recuperar dados de um local que não seja o cache.

• Os dados que são frequentemente acessados juntos devem ser mantidos na mesma partição. O Redis é um poderoso armazenamento de chave-valor que fornece vários mecanismos altamente otimizados para a estruturação de dados. Estes mecanismos podem ser um dos seguintes:

  • Strings simples (dados binários de até 512 MB de comprimento)
  • Agregar tipos, como listas (que podem atuar como filas e pilhas)
  • Conjuntos (ordenados e não ordenados)
  • Hashes (que podem agrupar campos relacionados, como os itens que representam os campos em um objeto)

• Os tipos agregados permitem associar muitos valores relacionados à mesma chave. Uma chave Redis identifica uma lista, um conjunto ou um hash em vez dos itens de dados que ela contém. Esses tipos estão todos disponíveis com o Cache Redis do Azure e são descritos pela página Tipos de dados no site do Redis. Por exemplo, em parte de um sistema de comércio eletrônico que rastreia os pedidos que são feitos pelos clientes, os detalhes de cada cliente podem ser armazenados em um hash Redis que é digitado usando o ID do cliente. Cada hash pode conter uma coleção de IDs de ordem para o cliente. Um conjunto Redis separado pode conter as ordens, novamente estruturadas como hashes, e digitadas usando o ID da ordem. A Figura 8 mostra esta estrutura. Observe que o Redis não implementa nenhuma forma de integridade referencial, portanto, é responsabilidade do desenvolvedor manter as relações entre clientes e pedidos.

Figura 8. Estrutura sugerida no armazenamento Redis para registro de pedidos de clientes e seus detalhes.

Observação

No Redis, todas as chaves são valores de dados binários (como cadeias de caracteres Redis) e podem conter até 512 MB de dados. Em teoria, uma chave pode conter quase qualquer informação. No entanto, recomendamos a adoção de uma convenção de nomenclatura consistente para chaves que seja descritiva do tipo de dados e que identifique a entidade, mas não seja excessivamente longa. Uma abordagem comum é usar chaves do formulário "entity_type:ID". Por exemplo, você pode usar "customer:99" para indicar a chave de um cliente com o ID 99.

• Você pode implementar o particionamento vertical armazenando informações relacionadas em diferentes agregações no mesmo banco de dados. Por exemplo, em um aplicativo de comércio eletrônico, você pode armazenar informações comumente acessadas sobre produtos em um hash Redis e informações detalhadas usadas com menos frequência em outro. Ambos os hashes podem usar o mesmo ID do produto como parte da chave. Por exemplo, você pode usar "product: nn" (onde nn é o ID do produto) para as informações do produto e "product_details: nn" para os dados detalhados. Essa estratégia pode ajudar a reduzir o volume de dados que a maioria das consultas provavelmente recuperará.

• Você pode reparticionar um armazenamento de dados Redis, mas lembre-se de que é uma tarefa complexa e demorada. O clustering Redis pode reparticionar dados automaticamente, mas esse recurso não está disponível com o Cache do Azure para Redis. Portanto, ao projetar seu esquema de particionamento, tente deixar espaço livre suficiente em cada partição para permitir o crescimento esperado de dados ao longo do tempo. No entanto, lembre-se de que o Cache Redis do Azure se destina a armazenar dados em cache temporariamente e que os dados mantidos no cache podem ter um tempo de vida limitado especificado como um valor TTL (time-to-live). Para dados relativamente voláteis, o TTL pode ser curto, mas para dados estáticos o TTL pode ser muito mais longo. Evite armazenar grandes quantidades de dados de longa duração no cache se o volume desses dados provavelmente preencher o cache. Você pode especificar uma política de remoção que faça com que o Cache Redis do Azure remova dados se o espaço for escasso.

  Observação

  Ao usar o Cache do Azure para Redis, você especifica o tamanho máximo do cache (de 250 MB a 53 GB) selecionando o nível de preço apropriado. No entanto, depois que um Cache Redis do Azure tiver sido criado, você não poderá aumentar (ou diminuir) seu tamanho.

• Os lotes e transações do Redis não podem abranger várias conexões, portanto, todos os dados afetados por um lote ou transação devem ser mantidos no mesmo banco de dados (fragmento).

  Observação

  Uma sequência de operações numa transação Redis não é necessariamente atómica. Os comandos que compõem uma transação são verificados e enfileirados antes de serem executados. Se ocorrer um erro durante essa fase, toda a fila será descartada. No entanto, depois que a transação for enviada com êxito, os comandos enfileirados serão executados em sequência. Se algum comando falhar, apenas esse comando para de ser executado. Todos os comandos anteriores e subsequentes na fila são executados. Para obter mais informações, acesse a página Transações no site do Redis.

• O Redis suporta um número limitado de operações atómicas. As únicas operações desse tipo que suportam várias chaves e valores são operações MGET e MSET. As operações MGET retornam uma coleção de valores para uma lista especificada de chaves e as operações MSET armazenam uma coleção de valores para uma lista especificada de chaves. Se você precisar usar essas operações, os pares chave-valor referenciados pelos comandos MSET e MGET devem ser armazenados no mesmo banco de dados.

Particionando o Azure Service Fabric

O Azure Service Fabric é uma plataforma de microsserviços que fornece um tempo de execução para aplicativos distribuídos na nuvem. O Service Fabric oferece suporte a executáveis convidados .NET, serviços com e sem monitoração de estado e contêineres. Os serviços com monitoração de estado fornecem um de coleta confiável para armazenar dados persistentemente em uma coleção de chave-valor dentro do cluster do Service Fabric. Para obter mais informações sobre estratégias de particionamento de chaves em uma coleção confiável, consulte Diretrizes e recomendações para coleções confiáveis no Azure Service Fabric.

Próximos passos

• Visão geral do do Azure Service Fabric é uma introdução ao Azure Service Fabric.

• de serviços confiáveis do Partition Service Fabric fornece mais informações sobre serviços confiáveis no Azure Service Fabric.

Particionando Hubs de Eventos do Azure

de Hubs de Eventos do Azure foi projetado para streaming de dados em grande escala, e o particionamento é incorporado ao serviço para habilitar o dimensionamento horizontal. Cada consumidor lê apenas uma partição específica do fluxo de mensagens.

O publicador de eventos apenas tem conhecimento da respetiva chave de partição, não da partição onde os eventos são publicados. Este desacoplamento da chave e da partição faz com que o remetente não tenha necessidade de saber muito sobre o processamento a jusante. (Também é possível enviar eventos diretamente para uma determinada partição, mas geralmente isso não é recomendado.)

Considere a escala de longo prazo ao selecionar a contagem de partições. Depois que um hub de eventos é criado, não é possível alterar o número de partições.

Próximos passos

Para obter mais informações sobre como usar partições em Hubs de Eventos, consulte O que são Hubs de Eventos?.

Para obter considerações sobre compensações entre disponibilidade e consistência, consulte Disponibilidade e consistência em Hubs de Eventos.

Este artigo descreve algumas estratégias para particionar dados em vários armazenamentos de dados do Azure. Para obter orientações gerais sobre quando particionar dados e práticas recomendadas, consulte de particionamento de dados .

Particionando o Banco de Dados SQL do Azure

Um único banco de dados SQL tem um limite para o volume de dados que ele pode conter. A taxa de transferência é limitada por fatores de arquitetura e pelo número de conexões simultâneas suportadas.

Pools Elásticos suportam o dimensionamento horizontal para um banco de dados SQL. Usando pools elásticos, você pode particionar seus dados em fragmentos espalhados por vários bancos de dados SQL. Você também pode adicionar ou remover fragmentos à medida que o volume de dados que você precisa manipular cresce e diminui. Os pools elásticos também podem ajudar a reduzir a contenção distribuindo a carga entre bancos de dados.

Cada fragmento é implementado como um banco de dados SQL. Um fragmento pode conter mais de um conjunto de dados (chamado de deshardlet). Cada banco de dados mantém metadados que descrevem os shardlets que ele contém. Um shardlet pode ser um único item de dados ou um grupo de itens que compartilham a mesma chave de shardlet. Por exemplo, em um aplicativo multilocatário, a chave do shardlet pode ser a ID do locatário e todos os dados de um locatário podem ser mantidos no mesmo shardlet.

Os aplicativos cliente são responsáveis por associar um conjunto de dados a uma chave shardlet. Um Banco de Dados SQL separado atua como um gerenciador de mapa de estilhaços global. Esta base de dados contém uma lista de todos os fragmentos e shardlets (subfragmentos) do sistema. A aplicação conecta-se à base de dados do gestor de mapa de fragmentos para obter uma cópia do mapa de fragmentos. Ele armazena em cache o mapa de estilhaços localmente e usa o mapa para rotear solicitações de dados para o fragmento apropriado. Essa funcionalidade está oculta por trás de uma série de APIs contidas na biblioteca de cliente do Elastic Database, que está disponível para Java e .NET.

Para obter mais informações sobre pools elásticos, consulte Dimensionamento com o Banco de Dados SQL do Azure.

Para reduzir a latência e melhorar a disponibilidade, pode replicar a base de dados global do gestor de mapas de fragmentos. Com os níveis de preços Premium, você pode configurar a replicação geográfica ativa para copiar dados continuamente para bancos de dados em diferentes regiões.

Como alternativa, use de Sincronização de Dados SQL do Azure ou do Azure Data Factory para replicar o banco de dados do gerenciador de mapas de estilhaços entre regiões. Essa forma de replicação é executada periodicamente e é mais adequada se o mapa de estilhaços mudar com pouca frequência e não exigir a camada Premium.

O Elastic Database fornece dois esquemas para mapear dados para shardlets e armazená-los em fragmentos:

• Um mapa de estilhaços de lista associa uma única chave a um shardlet. Por exemplo, em um sistema multilocatário, os dados de cada locatário podem ser associados a uma chave exclusiva e armazenados em seu próprio shardlet. Para garantir o isolamento, cada subfragmento pode ser mantido dentro do seu próprio fragmento.

  

  Baixe um arquivo Visio deste diagrama.

• Um mapa de estilhaços de intervalo de associa um conjunto de valores-chave contíguos a um shardlet. Por exemplo, você pode agrupar os dados de um conjunto de locatários (cada um com sua própria chave) dentro do mesmo shardlet. Este esquema é menos dispendioso do que o primeiro, porque os inquilinos partilham armazenamento de dados, mas tem menos isolamento.

  

  Baixe um arquivo Visio deste diagrama

Um único fragmento pode conter os dados de vários sub-fragmentos. Por exemplo, é possível usar fragmentos de lista para armazenar dados de diferentes clientes não contíguos no mesmo fragmento. Você também pode misturar shardlets de alcance e shardlets de lista no mesmo fragmento, embora eles sejam abordados através de mapas diferentes. O diagrama a seguir mostra essa abordagem:

Baixe um arquivo Visio deste diagrama.

Os pools elásticos possibilitam adicionar e remover fragmentos à medida que o volume de dados diminui e cresce. Os aplicativos cliente podem criar e excluir fragmentos dinamicamente e atualizar de forma transparente o gerenciador de mapas de estilhaços. No entanto, a remoção de um fragmento é uma operação destrutiva que também requer a exclusão de todos os dados desse fragmento.

Se um aplicativo precisar dividir um fragmento em dois fragmentos separados ou combinar fragmentos, use a ferramenta de mesclagem dividida. Essa ferramenta é executada como um serviço Web do Azure e migra dados com segurança entre fragmentos.

O esquema de particionamento pode afetar significativamente o desempenho do seu sistema. Também pode afetar a taxa na qual os fragmentos devem ser adicionados ou removidos, ou que os dados devem ser reparticionados entre fragmentos. Considere os seguintes pontos:

• Agrupe dados usados juntos no mesmo fragmento e evite operações que acessam dados de vários fragmentos. Um fragmento é um banco de dados SQL por si só, e as junções entre bancos de dados devem ser executadas no lado do cliente.

  Embora o Banco de dados SQL não ofereça suporte a junções entre bancos de dados, você pode usar as ferramentas do Banco de Dados Elástico para executar consultas de vários estilhaços. Uma consulta com múltiplos shards envia consultas individuais para cada banco de dados e consolida os resultados.

• Não projete um sistema que tenha dependências entre fragmentos. Restrições de integridade referencial, gatilhos e procedimentos armazenados em um banco de dados não podem fazer referência a objetos em outro.

• Se você tiver dados de referência usados com freqüência por consultas, considere replicar esses dados entre fragmentos. Essa abordagem pode eliminar a necessidade de unir dados entre bancos de dados. Idealmente, esses dados devem ser estáticos ou lentos, para minimizar o esforço de replicação e reduzir as chances de se tornarem obsoletos.

• Os shardlets que pertencem ao mesmo mapa de estilhaços devem ter o mesmo esquema. Essa regra não é imposta pelo Banco de dados SQL, mas o gerenciamento e a consulta de dados se tornam muito complexos se cada shardlet tiver um esquema diferente. Em vez disso, crie mapas de estilhaços separados para cada esquema. Lembre-se de que os dados pertencentes a diferentes shardlets podem ser armazenados no mesmo fragmento.

• As operações transacionais são suportadas apenas para dados dentro de um fragmento, e não entre fragmentos. As transações podem abranger shardlets, desde que façam parte do mesmo fragmento. Portanto, se sua lógica de negócios precisa realizar transações, armazene os dados no mesmo fragmento ou implemente uma eventual consistência.

• Coloque fragmentos perto dos usuários que acessam os dados nesses fragmentos. Essa estratégia ajuda a reduzir a latência.

• Evite ter uma mistura de fragmentos altamente ativos e relativamente inativos. Tente distribuir a carga uniformemente pelos estilhaços. Isso pode exigir hashing das chaves de fragmentação. Se você estiver localizando geograficamente fragmentos, certifique-se de que as chaves com hash sejam mapeadas para shardlets mantidos em fragmentos armazenados perto dos usuários que acessam esses dados.

Particionando o armazenamento de tabela do Azure

O Armazenamento de Tabela do Azure é um armazenamento de chave-valor projetado em torno do particionamento. Todas as entidades são armazenadas em uma partição e as partições são gerenciadas internamente pelo armazenamento de Tabela do Azure. Cada entidade armazenada em uma tabela deve fornecer uma chave de duas partes que inclui:

• A chave de partição. Este é um valor de cadeia de caracteres que determina a partição onde o armazenamento de Tabela do Azure colocará a entidade. Todas as entidades com a mesma chave de partição são armazenadas na mesma partição.

• A chave de linha. Este é um valor de cadeia de caracteres que identifica a entidade dentro da partição. Todas as entidades dentro de uma partição são classificadas lexicamente, em ordem crescente, por esta chave. A combinação de chave de partição/chave de linha deve ser exclusiva para cada entidade e não pode exceder 1 KB de comprimento.

Se uma entidade for adicionada a uma tabela com uma chave de partição não utilizada anteriormente, o Armazenamento de Tabela do Azure criará uma nova partição para essa entidade. Outras entidades com a mesma chave de partição serão armazenadas na mesma partição.

Este mecanismo implementa efetivamente uma estratégia de expansão automática. Cada partição é armazenada no mesmo servidor em um datacenter do Azure para ajudar a garantir que as consultas que recuperam dados de uma única partição sejam executadas rapidamente.

A Microsoft publicou metas de escalabilidade para o Armazenamento do Azure. Se for provável que o seu sistema exceda esses limites, considere dividir as entidades em várias tabelas. Use o particionamento vertical para dividir os campos nos grupos com maior probabilidade de serem acessados juntos.

O diagrama a seguir mostra a estrutura lógica de uma conta de armazenamento de exemplo. A conta de armazenamento contém três tabelas: Informações do cliente, Informações do produto e Informações do pedido.

Cada tabela tem várias partições.

• Na tabela Informações do cliente, os dados são particionados de acordo com a cidade onde o cliente está localizado. A chave de linha contém o ID do cliente.
• Na tabela Informações do produto, os produtos são particionados por categoria de produto e a chave de linha contém o número do produto.
• Na tabela Informações do pedido, os pedidos são particionados por data do pedido, e a chave de linha especifica a hora em que o pedido foi recebido. Todos os dados são ordenados pela chave de linha em cada partição.

Considere os seguintes pontos ao projetar suas entidades para o armazenamento de tabela do Azure:

• Selecione uma chave de partição e uma chave de linha de acordo com a forma como os dados são acessados. Escolha uma combinação de chave de partição/chave de linha que suporte a maioria das suas consultas. As consultas mais eficientes recuperam dados especificando a chave de partição e a chave de linha. As consultas que especificam uma chave de partição e um intervalo de chaves de linha podem ser concluídas verificando uma única partição. Isso é relativamente rápido porque os dados são mantidos em ordem de chave de linha. Se as consultas não especificarem qual partição examinar, todas as partições deverão ser verificadas.

• Se uma entidade tiver uma chave natural, use-a como a chave de partição e especifique uma cadeia de caracteres vazia como a chave de linha. Se uma entidade tiver uma chave composta que consiste em duas propriedades, selecione a propriedade de alteração mais lenta como a chave de partição e a outra como a chave de linha. Se uma entidade tiver mais de duas propriedades de chave, use uma concatenação de propriedades para fornecer as chaves de partição e linha.

• Se você executar regularmente consultas que pesquisam dados usando campos diferentes das chaves de partição e linha, considere implementar o padrão Tabela de Índice ou considere usar um armazenamento de dados diferente que ofereça suporte à indexação, como o Azure Cosmos DB.

• Se você gerar chaves de partição usando uma sequência monotônica (como "0001", "0002", "0003") e cada partição contiver apenas uma quantidade limitada de dados, o armazenamento de Tabela do Azure poderá agrupar fisicamente essas partições no mesmo servidor. O Armazenamento do Azure pressupõe que o aplicativo tem maior probabilidade de executar consultas em um intervalo contíguo de partições (consultas de intervalo) e é otimizado para esse caso. No entanto, esta abordagem pode conduzir a centros de registo, uma vez que é provável que todas as inserções de novas entidades se concentrem num extremo da gama contígua. Também pode reduzir a escalabilidade. Para distribuir a carga de forma mais uniforme, considere hashing da chave de partição.

• O Armazenamento de Tabela do Azure dá suporte a operações transacionais para entidades que pertencem à mesma partição. Um aplicativo pode executar várias operações de inserção, atualização, exclusão, substituição ou mesclagem como uma unidade atômica, desde que a transação não inclua mais de 100 entidades e a carga útil da solicitação não exceda 4 MB. As operações que abrangem várias partições não são transacionais e podem exigir que você implemente uma eventual consistência. Para obter mais informações sobre armazenamento de tabelas e transações, consulte Executando transações de grupo de entidades.

• Considere a granularidade da chave de partição:

  • Usar a mesma chave de partição para cada entidade resulta em uma única partição mantida em um servidor. Isso impede que a partição seja dimensionada e concentra a carga em um único servidor. Como resultado, essa abordagem só é adequada para armazenar um pequeno número de entidades. No entanto, garante que todas as entidades possam participar em transações de grupos de entidades.

  • O uso de uma chave de partição exclusiva para cada entidade faz com que o serviço de armazenamento de tabelas crie uma partição separada para cada entidade, possivelmente resultando em um grande número de partições pequenas. Essa abordagem é mais escalável do que usar uma única chave de partição, mas as transações de grupo de entidades não são possíveis. Além disso, as consultas que buscam mais de uma entidade podem envolver a leitura de mais de um servidor. No entanto, se o aplicativo executar consultas de intervalo, usar uma sequência monotônica para as chaves de partição pode ajudar a otimizar essas consultas.

  • O compartilhamento da chave de partição em um subconjunto de entidades torna possível agrupar entidades relacionadas na mesma partição. As operações que envolvem entidades relacionadas podem ser executadas usando transações de grupo de entidades, e consultas que buscam um conjunto de entidades relacionadas podem ser satisfeitas acessando um único servidor.

Para obter mais informações, consulte guia de design de tabela do Armazenamento do Azure e Estratégia de particionamento escalável.

Particionando o Armazenamento de Blobs do Azure

O Armazenamento de Blobs do Azure torna possível armazenar grandes objetos binários. Use blobs de bloco em cenários em que você precisa carregar ou baixar grandes volumes de dados rapidamente. Use blobs de página para aplicativos que exigem acesso aleatório em vez de serial a partes dos dados.

Cada blob (bloco ou página) é mantido em um contêiner em uma conta de Armazenamento do Azure. Você pode usar contêineres para agrupar blobs relacionados que tenham os mesmos requisitos de segurança. Este agrupamento é lógico e não físico. Dentro de um contêiner, cada blob tem um nome exclusivo.

A chave de partição para um blob é nome da conta + nome do contêiner + nome do blob. A chave de partição é usada para particionar dados em intervalos e esses intervalos são balanceados de carga em todo o sistema. Os blobs podem ser distribuídos em vários servidores para expandir o acesso a eles, mas um único blob só pode ser servido por um único servidor.

Se o seu esquema de nomenclatura usa carimbos de data/hora ou identificadores numéricos, isso pode levar a um tráfego excessivo indo para uma partição, limitando o sistema de balanceamento de carga eficaz. Por exemplo, se você tiver operações diárias que usam um objeto blob com um carimbo de data/hora, como aaaa-mm-dd, todo o tráfego dessa operação irá para um único servidor de partição. Em vez disso, considere prefixar o nome com um hash de três dígitos. Para obter mais informações, consulte Convenção de Nomenclatura de Partições.

As ações de escrever um único bloco ou página são atômicas, mas as operações que abrangem blocos, páginas ou blobs não são. Se você precisar garantir a consistência ao executar operações de gravação em blocos, páginas e blobs, retire um bloqueio de gravação usando uma concessão de blob.

Particionando filas de Armazenamento do Azure

As filas de Armazenamento do Azure permitem implementar mensagens assíncronas entre processos. Uma conta de Armazenamento do Azure pode conter qualquer número de filas e cada fila pode conter qualquer número de mensagens. A única limitação é o espaço disponível na conta de armazenamento. O tamanho máximo de uma mensagem individual é de 64 KB. Se você precisar de mensagens maiores do que isso, considere usar filas do Barramento de Serviço do Azure.

Cada fila de armazenamento tem um nome exclusivo dentro da conta de armazenamento que a contém. Filas de partições do Azure com base no nome. Todas as mensagens para a mesma fila são armazenadas na mesma partição, que é controlada por um único servidor. Filas diferentes podem ser gerenciadas por servidores diferentes para ajudar a equilibrar a carga. A alocação de filas para servidores é transparente para aplicativos e usuários.

Em um aplicativo de grande escala, não use a mesma fila de armazenamento para todas as instâncias do aplicativo porque essa abordagem pode fazer com que o servidor que está hospedando a fila se torne um ponto de acesso. Em vez disso, use filas diferentes para diferentes áreas funcionais do aplicativo. As filas do Armazenamento do Azure não dão suporte a transações, portanto, direcionar mensagens para filas diferentes deve ter pouco efeito na consistência das mensagens.

Uma fila de Armazenamento do Azure pode lidar com até 2.000 mensagens por segundo. Se você precisar processar mensagens em uma taxa maior do que essa, considere a criação de várias filas. Por exemplo, em um aplicativo global, crie filas de armazenamento separadas em contas de armazenamento separadas para lidar com instâncias de aplicativos que estão sendo executadas em cada região.

Particionando o Barramento de Serviço do Azure

O Barramento de Serviço do Azure usa um agente de mensagens para manipular mensagens enviadas para uma fila ou tópico do Barramento de Serviço. Por padrão, todas as mensagens enviadas para uma fila ou tópico são tratadas pelo mesmo processo do agente de mensagens. Essa arquitetura pode colocar uma limitação na taxa de transferência geral da fila de mensagens. No entanto, você também pode particionar uma fila ou tópico quando ele é criado. Para fazer isso, defina a propriedade EnablePartitioning da fila ou descrição do tópico como true.

Uma fila ou tópico particionado é dividido em vários fragmentos, cada um dos quais é apoiado por um armazenamento de mensagens separado e um agente de mensagens. O Service Bus assume a responsabilidade de criar e gerenciar esses fragmentos. Quando um aplicativo posta uma mensagem em uma fila ou tópico particionado, o Service Bus atribui a mensagem a um fragmento para essa fila ou tópico. Quando um aplicativo recebe uma mensagem de uma fila ou assinatura, o Barramento de Serviço verifica cada fragmento em busca da próxima mensagem disponível e, em seguida, a passa para o aplicativo para processamento.

Essa estrutura ajuda a distribuir a carga entre agentes de mensagens e armazenamentos de mensagens, aumentando a escalabilidade e melhorando a disponibilidade. Se o agente de mensagens ou o armazenamento de mensagens de um fragmento estiver temporariamente indisponível, o Service Bus poderá recuperar mensagens de um dos fragmentos restantes disponíveis.

O Service Bus atribui uma mensagem a um fragmento da seguinte maneira:

• Se a mensagem pertencer a uma sessão, todas as mensagens com o mesmo valor para a propriedade SessionId serão enviadas para o mesmo fragmento.

• Se a mensagem não pertencer a uma sessão, mas o remetente tiver especificado um valor para a propriedade PartitionKey, todas as mensagens com o mesmo valor PartitionKey serão enviadas para o mesmo fragmento.

  Observação

  Se as propriedades SessionId e PartitionKey forem especificadas, elas deverão ser definidas com o mesmo valor ou a mensagem será rejeitada.

• Se as propriedades SessionId e PartitionKey de uma mensagem não forem especificadas, mas a deteção de duplicados estiver habilitada, a propriedade MessageId será usada. Todas as mensagens com o mesmo MessageId serão direcionadas para o mesmo fragmento.

• Se as mensagens não incluírem um SessionId, PartitionKey, ou propriedade MessageId, o Service Bus atribuirá mensagens a fragmentos sequencialmente. Se um fragmento não estiver disponível, o Service Bus passará para o próximo. Isso significa que uma falha temporária na infraestrutura de mensagens não faz com que a operação de envio de mensagens falhe.

Considere os seguintes pontos ao decidir se ou como particionar uma fila ou tópico de mensagens do Service Bus:

• Filas e tópicos do Barramento de Serviço são criados dentro do escopo de um namespace do Barramento de Serviço. Atualmente, o Service Bus permite até 100 filas ou tópicos particionados por namespace.

• Cada namespace do Service Bus impõe cotas aos recursos disponíveis, como o número de assinaturas por tópico, o número de solicitações simultâneas de envio e recebimento por segundo e o número máximo de conexões simultâneas que podem ser estabelecidas. Essas cotas estão documentadas em cotas do Service Bus. Se você espera exceder esses valores, crie namespaces adicionais com suas próprias filas e tópicos e espalhe o trabalho por esses namespaces. Por exemplo, em um aplicativo global, crie namespaces separados em cada região e configure instâncias de aplicativo para usar as filas e tópicos no namespace mais próximo.

• As mensagens que são enviadas como parte de uma transação têm de especificar uma chave de partição. Pode ser um SessionId, PartitionKeyou propriedade MessageId. Todas as mensagens enviadas como parte da mesma transação devem especificar a mesma chave de partição porque devem ser manipuladas pelo mesmo processo de agente de mensagens. Não é possível enviar mensagens para filas ou tópicos diferentes dentro da mesma transação.

• Filas e tópicos particionados não podem ser configurados para serem excluídos automaticamente quando ficam ociosos.

• No momento, filas e tópicos particionados não podem ser usados com o AMQP (Advanced Message Queuing Protocol) se você estiver criando soluções híbridas ou multiplataforma.

Particionando o Azure Cosmos DB

Azure Cosmos DB para NoSQL é um banco de dados NoSQL para armazenar documentos JSON. Um documento em um banco de dados do Azure Cosmos DB é uma representação serializada em JSON de um objeto ou outra parte dos dados. Nenhum esquema fixo é aplicado, exceto que cada documento deve conter uma ID exclusiva.

Os documentos estão organizados em coleções. Você pode agrupar documentos relacionados em uma coleção. Por exemplo, em um sistema que mantém postagens de blog, você pode armazenar o conteúdo de cada postagem de blog como um documento em uma coleção. Você também pode criar coleções para cada tipo de assunto. Como alternativa, em um aplicativo multilocatário, como um sistema em que diferentes autores controlam e gerenciam suas próprias postagens de blog, você pode particionar blogs por autor e criar coleções separadas para cada autor. O espaço de armazenamento alocado para coleções é elástico e pode diminuir ou crescer conforme necessário.

O Azure Cosmos DB dá suporte ao particionamento automático de dados com base em uma chave de partição definida pelo aplicativo. Um de partição lógica é uma partição que armazena todos os dados para um único valor de chave de partição. Todos os documentos que compartilham o mesmo valor para a chave de partição são colocados dentro da mesma partição lógica. O Azure Cosmos DB distribui valores de acordo com o hash da chave de partição. Uma partição lógica tem um tamanho máximo de 20 GB. Portanto, a escolha da chave de partição é uma decisão importante em tempo de design. Escolha um imóvel com uma ampla gama de valores e até mesmo padrões de acesso. Para obter mais informações, consulte particionar e dimensionar no Azure Cosmos DB.

Observação

Cada banco de dados do Azure Cosmos DB tem um nível de desempenho que determina a quantidade de recursos que recebe. Um nível de desempenho está associado a uma unidade de solicitação de (RU) limite de taxa. O limite de taxa de RU especifica o volume de recursos reservados e disponíveis para uso exclusivo por essa coleção. O custo de uma coleção depende do nível de desempenho selecionado para essa coleção. Quanto maior o nível de desempenho (e limite de taxa de RU) maior a carga. Você pode ajustar o nível de desempenho de uma coleção usando o portal do Azure. Para obter mais informações, consulte unidades de solicitação no Azure Cosmos DB.

Se o mecanismo de particionamento que o Azure Cosmos DB fornece não for suficiente, talvez seja necessário fragmentar os dados no nível do aplicativo. As coleções de documentos fornecem um mecanismo natural para particionar dados dentro de um único banco de dados. A maneira mais simples de implementar a fragmentação é criar uma coleção para cada fragmento. Os contêineres são recursos lógicos e podem abranger um ou mais servidores. Os contêineres de tamanho fixo têm um limite máximo de 20 GB e taxa de transferência de 10.000 RU/s. Os contêineres ilimitados não têm um tamanho máximo de armazenamento, mas devem especificar uma chave de partição. Com a fragmentação de aplicativos, o aplicativo cliente deve direcionar solicitações para o fragmento apropriado, geralmente implementando seu próprio mecanismo de mapeamento com base em alguns atributos dos dados que definem a chave de estilhaço.

Todos os bancos de dados são criados no contexto de uma conta de banco de dados do Azure Cosmos DB. Uma única conta pode conter vários bancos de dados e especifica em quais regiões os bancos de dados são criados. Cada conta também impõe seu próprio controle de acesso. Você pode usar contas do Azure Cosmos DB para localizar geograficamente fragmentos (coleções em bancos de dados) perto dos usuários que precisam acessá-los e impor restrições para que apenas esses usuários possam se conectar a eles.

Considere os seguintes pontos ao decidir como particionar dados com o Azure Cosmos DB para NoSQL:

• Os recursos disponíveis para um banco de dados do Azure Cosmos DB estão sujeitos às limitações de cota da conta. Cada banco de dados pode conter várias coleções, e cada coleção está associada a um nível de desempenho que rege o limite de taxa de RU (taxa de transferência reservada) para essa coleção. Para obter mais informações, consulte limites, cotas e restrições de assinaturas e serviços do Azure.

• Cada documento deve ter um atributo que possa ser usado para identificar exclusivamente esse documento dentro da coleção na qual ele é mantido. Esse atributo é diferente da chave de estilhaço, que define qual coleção contém o documento. Uma coleção pode conter um grande número de documentos. Em teoria, é limitado apenas pelo comprimento máximo do ID do documento. O ID do documento pode ter até 255 caracteres.

• Todas as operações em relação a um documento são realizadas dentro do contexto de uma transação. As transações têm como escopo a coleção na qual o documento está contido. Se uma operação falhar, o trabalho que ela executou será revertido. Embora um documento esteja sujeito a uma operação, todas as alterações feitas estão sujeitas ao isolamento no nível de instantâneo. Esse mecanismo garante que, se, por exemplo, uma solicitação para criar um novo documento falhar, outro usuário que estiver consultando o banco de dados simultaneamente não verá um documento parcial que será removido.

• As consultas de banco de dados também têm como escopo o nível de coleta. Uma única consulta pode recuperar dados de apenas uma coleção. Se você precisar recuperar dados de várias coleções, deverá consultar cada coleção individualmente e mesclar os resultados no código do aplicativo.

• Azure Cosmos DB dá suporte a itens programáveis que podem ser armazenados em uma coleção junto com documentos. Isso inclui procedimentos armazenados, funções definidas pelo usuário e gatilhos (escritos em JavaScript). Esses itens podem acessar qualquer documento dentro da mesma coleção. Além disso, esses itens são executados dentro do escopo da transação ambiente (no caso de um gatilho que é acionado como resultado de uma operação de criação, exclusão ou substituição executada em um documento) ou iniciando uma nova transação (no caso de um procedimento armazenado que é executado como resultado de uma solicitação explícita do cliente). Se o código em um item programável gerar uma exceção, a transação será revertida. Você pode usar procedimentos armazenados e gatilhos para manter a integridade e a consistência entre documentos, mas todos esses documentos devem fazer parte da mesma coleção.

• É improvável que as coleções que você pretende manter nos bancos de dados excedam os limites de taxa de transferência definidos pelos níveis de desempenho das coleções. Para obter mais informações, consulte unidades de solicitação no Azure Cosmos DB. Se você prevê atingir esses limites, considere dividir coleções entre bancos de dados em contas diferentes para reduzir a carga por coleção.

Particionando a Pesquisa de IA do Azure

A capacidade de pesquisar dados é muitas vezes o principal método de navegação e exploração que é fornecido por muitas aplicações web. Ele ajuda os usuários a encontrar recursos rapidamente (por exemplo, produtos em um aplicativo de comércio eletrônico) com base em combinações de critérios de pesquisa. O serviço AI Search fornece recursos de pesquisa de texto completo sobre conteúdo da Web e inclui recursos como digitação antecipada, consultas sugeridas com base em correspondências próximas e navegação facetada. Para obter mais informações, consulte O que é AI Search?.

O AI Search armazena conteúdo pesquisável como documentos JSON em um banco de dados. Você define índices que especificam os campos pesquisáveis nesses documentos e fornece essas definições para o AI Search. Quando um usuário envia uma solicitação de pesquisa, o AI Search usa os índices apropriados para encontrar itens correspondentes.

Para reduzir a contenção, o armazenamento usado pelo AI Search pode ser dividido em 1, 2, 3, 4, 6 ou 12 partições, e cada partição pode ser replicada até 6 vezes. O produto do número de partições multiplicado pelo número de réplicas é chamado de unidade de pesquisa (SU). Uma única instância do AI Search pode conter um máximo de 36 SUs (um banco de dados com 12 partições suporta apenas um máximo de 3 réplicas).

Você é cobrado por cada SU alocado ao seu serviço. À medida que o volume de conteúdo pesquisável aumenta ou a taxa de solicitações de pesquisa aumenta, você pode adicionar SUs a uma instância existente do AI Search para lidar com a carga extra. O próprio AI Search distribui os documentos uniformemente pelas partições. Nenhuma estratégia de particionamento manual é suportada no momento.

Cada partição pode conter um máximo de 15 milhões de documentos ou ocupar 300 GB de espaço de armazenamento (o que for menor). Você pode criar até 50 índices. O desempenho do serviço varia e depende da complexidade dos documentos, dos índices disponíveis e dos efeitos da latência da rede. Em média, uma única réplica (1 SU) deve ser capaz de lidar com 15 consultas por segundo (QPS), embora recomendemos a realização de benchmarking com seus próprios dados para obter uma medida mais precisa de taxa de transferência. Para obter mais informações, consulte Limites de serviço no AI Search.

Observação

Você pode armazenar um conjunto limitado de tipos de dados em documentos pesquisáveis, incluindo cadeias de caracteres, booleanos, dados numéricos, dados de data/hora e alguns dados geográficos. Para obter mais informações, consulte a página Tipos de dados suportados (AI Search) no site da Microsoft.

Você tem controle limitado sobre como o AI Search particiona dados para cada instância do serviço. No entanto, em um ambiente global, você poderá melhorar o desempenho e reduzir ainda mais a latência e a contenção particionando o próprio serviço usando uma das seguintes estratégias:

• Crie uma instância do AI Search em cada região geográfica e garanta que os aplicativos cliente sejam direcionados para a instância disponível mais próxima. Essa estratégia exige que todas as atualizações de conteúdo pesquisável sejam replicadas em tempo hábil em todas as instâncias do serviço.

• Crie duas camadas de Pesquisa de IA:

  • Um serviço local em cada região que contém os dados acessados com mais frequência pelos usuários nessa região. Os usuários podem direcionar solicitações aqui para obter resultados rápidos, mas limitados.
  • Um serviço global que engloba todos os dados. Os usuários podem direcionar solicitações aqui para obter resultados mais lentos, mas mais completos.

Essa abordagem é mais adequada quando há uma variação regional significativa nos dados que estão sendo pesquisados.

Particionando o Cache do Azure para Redis

O Cache Redis do Azure fornece um serviço de cache compartilhado na nuvem baseado no armazenamento de dados chave-valor do Redis. Como o próprio nome indica, o Cache Redis do Azure destina-se a ser uma solução de cache. Use-o apenas para armazenar dados transitórios e não como um armazenamento de dados permanente. Os aplicativos que usam o Cache Redis do Azure devem poder continuar funcionando se o cache não estiver disponível. O Cache Redis do Azure dá suporte à replicação primária/secundária para fornecer alta disponibilidade, mas atualmente limita o tamanho máximo do cache a 53 GB. Se precisar de mais espaço do que isso, você deve criar caches adicionais. Para obter mais informações, veja Azure Cache for Redis (Cache do Azure para Redis).

O particionamento de um armazenamento de dados Redis envolve a divisão dos dados entre instâncias do serviço Redis. Cada instância constitui uma única partição. O Cache do Azure para Redis abstrai os serviços do Redis por trás de uma fachada e não os expõe diretamente. A maneira mais simples de implementar o particionamento é criar várias instâncias do Cache do Azure para Redis e distribuir os dados entre elas.

Você pode associar cada item de dados a um identificador (uma chave de partição) que especifica qual cache armazena o item de dados. A lógica do aplicativo cliente pode usar esse identificador para rotear solicitações para a partição apropriada. Esse esquema é muito simples, mas se o esquema de particionamento for alterado (por exemplo, se instâncias adicionais do Cache do Azure para Redis forem criadas), os aplicativos cliente talvez precisem ser reconfigurados.

O Redis nativo (não o Cache do Azure para Redis) dá suporte ao particionamento do lado do servidor com base no cluster Redis. Nessa abordagem, você pode dividir os dados uniformemente entre servidores usando um mecanismo de hash. Cada servidor Redis armazena metadados que descrevem o intervalo de chaves hash que a partição mantém e também contém informações sobre quais chaves hash estão localizadas nas partições em outros servidores.

Os aplicativos cliente simplesmente enviam solicitações para qualquer um dos servidores Redis participantes (provavelmente o mais próximo). O servidor Redis examina a solicitação do cliente. Se puder ser resolvido localmente, ele executa a operação solicitada. Caso contrário, ele encaminha a solicitação para o servidor apropriado.

Esse modelo é implementado usando o cluster Redis e é descrito com mais detalhes na página do tutorial do cluster do Redis no site do Redis. O clustering Redis é transparente para aplicativos cliente. Servidores Redis adicionais podem ser adicionados ao cluster (e os dados podem ser reparticionados) sem exigir que você reconfigure os clientes.

Importante

Atualmente, o Cache do Azure para Redis dá suporte ao clustering Redis somente na camada Premium.

A página Particionamento: como dividir dados entre várias instâncias do Redis no site do Redis fornece mais informações sobre como implementar o particionamento com o Redis. O restante desta seção pressupõe que você esteja implementando particionamento do lado do cliente ou assistido por proxy.

Considere os seguintes pontos ao decidir como particionar dados com o Cache do Azure para Redis:

• O Cache Redis do Azure não se destina a atuar como um armazenamento de dados permanente, portanto, seja qual for o esquema de particionamento implementado, o código do aplicativo deve ser capaz de recuperar dados de um local que não seja o cache.

• Os dados que são frequentemente acessados juntos devem ser mantidos na mesma partição. O Redis é um poderoso armazenamento de chave-valor que fornece vários mecanismos altamente otimizados para a estruturação de dados. Estes mecanismos podem ser um dos seguintes:

  • Strings simples (dados binários de até 512 MB de comprimento)
  • Agregar tipos, como listas (que podem atuar como filas e pilhas)
  • Conjuntos (ordenados e não ordenados)
  • Hashes (que podem agrupar campos relacionados, como os itens que representam os campos em um objeto)

• Os tipos agregados permitem associar muitos valores relacionados à mesma chave. Uma chave Redis identifica uma lista, um conjunto ou um hash em vez dos itens de dados que ela contém. Esses tipos estão todos disponíveis com o Cache Redis do Azure e são descritos pela página Tipos de dados no site do Redis. Por exemplo, em parte de um sistema de comércio eletrônico que rastreia os pedidos que são feitos pelos clientes, os detalhes de cada cliente podem ser armazenados em um hash Redis que é digitado usando o ID do cliente. Cada hash pode conter uma coleção de IDs de ordem para o cliente. Um conjunto Redis separado pode conter as ordens, novamente estruturadas como hashes, e digitadas usando o ID da ordem. A Figura 8 mostra esta estrutura. Observe que o Redis não implementa nenhuma forma de integridade referencial, portanto, é responsabilidade do desenvolvedor manter as relações entre clientes e pedidos.

Figura 8. Estrutura sugerida no armazenamento Redis para registro de pedidos de clientes e seus detalhes.

Observação

No Redis, todas as chaves são valores de dados binários (como cadeias de caracteres Redis) e podem conter até 512 MB de dados. Em teoria, uma chave pode conter quase qualquer informação. No entanto, recomendamos a adoção de uma convenção de nomenclatura consistente para chaves que seja descritiva do tipo de dados e que identifique a entidade, mas não seja excessivamente longa. Uma abordagem comum é usar chaves do formulário "entity_type:ID". Por exemplo, você pode usar "customer:99" para indicar a chave de um cliente com o ID 99.

• Você pode implementar o particionamento vertical armazenando informações relacionadas em diferentes agregações no mesmo banco de dados. Por exemplo, em um aplicativo de comércio eletrônico, você pode armazenar informações comumente acessadas sobre produtos em um hash Redis e informações detalhadas usadas com menos frequência em outro. Ambos os hashes podem usar o mesmo ID do produto como parte da chave. Por exemplo, você pode usar "product: nn" (onde nn é o ID do produto) para as informações do produto e "product_details: nn" para os dados detalhados. Essa estratégia pode ajudar a reduzir o volume de dados que a maioria das consultas provavelmente recuperará.

• Você pode reparticionar um armazenamento de dados Redis, mas lembre-se de que é uma tarefa complexa e demorada. O clustering Redis pode reparticionar dados automaticamente, mas esse recurso não está disponível com o Cache do Azure para Redis. Portanto, ao projetar seu esquema de particionamento, tente deixar espaço livre suficiente em cada partição para permitir o crescimento esperado de dados ao longo do tempo. No entanto, lembre-se de que o Cache Redis do Azure se destina a armazenar dados em cache temporariamente e que os dados mantidos no cache podem ter um tempo de vida limitado especificado como um valor TTL (time-to-live). Para dados relativamente voláteis, o TTL pode ser curto, mas para dados estáticos o TTL pode ser muito mais longo. Evite armazenar grandes quantidades de dados de longa duração no cache se o volume desses dados provavelmente preencher o cache. Você pode especificar uma política de remoção que faça com que o Cache Redis do Azure remova dados se o espaço for escasso.

  Observação

  Ao usar o Cache do Azure para Redis, você especifica o tamanho máximo do cache (de 250 MB a 53 GB) selecionando o nível de preço apropriado. No entanto, depois que um Cache Redis do Azure tiver sido criado, você não poderá aumentar (ou diminuir) seu tamanho.

• Os lotes e transações do Redis não podem abranger várias conexões, portanto, todos os dados afetados por um lote ou transação devem ser mantidos no mesmo banco de dados (fragmento).

  Observação

  Uma sequência de operações numa transação Redis não é necessariamente atómica. Os comandos que compõem uma transação são verificados e enfileirados antes de serem executados. Se ocorrer um erro durante essa fase, toda a fila será descartada. No entanto, depois que a transação for enviada com êxito, os comandos enfileirados serão executados em sequência. Se algum comando falhar, apenas esse comando para de ser executado. Todos os comandos anteriores e subsequentes na fila são executados. Para obter mais informações, acesse a página Transações no site do Redis.

• O Redis suporta um número limitado de operações atómicas. As únicas operações desse tipo que suportam várias chaves e valores são operações MGET e MSET. As operações MGET retornam uma coleção de valores para uma lista especificada de chaves e as operações MSET armazenam uma coleção de valores para uma lista especificada de chaves. Se você precisar usar essas operações, os pares chave-valor referenciados pelos comandos MSET e MGET devem ser armazenados no mesmo banco de dados.

Particionando o Azure Service Fabric

O Azure Service Fabric é uma plataforma de microsserviços que fornece um tempo de execução para aplicativos distribuídos na nuvem. O Service Fabric oferece suporte a executáveis convidados .NET, serviços com e sem monitoração de estado e contêineres. Os serviços com monitoração de estado fornecem um de coleta confiável para armazenar dados persistentemente em uma coleção de chave-valor dentro do cluster do Service Fabric. Para obter mais informações sobre estratégias de particionamento de chaves em uma coleção confiável, consulte Diretrizes e recomendações para coleções confiáveis no Azure Service Fabric.

Próximos passos

• Visão geral do do Azure Service Fabric é uma introdução ao Azure Service Fabric.

• de serviços confiáveis do Partition Service Fabric fornece mais informações sobre serviços confiáveis no Azure Service Fabric.

Particionando Hubs de Eventos do Azure

de Hubs de Eventos do Azure foi projetado para streaming de dados em grande escala, e o particionamento é incorporado ao serviço para habilitar o dimensionamento horizontal. Cada consumidor lê apenas uma partição específica do fluxo de mensagens.

O publicador de eventos apenas tem conhecimento da respetiva chave de partição, não da partição onde os eventos são publicados. Este desacoplamento da chave e da partição faz com que o remetente não tenha necessidade de saber muito sobre o processamento a jusante. (Também é possível enviar eventos diretamente para uma determinada partição, mas geralmente isso não é recomendado.)

Considere a escala de longo prazo ao selecionar a contagem de partições. Depois que um hub de eventos é criado, não é possível alterar o número de partições.

Próximos passos

Para obter mais informações sobre como usar partições em Hubs de Eventos, consulte O que são Hubs de Eventos?.

Para obter considerações sobre compensações entre disponibilidade e consistência, consulte Disponibilidade e consistência em Hubs de Eventos.