MongoDB: collection, cluster y replica set explicados

Quien empieza con MongoDB se topa con tres palabras que parecen sinónimos: collection, cluster y replica set. Están en niveles distintos. Una describe cómo se organizan tus datos, otra describe cómo se copian entre servidores, y la tercera es un apodo para el conjunto completo.

Entender la diferencia evita errores prácticos: escribir mal la cadena de conexión, esperar que un secondary tenga siempre el dato más reciente, o creer que necesitas sharding cuando solo hacía falta una copia más. Si todavía no conoces la base de datos en sí, empieza por Qué es MongoDB.

¿Qué es una collection en MongoDB?#

MongoDB guarda datos en documentos (formato BSON, parecido a JSON). Los documentos viven en collections, y las collections viven en una base de datos (database). En términos de SQL, la collection es la tabla y el documento es la fila, con una diferencia importante: por defecto, los documentos de una misma collection no necesitan tener los mismos campos.

use tienda
db.clientes.insertMany([
  { nombre: "Ada", edad: 36 },
  { nombre: "Linus", lenguajes: ["C", "Rust"] },
  { titulo: "Sin nombre", tags: [] }
])

Los tres documentos de arriba conviven en la collection clientes. Eso da libertad al inicio del proyecto, pero también deja pasar datos mal formados.

¿Hay que crear la collection antes?#

No. MongoDB crea la base de datos y la collection en la primera escritura. insertOne crea la collection si no existe, y createIndex también. Esta creación implícita usa las opciones por defecto.

Cuando quieras definir opciones antes, créala de forma explícita con createCollection. Un uso común es la validación de esquema:

db.createCollection("usuarios", {
  validator: {
    $jsonSchema: {
      bsonType: "object",
      required: ["nombre", "email"],
      properties: {
        nombre: { bsonType: "string" },
        email: { bsonType: "string", pattern: "^.+@.+$" }
      }
    }
  }
})

Para cambiar las opciones después, usa el comando collMod. La validación puede rechazar la escritura (validationAction: "error") o solo registrar un aviso ("warn"). Si tus datos tienen una forma estable, conviene activar la validación pronto.

¿Qué es un replica set?#

Un replica set es un grupo de procesos mongod que mantienen el mismo conjunto de datos. Cada proceso pertenece a un único replica set. Los roles son:

• Primary: recibe todas las escrituras.
• Secondaries: guardan copias de los datos y aplican los cambios del primary de forma asíncrona.
• Arbiter: vota en las elecciones, pero no guarda datos. Sirve para cuando un tercer servidor completo resulta demasiado caro, y no aporta redundancia de datos.

El primary registra cada cambio en el oplog (registro de operaciones), y los secondaries leen ese registro para quedar iguales a él. Como la copia es asíncrona, un secondary puede ir unos instantes por detrás.

¿Cuántos miembros y por qué?#

La documentación indica al menos tres miembros. El formato recomendado es primary, secondary y secondary (P-S-S), con tres copias completas de los datos. La alternativa más barata es primary, secondary y arbiter (P-S-A): el arbiter solo vota, así que hay una única copia de reserva y la tolerancia a fallos es menor.

El motivo del número tres es el voto. Con tres votantes, la mayoría es dos. Si un servidor cae, los otros dos siguen formando mayoría y continúan operando. Con dos votantes, perder uno deja al otro solo, sin mayoría.

¿Qué pasa cuando el primary cae?#

Si el primary deja de comunicarse con el resto del conjunto durante más de electionTimeoutMillis (10 segundos por defecto), un secondary elegible convoca una elección. Con la configuración por defecto, la mediana para elegir un nuevo primary normalmente no supera los 12 segundos, contando la detección del fallo.

Durante ese intervalo no hay primary, así que las escrituras fallan o esperan. Los drivers actuales reintentan automáticamente ciertas escrituras una vez (retryable writes), lo que oculta parte del problema a tu aplicación. Reducir electionTimeoutMillis detecta fallos más rápido, pero puede provocar elecciones innecesarias en picos de latencia de red.

