Ir para o conteúdo

Detalhes

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!

🌐 Site: https://craftcodeclub.io
💬 Comunidade: https://craftcodeclub.io/join
📅 Próximos eventos: https://craftcodeclub.io/events
📖 O livro PT: https://link.amazon/B0j5WeuXg
📖 O livro EN: https://link.amazon/B0ct3Q7K7
📚 Clube do Livro DDIA: https://craftcodeclub.io/book-clubs/designing-data-intensive-applications

O que você vai ver:

  • Workloads com skew: chaves distribuídas por igual não significam carga distribuída por igual
  • Hot keys: isolar a chave num shard só, dividir as escritas com prefixos aleatórios e o custo disso na leitura
  • Heat management e adaptive capacity: como os serviços de nuvem automatizam isso
  • Rebalanceamento automático vs manual: autoscaling, o custo de mover dados e as falhas em cascata
  • Roteamento de requisições: qualquer nó, uma camada de roteamento ou clientes que conhecem os shards
  • Quem decide onde fica cada shard: ZooKeeper, etcd, Raft embutido, config servers do MongoDB e gossip do Riak
  • Índices secundários locais: escrita num shard só, leitura em todos (scatter/gather) e latência de cauda
  • Índices secundários globais: leitura num shard só, escrita em vários e índices que podem ficar desatualizados
  • Resumo do capítulo: key range vs hash, coordenação e o problema das escritas entre shards

🎥 Outros vídeos que você também pode gostar

#DDIA #DesigningDataIntensiveApplications #Sharding #Particionamento #SistemasDistribuídos #BancoDeDados #CraftCodeClub #ClubeDoLivro #EngenhariaDeSoftware

Tópicos relacionados

Book Club
Software Architecture
Computer Programming
Software Development
Software Engineering

Você também pode gostar