O problema da partição quente e por que sharding não te salva

Sharding é vendido como a resposta para escala: divida os dados em N nós, ganhe N vezes a capacidade. O discurso de venda assume em silêncio que o tráfego está distribuído de forma uniforme entre as chaves. Quase nunca está. E quando não está, o nó que segura a chave quente é o seu sistema inteiro, não importa quantos outros fiquem ociosos ao lado.

Esse é o problema da partição quente. Não é exótico. Eu diria que é o motivo mais comum para um banco "horizontalmente escalável" cair com um décimo da capacidade teórica.

Como as chaves esquentam

O desequilíbrio vem de algumas formas recorrentes. Um tenant grande: um SaaS com mil clientes em que um cliente gera quarenta por cento das escritas. Se a chave de shard é o id do tenant, esse tenant mora num shard só, e esse shard é sempre o que está pegando fogo.

Um post viral: uma funcionalidade social com chave por id de post. A maioria dos posts recebe dez leituras. Um recebe dez milhões em uma hora. Todas as dez milhões caem na mesma partição.

Timestamp como chave: o erro clássico. Se a chave de partição é a hora atual, ou um id auto-incremental, toda escrita do sistema vai para a partição mais nova. Você pagou por vinte nós e está usando um, e amanhã vai estar usando outro.

Repare que o problema em cada caso é uma única chave, ou um conjunto pequeno de chaves, que é quente por conta própria. Adicionar shards não faz nada por isso. Uma chave mora em exatamente um lugar. Dobrar o cluster reduz pela metade a carga dos shards frios, que estavam bem, e deixa o shard quente exatamente tão quente quanto estava.

Por que a solução nunca é "mais shards"

As pessoas tentam mesmo assim, porque é a alavanca que o fornecedor entregou. O resultado é uma conta maior e o mesmo alerta. As únicas saídas envolvem mudar o que a chave significa, mudar de onde a leitura vem, ou mudar quando a escrita pousa.

As mitigações de verdade

Salgue a chave. Em vez de uma partição para o post 123, use post 123 com um sufixo de 0 a 15, escolhido na hora da escrita. As escritas se espalham por dezesseis partições. As leituras precisam consultar as dezesseis e juntar, então isso troca custo de leitura por distribuição de escrita. Funciona bem para contadores, logs e dados de append onde as leituras já são agregadas.

Divida a entidade quente. Um tenant grande demais para um shard não deveria ser uma entidade só. Divida por tenant mais região, tenant mais mês, tenant mais workspace, qualquer subfronteira que o domínio já tenha. A divisão precisa ser algo que as queries naturalmente incluam, senão você só mudou o problema de scatter-gather de lugar.

Cacheie a leitura quente. O post viral não precisa de dez milhões de leituras no banco. Precisa de uma leitura por segundo, guardada em memória, servida dez milhões de vezes. Uma chave quente do lado da leitura é um problema de cache, e um cache com coalescência de requisições resolve quase por completo. Só cuidado com a expiração: o stampede depois que uma chave quente expira é a mesma tempestade que você estava evitando.

Agregue escritas atrás de um buffer. Se a chave quente é um contador, curtidas, visualizações, o estoque de uma promoção relâmpago, não escreva cada incremento na linha. Acumule em memória ou numa fila e descarregue a cada segundo. Mil incrementos viram uma escrita. Você perde um segundo de frescor e ganha três ordens de grandeza de folga. Para estoque isso exige cuidado, porque vender a mais tem custo real, então combine o agregado com uma etapa de reserva rígida para as últimas unidades.

Separe a baleia. Às vezes a resposta honesta é que um tenant é outra carga de trabalho. Dê a ele seu próprio banco, seu próprio cluster, sua própria linha de custo. Multi-tenancy é uma decisão de compartilhamento, e o maior cliente costuma ser justamente aquele com quem você não deveria compartilhar.

O que olhar esta semana

Puxe as métricas por partição do que quer que você rode. Se não conseguir, essa é a primeira descoberta. Se conseguir, ordene por escritas. Se a partição do topo faz mais do que algumas vezes a mediana, você já tem uma partição quente. Só ainda não teve o dia de tráfego que transforma isso em incidente.