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 em contêineres que, por sua vez, são distribuídos entre partições físicas e em que 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 dá suporte a 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 entre as partições físicas disponíveis, novamente usando o valor da chave de partição para isso de maneira previsível.
Nesta unidade, você saberá mais sobre as partições lógicas e como evitar partições frequentes. Essas informações nos ajudarão a escolher a chave de partição apropriada para os dados do cliente no cenário.
No Azure Cosmos DB, você aumenta o armazenamento e a taxa de transferência adicionando partições físicas para acessar e armazenar dados. O tamanho máximo de armazenamento de uma partição física é de 50 GB. 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 como pertencendo à mesma partição lógica e sejam roteados para e armazenados em 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 em uma só partição física, e o contêiner pode ter um número ilimitado de partições lógicas. 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. O uso de uma chave de partição com alta cardinalidade permite evitar esse limite de 20 GB, difundindo seus dados em um número maior de partições lógicas.
Uma chave de partição fornece um modo de encaminhar os dados para uma partição lógica. É uma propriedade que existe em cada documento no contêiner que encaminha seus dados. Um contêiner é outra abstração, além de ser para todos os dados armazenados com a mesma chave de partição. A chave de partição é definida quando um contêiner é criado.
No exemplo a seguir, o contêiner tem uma chave de partição de /username.
Evitar partições quentes
Ao modelar dados para o Azure Cosmos DB, é extremamente importante que a chave de partição que você escolher resulte em uma distribuição uniforme de dados e solicitações entre as partições físicas no contêiner. Isso é especialmente verdadeiro quando os contêineres aumentam e têm um número cada vez maior de partições físicas.
Se você não testar o design do banco de dados sob carga durante o desenvolvimento, uma escolha ruim para a chave de partição poderá não ser revelada até o aplicativo estar em produção e dados significativos já terem sido gravados.
Quando os dados não são particionados corretamente, isso pode resultar em partições frequentes. As partições quentes impedem o dimensionamento da carga de trabalho do aplicativo e podem ocorrer no armazenamento e na taxa de transferência.
Partições quentes de armazenamento
Uma partição quente no armazenamento ocorre quando você tem uma chave de partição que resulta em padrões de armazenamento altamente assimétricos. Por 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 da respectiva partição. Nesse cenário, precisamos selecionar outra chave de partição que distribuirá o armazenamento entre mais partições lógicas.
Partições quentes de taxa de transferência
A taxa de transferência pode ser afetada por partições frequentes quando a maioria ou todas as solicitações seguem para a mesma partição lógica.
É importante entender os padrões de acesso do aplicativo a fim de garantir que as solicitações sejam distribuídas da maneira 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 de modo uniforme em todas as partições físicas em um contêiner.
Por exemplo, se você tiver um contêiner com 30.000 mil RU/s, essa carga de trabalho será distribuída entre as três partições físicas para os mesmos seis locatários mencionados anteriormente. Portanto, cada partição física obtém 10 mil RU/s. Se o locatário D consumir todas as suas 10 mil RU/s, ele sofrerá limitação de taxa porque não poderá consumir a taxa de transferência alocada para as outras partições. Isso resulta em baixo desempenho para o locatário C e D e deixa a capacidade de computação não utilizada nas outras partições físicas e nos locatários restantes. Por fim, 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 de modo uniforme, o banco de dados pode crescer de uma forma que utilize o armazenamento e a taxa de transferência por completo. O resultado será o melhor desempenho possível e a maior eficiência. Em resumo, o design do banco de dados será escalado.
Considere leituras versus gravações
Ao escolher uma chave de partição, você também precisa considerar se os dados apresentam uso intenso de leitura ou de gravação. Você deve buscar distribuir solicitações com gravação intensa com uma chave de partição que tenha alta cardinalidade.
Para cargas de trabalho de leitura intensa, você deve garantir que as consultas sejam processadas por uma ou um número limitado de partições físicas incluindo uma cláusula WHERE 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 é intensa em gravação e leitura, há uma solução. Exploraremos isso no próximo módulo.
A ilustração a seguir mostra um contêiner particionado por nome de usuário. Essa consulta atingirá apenas uma única partição lógica, portanto, o desempenho sempre será bom.
Uma consulta filtrada em outra propriedade, como favoriteColor, fará o fan-out para todas as partições no contêiner. Isso também é conhecido como uma consulta entre partições. Essa consulta terá o desempenho esperado quando o contêiner for pequeno e ocupar apenas uma partição. No entanto, à medida que o contêiner cresce e há um número cada vez maior de partições físicas, essa consulta ficará mais lenta e mais dispendiosa, pois precisará verificar cada partição para obter os resultados se os dados de contêineres de partição física relacionados à consulta ou não.
Escolher uma chave de partição para clientes
Agora que você compreende o particionamento no Azure Cosmos DB, podemos decidir qual chave de partição usaremos para os dados do cliente. Como abordamos anteriormente, realizamos três operações nos clientes: criar um cliente, atualizar um cliente e recuperar um cliente. Neste caso, vamos recuperar o cliente pela ID. Como essa operação será a mais chamada, fará sentido tornar a ID do cliente a chave de partição para o contêiner.
Neste ponto, talvez você se preocupe porque tornar a ID a chave de partição significa que teremos o mesmo número de partições lógicas quanto há de clientes, com cada partição lógica contendo apenas um documento individual. Milhões de clientes resultarão em milhões de partições lógicas.
Mas isso é perfeitamente aceitável. As partições lógicas são um conceito virtual, e não há limite para o número de partições lógicas que você pode ter. O Azure Cosmos DB colocará várias partições lógicas na mesma partição física. Conforme as partições lógicas crescem em número ou tamanho, o Cosmos DB as move para novas partições físicas, quando necessário.