Escolhendo uma chave de fragmentação: cardinalidade, frequência e monotonicidade

A chave de fragmentação é imutável depois de definida e não pode ser alterada sem desfazer a fragmentação e fragmentar novamente toda a coleção — uma operação cara e perturbadora. Escolher a chave de fragmentação errada causa fragmentos sobrecarregados, roteamento inadequado de consultas e desperdício de hardware. Você deve avaliar as candidatas em três dimensões: cardinalidade, frequência e monotonicidade.

Cardinalidade é o número de valores distintos que a chave de fragmentação pode assumir. Uma cardinalidade alta (por exemplo, userId, email, orderId) é positiva — ela oferece ao MongoDB muitos limites possíveis para os blocos e permite que o balanceador distribua os dados com precisão. Uma cardinalidade baixa (por exemplo, status: 'active' | 'inactive' ou country com 50 valores) cria blocos gigantes que não podem ser divididos nem migrados.

Frequência mede quantos documentos compartilham cada valor da chave de fragmentação. Mesmo chaves com cardinalidade alta podem ser problemáticas se um pequeno número de valores aparecer na grande maioria dos documentos. Por exemplo, um campo countryCode pode ter 200 valores distintos, mas 90% dos usuários podem ser de um único país — criando um bloco enorme e sobrecarregado que não pode ser dividido.

Monotonicidade indica se os valores da chave de fragmentação sempre aumentam (ou diminuem) ao longo do tempo. Campos como os carimbos de data e hora de createdAt e ObjectId (_id) são monotonicamente crescentes. Isso é problemático porque todas as novas inserções chegam ao mesmo bloco de valor máximo em um fragmento, criando um ponto de sobrecarga de gravação mesmo quando os dados estão historicamente distribuídos de maneira uniforme.

A chave de fragmentação ideal tem: alta cardinalidade — milhares ou milhões de valores distintos. baixa concentração de frequência — nenhum valor individual predomina. distribuição não monotônica — os valores não aumentam sempre, ou você usa fragmentação por hash. alinhamento com as consultas — corresponde aos filtros das consultas mais frequentes e sensíveis à latência para permitir o roteamento direcionado.

Uma chave de fragmentação composta combina dois campos para obter uma distribuição melhor. Por exemplo, { tenantId: 1, createdAt: 1 } distribui os dados entre os locatários (alta cardinalidade) e permite consultas por intervalo dentro de cada locatário. O primeiro campo determina a distribuição geral; o segundo permite uma divisão mais detalhada. Chaves compostas podem atender a predicados de consultas com vários campos como consultas direcionadas.

Uma chave de fragmentação por hash aplica uma função de hash ao valor do campo antes de mapeá-lo para um bloco. Isso converte chaves monotônicas (como ObjectId) em valores de hash distribuídos aleatoriamente, eliminando pontos de sobrecarga de gravação. A desvantagem é que as consultas por intervalo no campo se tornam consultas distribuídas, pois os valores de hash não são armazenados na ordem original.

O MongoDB permite a fragmentação por zonas, na qual você atribui intervalos da chave de fragmentação a fragmentos específicos usando etiquetas (zonas). Isso é útil para requisitos de residência de dados: os dados de usuários europeus podem ser fixados em fragmentos da região EU, e os dados dos US em fragmentos dos US. A fragmentação por zonas exige uma chave de fragmentação composta, com um prefixo de região como primeiro componente.

Ao avaliar candidatas a chave de fragmentação: 1) Execute uma verificação de cardinalidade — db.col.distinct('field').length deve resultar em milhares ou mais. 2) Verifique a distribuição de frequência com uma agregação. 3) Determine se o campo é monotônico (carimbos de data e hora, incremento automático). 4) Analise suas 5 consultas mais frequentes — o campo candidato aparece no filtro delas?

Um padrão comum e seguro para muitas cargas de trabalho é usar { _id: 'hashed' }. Os valores de ObjectId do MongoDB, embora monotônicos, tornam-se distribuídos uniformemente depois do hashing. Isso proporciona uma distribuição uniforme das gravações desde o início. A principal limitação é que qualquer consulta por intervalo em _id se torna uma consulta distribuída — mas, para a maioria das cargas de trabalho de busca no nível do documento, isso é aceitável.

O MongoDB Atlas oferece um Consultor de chaves de fragmentação no Consultor de desempenho, que analisa seus padrões de consulta e recomenda chaves de fragmentação com base no uso real. Ele pode detectar chaves monotônicas, concentração de frequência e índices ausentes. Usar o consultor antes da fragmentação é especialmente útil para cargas de trabalho de produção cujos padrões de consulta já estão estabelecidos.

Nesta lição, você aprendeu que: uma boa chave de fragmentação tem alta cardinalidade, baixa concentração de frequência e evita valores monotônicos, as chaves de fragmentação compostas combinam cobertura para distribuição e direcionamento de consultas e a fragmentação por hash neutraliza pontos de sobrecarga causados por chaves monotônicas, ao custo da eficiência das consultas por intervalo. A seguir, compararemos em detalhes as estratégias de fragmentação por intervalo e por hash.