Read Preference no MongoDB | MongoDB | Banco de Dados

• Read Preference no MongoDB | MongoDB | Banco de Dados

---

Visão geral

O Read Preference define de qual membro do replica set o MongoDB irá ler os dados.

Isso impacta diretamente:

• latência
• consistência
• distribuição de carga
• comportamento em ambientes geograficamente distribuídos

Em replica sets, você tem:

• 1 primary
• N secondary

O read preference controla para onde vão as leituras.

---

Tipos de Read Preference

primary

db.collection.find().readPref("primary")

Características:

• lê apenas do primary
• dados sempre mais atualizados
• comportamento padrão

Uso:

• quando precisa de consistência forte
• sistemas críticos (financeiro, transações)

---

primaryPreferred

db.collection.find().readPref("primaryPreferred")

Características:

• tenta ler do primary
• se não estiver disponível → usa secondary

Uso:

• quer consistência, mas tolera fallback
• melhora disponibilidade

---

secondary

db.collection.find().readPref("secondary")

Características:

• lê apenas dos secondary
• pode retornar dados desatualizados (replicação assíncrona)

Uso:

• relatórios
• analytics
• dashboards
• workloads de leitura pesada

---

secondaryPreferred

db.collection.find().readPref("secondaryPreferred")

Características:

• tenta ler dos secondary
• se não houver → usa primary

Uso:

• reduzir carga no primary
• leitura com alta disponibilidade
• aceita eventual consistency

---

nearest

db.collection.find().readPref("nearest")

Características:

• escolhe o nó com menor latência
• pode ser primary ou secondary
• baseado em tempo de resposta de rede

Uso:

• aplicações distribuídas globalmente
• multi-região
• foco em performance de leitura

---

Comparação rápida

Tipo	Fonte de leitura	Consistência	Uso principal
primary	primary	forte	transações, dados críticos
primaryPreferred	primary → fallback	alta	disponibilidade + consistência
secondary	secondary	eventual	analytics / relatórios
secondaryPreferred	secondary → fallback	eventual	aliviar primary
nearest	menor latência	variável	multi-região / baixa latência

---

Consistência vs Performance

• Primary

  • sempre consistente
  • maior carga

• Secondary

  • menor carga no primary
  • pode ter delay (replication lag)

MongoDB replica de forma assíncrona, então:

• leituras em secondary podem estar atrasadas

---

Cenários práticos

Sistema financeiro

Read Preference: primary

Motivo:

• não pode ler dado desatualizado

---

Dashboard de BI

Read Preference: secondary

Motivo:

• aceita delay
• reduz carga do primary

---

API global (multi-região)

Read Preference: nearest

Motivo:

• menor latência
• melhor experiência para usuário

---

Sistema com alta disponibilidade

Read Preference: secondaryPreferred

Motivo:

• prioriza performance
• fallback automático

---

Boas práticas

• não usar secondary para operações críticas
• usar nearest em arquiteturas distribuídas
• monitorar replication lag
• combinar com read concern quando necessário
• testar comportamento em failover

---

Insight importante

O Read Preference não garante consistência sozinho.

Ele funciona junto com:

• Read Concern
• Write Concern

Para definir:

• frescor do dado
• durabilidade
• comportamento em falhas

---