Antes de comprar RAM, descubra o que cada ponto do hash está comprando

A Cloudflare economizou mais de 100 TB de memória ao otimizar os anéis de consistent hashing usados por seu roteador interno de backends, segundo a reportagem do InfoQ.[13] O trabalho revisou tanto o número de pontos necessários quanto o tamanho da representação de cada ponto.[13]

A lição para desenvolvimento não é perseguir um número gigantesco de economia. É perguntar qual propriedade um parâmetro preserva e quanto custa aproximá-la um pouco mais do ideal. Um valor histórico pode continuar sendo multiplicado muito depois de alguém esquecer por que ele foi escolhido.

O que muda para quem desenvolve

Na análise relatada, os últimos 90 mil hashes melhoravam o erro de distribuição em apenas 0,7%, e a equipe conseguiu reduzir em cerca de 90% a quantidade de hashes por servidor dentro do objetivo operacional.[13] A representação de dados em Rust também passou de oito para seis bytes em uma estrutura relevante.[13]

Minha leitura: há duas perguntas independentes. A primeira é se a estrutura precisa conter tantos elementos. A segunda é se cada elemento ocupa o espaço necessário. Otimizar apenas o layout pode manter uma quantidade desnecessária; reduzir elementos sem validar a distribuição pode trocar memória por sobrecarga em alguns destinos.

O desenho também considerou colisões em hashes de 32 bits, em vez de assumir que acrescentar pontos sempre melhoraria a distribuição.[13]

Como aplicar

Escolha uma estrutura repetida muitas vezes no seu serviço e estabeleça a propriedade que precisa preservar. Em um roteador, isso pode ser uma meta de distribuição entre destinos. Em outro sistema, pode ser precisão ou tempo de consulta.

Crie um benchmark com dados representativos e varie um parâmetro por vez. Registre consumo total, custo de construção, tempo de consulta e qualidade do resultado. Compare a economia agregada, não apenas a diferença aparente em uma instância do objeto.

Se a mudança alterar a escolha do destino de uma requisição, simule a transição entre as versões antiga e nova. Meça quantas chaves mudam de lugar e estime a pressão adicional na origem. Prepare um limite de avanço e uma condição de retorno antes da implantação gradual.

Cuidados e limites

A implantação relatada fez as implementações conviverem gradualmente para limitar misses e tráfego na origem durante a troca do anel.[13] O ganho de memória não elimina esse custo transitório.

Os percentuais da Cloudflare não devem virar configuração padrão para outros sistemas. Distribuição de chaves, pesos e escala podem exigir outra escolha. Também não basta declarar que uma estrutura tem seis bytes sem medir a alocação efetiva no conjunto usado pela aplicação. A proposta é reduzir desperdício demonstrável, não trocar uma suposição antiga por outra mais elegante.

Fonte

[13] Fonte: InfoQ