¿Cómo afecta el replica set a lecturas y escrituras?#

Por defecto, el cliente lee del primary. Puedes leer de los secondaries con readPreference, aceptando que el dato puede estar atrasado por la replicación asíncrona. Las transacciones que leen datos deben usar primary.

Para escrituras importantes, usa w: "majority". La escritura solo se confirma después de replicarse en la mayoría de los votantes, así que sobrevive a un cambio de primary. Con w: 1, una escritura confirmada solo por el primary puede sufrir rollback si este cae antes de replicar.

¿Qué es un cluster en MongoDB?#

"Cluster" no es un componente con una definición única. Es la palabra para el conjunto de servidores que atiende tu base de datos, y su sentido depende del contexto:

• Cluster como replica set. En muchos servicios de bases de datos alojadas, "crear un cluster" da como resultado un replica set. Es el caso más común.
• Sharded cluster. En el manual de MongoDB, el término designa la arquitectura de sharding: varios shards (cada uno debe ser un replica set), routers mongos que reciben las conexiones de los clientes y config servers que guardan los metadatos.

Es decir: todo shard es un replica set, pero no todo replica set es un sharded cluster.

¿Cuándo tiene sentido usar sharding?#

El sharding divide una collection en trozos (chunks) entre varios shards, y un balanceador mueve esos trozos para equilibrar el volumen. Resuelve dos límites del escalado vertical (un servidor más grande): CPU saturada por muchas consultas y datos más grandes que la RAM.

El costo es complejidad operativa. La clave de shard exige cuidado: se puede rehacer el sharding de la collection (reshard, desde MongoDB 5.0), pero el proceso es lento y consume muchos recursos. Las consultas sin la clave se envían a todos los shards. Antes de pensar en esto, agota mejores índices, consultas más ligeras y más RAM. El sharding no sustituye la replicación: la alta disponibilidad sigue viniendo del replica set, ya que cada shard es uno.

¿Cómo aparece el replica set en la cadena de conexión?#

En la cadena de conexión enumeras los miembros e indicas el nombre del conjunto, para que el driver descubra quién es el primary:

mongodb://usuario:contraseña@host1:27017,host2:27017,host3:27017/tienda?replicaSet=rs0&w=majority

El formato mongodb+srv:// descubre la lista de servidores mediante una consulta DNS, así que indicas un único nombre de host, y activa TLS por defecto. Los caracteres especiales en el usuario o la contraseña (como $ : / ? # [ ] @) necesitan codificación porcentual: @ se convierte en %40. Para ver la conexión en código, lee Cómo conectar MongoDB a Node.js.

¿Cuándo no necesitas preocuparte por esto?#

Si tu base de datos la aloja un servicio, la topología (cuántos miembros, dónde están) suele definirla quien provee la base, y tú usas la cadena de conexión que te entrega. Aun así conviene conocer los términos, porque w: "majority" y readPreference cambian el comportamiento de tu aplicación. Para comparar el modelo de documentos con las tablas, mira SQL o NoSQL.

Cómo hacerlo en Square Cloud#

Square Cloud ofrece hosting de MongoDB a partir del plan Standard, siempre en una versión reciente. Creas la base de datos en el panel, y se aprovisiona en segundos en el mismo datacenter que tus aplicaciones, con una latencia media de alrededor de 1 ms. El TLS es obligatorio, con el certificado que descargas en el panel.

El MongoDB alojado es un nodo único (standalone), sin replica set: no hay miembros secundarios, ni elecciones, ni replicaSet en la cadena de conexión. Usa la URL que te da el panel y confía en los snapshots, no en réplicas, para recuperar datos. Las collections, los documentos y los índices funcionan como se describe arriba.

Puedes tomar snapshots manuales de la base cuando quieras y, en todo plan que incluye bases de datos, también tienes un snapshot automático diario, guardado durante 7 días (el más reciente hasta 30 días). Cada snapshot se puede restaurar en la misma base, en otra del mismo motor o en una base nueva.

Mira los detalles en hosting de MongoDB.