“Partitioning data is essential when scaling systems to handle large amounts of data and traffic.” — Martin Fowler
Aplicações modernas como redes sociais, e-commerces e serviços de streaming geram grandes volumes de dados rapidamente. Escalar verticalmente o banco pode não ser suficiente. A escalabilidade horizontal, que distribui os dados entre vários servidores, é uma solução comum em bancos NoSQL. Este artigo explica como isso funciona, com foco no MongoDB.
Em bancos de dados, escalar significa aumentar a capacidade de lidar com mais requisições ou mais volume de dados. Existem dois tipos principais de escala:
- Escala Vertical (scale-up): adicionar mais recursos (CPU, RAM, disco) a um único servidor.
- Escala Horizontal (scale-out): adicionar mais servidores/nós para distribuir a carga.
Bancos de dados relacionais tradicionais (como MySQL ou PostgreSQL):
- Foram projetados inicialmente para rodar em um único nó.
- Escalam principalmente de forma vertical.
- Replicação é geralmente usada apenas para leitura, com uma instância primária e réplicas secundárias (read replicas).
- Divisão de dados (particionamento) não é nativa e costuma exigir configurações complexas de sharding manual ou federated tables.
- Garantem transações fortes com o modelo ACID.
Já os bancos NoSQL:
- Foram projetados desde o início para rodar de forma distribuída.
- A escala horizontal é uma funcionalidade central e nativa.
- Utilizam sharding automático, com particionamento real dos dados entre os nós.
- A replicação é usada para alta disponibilidade, mas em conjunto com particionamento real dos dados.
- Muitas vezes adotam o modelo eventual consistency (consistência eventual) para permitir maior escalabilidade e performance.
| Característica | Banco Relacional (SQL) | Banco NoSQL |
|---|---|---|
| Modelo de Escala | Vertical (e horizontal com mais configuração) | Horizontal (nativo em muitos casos) |
| Replicação de Dados | Read replicas, escrita com configuração adicional | Replicação integrada com distribuição de dados |
| Particionamento de Dados | Suportado, exige configuração explícita (partitioning) | Nativo com balanceamento automático entre shards |
| Consistência | Forte (ACID) | Eventual ou configurável |
| Tolerância a falhas | Limitada, depende da arquitetura do cluster | Alta, com failover e distribuição integrada |
| Flexibilidade do esquema | Estrutura rígida, alteração controlada | Estrutura flexível (schema-less) |
Nota: O particionamento é possível em bancos relacionais, mas normalmente requer intervenção manual ou uso explícito de features como partition by, views particionadas ou sharding controlado externamente. Em bancos NoSQL como MongoDB, o particionamento faz parte da arquitetura do cluster e pode ser distribuído automaticamente entre nós.
Um replica set é um mecanismo de replicação usado por bancos NoSQL para garantir alta disponibilidade. No MongoDB, esse conceito refere-se a um grupo de nós que mantêm cópias idênticas dos dados. Um nó atua como primário (aceita escritas) e os demais como secundários (sincronizam as mudanças e podem servir leituras, dependendo da configuração). Como todos os nós armazenam os mesmos dados, não há divisão da carga de escrita — apenas redundância e leitura distribuída com consistência eventual.
Porém, todos os dados são armazenados em todos os nós. Não há divisão de carga de escrita, apenas possibilidade de leitura em réplicas, com limitações.
Para escalar leitura com consistência eventual, replicas ajudam. Para escalar escrita e volume de dados, só o sharding permite isso de forma verdadeira.
Outros bancos NoSQL também implementam replicação, ainda que com variações no modelo. Cassandra, por exemplo, adota uma arquitetura peer-to-peer, onde todos os nós são iguais e mantêm réplicas de forma distribuída, sem um líder fixo. DynamoDB, por sua vez, oferece replicação gerenciada como parte da infraestrutura da AWS.
O sharding é a base da escalabilidade horizontal em muitos bancos NoSQL. Ele divide os dados em partes menores chamadas shards, distribuindo-as entre diferentes nós do cluster. Com isso, é possível distribuir tanto a carga de leitura quanto de escrita.
Cada shard no MongoDB é implementado como um replica set independente, com seu próprio nó primário, o MongoDB permite múltiplas escritas simultâneas em diferentes shards. Isso garante escalabilidade horizontal real para escrita, desde que a distribuição dos dados pela shard key seja equilibrada. Caso contrário, um ou poucos shards podem se tornar sobrecarregados, anulando os benefícios do particionamento. Saiba mais na documentação oficial sobre sharding.
A forma como os dados são direcionados aos shards varia entre os bancos NoSQL. No MongoDB, usa-se uma shard key como chave de roteamento. Em outros, como Cassandra ou DynamoDB, a distribuição ocorre automaticamente com base em funções de hash internas ou algoritmos de particionamento definidos pelo sistema, sem a necessidade de configurar um roteador explícito como o mongos. Exemplo:
- Um dado chega com uma chave de roteamento (ex:
cliente_name). - A requisição passa por um roteador (como o
mongos, no MongoDB). - O roteador determina qual shard deve receber ou processar o dado.
- O dado é armazenado e replicado em um replica set que representa o shard.
Essa separação entre particionamento de dados (para escalar horizontalmente) e replicação (para alta disponibilidade) é um dos pilares da arquitetura de bancos NoSQL distribuídos.
sh.enableSharding("minha_base")
sh.shardCollection("minha_base.minha_colecao", { cliente_name: 1 })A partir desse ponto, o MongoDB distribui automaticamente os documentos com base nessa chave.
Sharding deve ser considerado quando o volume de dados ou a carga do sistema ultrapassam o que um único servidor consegue suportar com eficiência.
- Há crescimento constante e expressivo de dados.
- A escrita se torna um gargalo mesmo após otimizações.
- É necessário escalar horizontalmente para manter a performance.
- A aplicação atende múltiplos clientes ou regiões com padrões de acesso distintos.
- Recursos do servidor frequentemente no limite (CPU, memória ou disco).
- Lentidão percebida em operações simples.
- Crescimento rápido da base com expectativa de continuidade.
- O volume de dados é pequeno ou estável.
- A estrutura de acesso aos dados não favorece uma shard key eficiente.
- A equipe ainda está se familiarizando com operações distribuídas.
A recomendação geral é iniciar com replica sets e somente aplicar sharding quando houver evidências claras de que a escalabilidade do modelo atual não é mais suficiente.
Ao projetar a escala horizontal com bancos NoSQL, é importante considerar boas práticas para evitar armadilhas comuns:
- Escolha uma chave de particionamento bem distribuída (alta cardinalidade e uniformidade de acesso).
- Avalie se o volume e a taxa de acesso justificam a complexidade de um cluster sharded.
- Mantenha o balancer ativo no MongoDB para garantir distribuição automática dos dados.
- Monitore o cluster: uso de CPU, IOPS, latência e espaço em disco devem ser acompanhados continuamente.
- Teste com dados reais ou simulados antes de ativar sharding em produção.
- Evite shard keys com baixa variabilidade (como booleanos, status ou campos com poucos valores distintos).
Além do MongoDB, bancos como Cassandra e DynamoDB também oferecem escalabilidade horizontal, mas com abordagens diferentes:
- No Cassandra, a distribuição dos dados é automática via hashing e cada nó já participa da arquitetura distribuída desde o início.
- No DynamoDB, o particionamento é gerenciado pelo próprio serviço da AWS, com escalabilidade embutida baseada em throughput.
- Já em bancos como Redis Cluster, a distribuição de chaves é feita por slots, exigindo cuidado com balanceamento e acesso concorrente.
Cada banco NoSQL possui seus próprios mecanismos de sharding, replicação e consistência. Conhecer essas particularidades é essencial para tomar decisões técnicas alinhadas com os requisitos da aplicação.
A escala horizontal com NoSQL, especialmente com o uso de sharding, oferece ganhos reais em desempenho e capacidade de crescimento. No entanto, essa abordagem vem acompanhada de complexidade operacional, custos de infraestrutura e desafios na modelagem de dados.
Antes de optar por uma arquitetura distribuída, é importante avaliar se o volume e o ritmo de crescimento dos dados realmente exigem esse nível de escalabilidade. Em muitos casos, um banco relacional bem configurado, com índices adequados, replicação e particionamento controlado, pode atender grandes cargas de leitura e escrita com menor complexidade.
Optar por sharding é uma decisão arquitetural que deve ser feita com base em dados, testes e previsões de crescimento. Nem toda aplicação precisa de um cluster distribuído, mas toda aplicação precisa ser projetada com clareza sobre seus limites e seus objetivos.
- MongoDB Manual - Sharding
- MongoDB Manual - Replica Sets
- MongoDB - Sharded Cluster Components
- MongoDB - Add/Remove Shard
- MongoDB - Choose a Shard Key
- MongoDB - Read Concern
- Apache Cassandra - About DML and Consistency
- Fundamentals of Data Engineering — Reis & Housley
- Building Microservices — Sam Newman
- MongoDB Architecture