Craft & Code Club

Dividir os dados entre várias máquinas parece simples até você adicionar uma máquina nova e descobrir que quase todas as chaves mudaram de lugar. A forma de dividir decide quais consultas ficam baratas, onde a carga se acumula e quanto custa crescer.
Vamos abrir o Capítulo 7, 'Sharding', de Designing Data-Intensive Applications (2ª edição), de Martin Kleppmann e Chris Riccomini.

Vamos discutir quando vale dividir um banco em shards, quando é melhor não dividir, e como escolher a forma de dividir os dados para espalhar volume e escritas entre os nós.
Vamos passar pela diferença entre sharding e replicação (e pelos muitos nomes que um shard recebe), pelos prós e contras de shardear e pelo uso de shards para multitenancy, com isolamento de recursos e de falhas, backup por cliente e residência de dados. Depois, as formas de dividir dados chave-valor: key range sharding, com range scans eficientes e o risco de hot spots quando a chave é um timestamp, e hash sharding, do hash mod N que move quase tudo ao número fixo de shards, ao hash range e à variante do Cassandra e do ScyllaDB, até chegar ao consistent hashing.

E, como sempre, trazendo para o dia a dia: quando uma máquina só ainda dá conta (e hoje ela dá conta de muita coisa), como escolher uma partition key sem se arrepender depois, por que usar timestamp como chave joga todas as escritas num shard só e o que pesar antes de dar um shard para cada cliente. Uma conversa aberta, sem aula e sem dono da razão.

✨ Participa da Comunidade!

Os dados já estão divididos. Aí uma única chave passa a receber mais tráfego do que um shard aguenta, um nó lento é dado como morto e o cluster começa a mover dados no pior momento possível.
Vamos para a segunda e última parte do Capítulo 7, 'Sharding', de Designing Data-Intensive Applications (2ª edição), de Martin Kleppmann e Chris Riccomini. Saímos de como dividir os dados para o que acontece com um banco shardeado em produção: carga desigual, rebalanceamento, roteamento de requisições e índices secundários.

Vamos passar por workloads com skew e hot keys, como o post de uma celebridade, e pelas técnicas para aliviar um shard quente; pelo rebalanceamento automático vs manual e o risco de falhas em cascata quando ele se junta à detecção automática de falhas; pelas três formas de levar uma requisição até o nó certo e por quem guarda a verdade sobre onde está cada shard (ZooKeeper, etcd, Raft embutido e gossip); e pelos índices secundários locais e globais, com o trade-off entre escrita barata e leitura barata. Para fechar, os principais pontos do capítulo e o problema que ele deixa em aberto: escritas que precisam tocar vários shards.

E, como sempre, trazendo para o dia a dia: como lidar com um post que viraliza e concentra a carga numa chave só, quando vale deixar o rebalanceamento nas mãos de uma pessoa, como o seu banco descobre em que nó está cada shard e por que uma busca por índice secundário pode acabar consultando todos os shards. Uma conversa aberta, sem aula e sem dono da razão.

✨ Participa da Comunidade!