Escolher uma chave de partição
Lembre-se de que os dados em documentos JSON são armazenados em bancos de dados do Azure Cosmos DB dentro de contêineres que, por sua vez, são distribuídos entre partições físicas e onde os dados são roteados para a partição física apropriada com base no valor de uma chave de partição.
A chave de partição é uma propriedade de documento necessária que garante que documentos com o mesmo valor de chave de partição sejam roteados e armazenados em uma partição física específica. Uma partição física suporta uma quantidade máxima fixa de armazenamento e taxa de transferência (RU/s). O Azure Cosmos DB distribui automaticamente as partições lógicas pelas partições físicas disponíveis, novamente usando o valor da chave de partição para fazer isso de forma previsível.
Nesta unidade, você aprenderá mais sobre partições lógicas e como evitar partições quentes. Essas informações nos ajudarão a escolher a chave de partição apropriada para os dados do cliente em nosso cenário.
No Azure Cosmos DB, você aumenta o armazenamento e a taxa de transferência adicionando mais partições físicas para acessar e armazenar dados. O tamanho máximo de armazenamento de uma partição física é de 50 GB e a taxa de transferência máxima é de 10.000 RU/s.
Partições lógicas no Azure Cosmos DB
A chave de partição garante que documentos com o mesmo valor de chave de partição sejam considerados pertencentes à mesma partição lógica e sejam roteados e armazenados dentro de uma partição física específica. O conceito de uma partição lógica permite o agrupamento de documentos com o mesmo valor de chave de partição. Várias partições lógicas podem ser armazenadas dentro de uma única partição física e o contêiner pode ter um número ilimitado de partições lógicas. As partições lógicas individuais são movidas para novas partições físicas como uma unidade à medida que o contêiner cresce. Mover partições lógicas como uma unidade garante que todos os documentos dentro dela residam na mesma partição física. O tamanho máximo de uma partição lógica é de 20 GB. Usar uma chave de partição com alta cardinalidade permite que você evite esse limite de 20 GB espalhando seus dados por um número maior de partições lógicas.
Uma chave de partição fornece uma maneira de rotear dados para uma partição lógica. É uma propriedade que existe em cada documento em seu contêiner que roteia seus dados. Um contêiner é outra abstração e é para todos os dados armazenados com a mesma chave de partição. A chave de partição é definida quando você cria um contêiner.
No exemplo a seguir, o contêiner tem uma chave de partição de /username.
Evite partições quentes
Quando você está modelando dados para o Azure Cosmos DB, é extremamente importante que a chave de partição escolhida resulte em uma distribuição uniforme de dados e solicitações entre partições físicas em seu contêiner. Isso é especialmente verdadeiro quando os contêineres crescem e têm um número crescente de partições físicas.
Se você não testar o design do banco de dados sob carga durante o desenvolvimento, uma escolha incorreta para a chave de partição pode não ser revelada até que o aplicativo esteja em produção e dados significativos já tenham sido gravados.
Quando os dados não são particionados corretamente, isso pode resultar em partições quentes. As partições ativas impedem que a carga de trabalho do aplicativo seja dimensionada e podem ocorrer tanto no armazenamento quanto na taxa de transferência.
Partições quentes de armazenamento
Uma partição ativa no armazenamento ocorre quando você tem uma chave de partição que resulta em padrões de armazenamento altamente assimétricos. Como exemplo, considere um aplicativo multilocatário que usa TenantId como sua chave de partição com seis locatários: A a F. Os locatários B, C, E e F são muito pequenos, o locatário D tem um pouco mais de dados. No entanto, o locatário A é enorme e atinge rapidamente o limite de 20 GB para sua partição. Nesse cenário, precisamos selecionar uma chave de partição diferente que espalhará o armazenamento por mais partições lógicas.
Partições quentes de taxa de transferência
A taxa de transferência pode sofrer com partições quentes quando a maioria ou todas as solicitações vão para a mesma partição lógica.
É importante entender os padrões de acesso para seu aplicativo para garantir que as solicitações sejam distribuídas da forma mais uniforme possível entre os valores de chave de partição. Quando a taxa de transferência é provisionada para um contêiner no Azure Cosmos DB, ela é alocada uniformemente em todas as partições físicas dentro de um contêiner.
Por exemplo, se você tiver um contêiner com 30.000 RU/s, essa carga de trabalho será distribuída pelas três partições físicas para os mesmos seis locatários mencionados anteriormente. Assim, cada partição física recebe 10.000 RU/s. Se o locatário D consumir todos os seus 10.000 RU/s, a taxa será limitada porque não pode consumir a taxa de transferência alocada para as outras partições. Isso resulta em um desempenho ruim para o locatário C e D e deixando a capacidade de computação não utilizada nas outras partições físicas e nos locatários restantes. Em última análise, essa chave de partição resulta em um design de banco de dados em que a carga de trabalho do aplicativo não pode ser dimensionada.
Quando os dados e as solicitações são distribuídos uniformemente, o banco de dados pode crescer de uma forma que utiliza totalmente o armazenamento e a taxa de transferência. O resultado será o melhor desempenho possível e a mais alta eficiência. Em resumo, o design do banco de dados será dimensionado.
Considerar leituras versus gravações
Ao escolher uma chave de partição, você também precisa considerar se os dados são de leitura pesada ou gravação pesada. Você deve procurar distribuir solicitações de gravação pesada com uma chave de partição que tenha alta cardinalidade.
Para cargas de trabalho de leitura pesada, você deve garantir que as consultas sejam processadas por uma ou um número limitado de partições físicas, incluindo uma WHERE cláusula com um filtro de igualdade na chave de partição ou um operador IN em um subconjunto de valores de chave de partição em suas consultas.
Em cenários em que a carga de trabalho do aplicativo é pesada em termos de gravação e leitura, há uma solução. Vamos explorar isso no próximo módulo.
A ilustração a seguir mostra um contêiner particionado por nome de usuário. Esta consulta atingirá apenas uma única partição lógica, pelo que o seu desempenho será sempre bom.
Uma consulta que filtra em uma propriedade diferente, como favoriteColor, seria "distribuída" para todas as partições no contêiner. Isso também é conhecido como uma consulta entre partições. Essa consulta será executada conforme o esperado quando o contêiner for pequeno e ocupar apenas uma única partição. No entanto, à medida que o contêiner cresce e há um número crescente de partições físicas, essa consulta se tornará mais lenta e mais cara, pois precisará verificar cada partição para obter os resultados se a partição física contém dados relacionados à consulta ou não.
Escolha uma chave de partição para os clientes
Agora que você entende o particionamento no Azure Cosmos DB, podemos decidir sobre uma chave de partição para os dados de nossos clientes. Como abordamos anteriormente, realizamos três operações nos clientes: criar um cliente, atualizar um cliente e recuperar um cliente. Neste caso, recuperaremos o cliente pelo seu ID. Como essa operação será a mais chamada, faz sentido tornar o ID do cliente a chave de partição para o contêiner.
Você pode se preocupar aqui que tornar o ID a chave de partição significa que teremos tantas partições lógicas quanto houver clientes, com cada partição lógica contendo apenas um único documento. Milhões de clientes resultariam em milhões de partições lógicas.
Mas tudo bem! As partições lógicas são um conceito virtual, e não há limite para quantas partições lógicas você pode ter. O Azure Cosmos DB colocará várias partições lógicas na mesma partição física. À medida que as partições lógicas crescem em número ou em tamanho, o Cosmos DB as moverá para novas partições físicas quando necessário.