MongoDB
Explica cómo crear, configurar, renombrar y eliminar colecciones, junto con validators, collation, capped collections y opciones operativas relevantes.
Una colección agrupa documentos con propósito, access patterns y políticas de operación relacionadas. MongoDB puede crear una collection implícitamente al insertar el primer documento, pero crearla de forma explícita permite establecer desde el inicio validation, collation y opciones especiales.
database
├── orders
├── products
├── customers
└── inventoryMovementsEl número de colecciones no debe copiar automáticamente el número de clases, pantallas o pequeños objetos del sistema. Cada collection debe justificar su lifecycle, queries, índices, permisos y crecimiento.
Una collection funciona como frontera para:
Crear colecciones sin criterio produce fragmentación, joins constantes y administración innecesaria. Mezclar documentos incompatibles en una sola colección produce índices poco útiles, validators complejos y queries difíciles.
MongoDB puede crear database y collection al realizar la primera escritura:
use domisys;
db.products.insertOne({
name: 'Café molido',
active: true
});Esto es cómodo para aprendizaje y prototipos. Sin embargo, la primera escritura puede ocurrir antes de configurar validator, collation o permisos adecuados.
En entornos controlados suele ser preferible que una migración cree explícitamente la collection y sus índices.
db.createCollection('orders', {
validator: {
$jsonSchema: {
bsonType: 'object',
required: ['businessId', 'status', 'items', 'createdAt'],
properties: {
businessId: { bsonType: 'objectId' },
status: {
enum: ['draft', 'pending', 'confirmed', 'cancelled']
},
items: {
bsonType: 'array',
minItems: 1
},
createdAt: { bsonType: 'date' }
}
}
},
validationLevel: 'strict',
validationAction: 'error'
});Después se crean índices de forma deliberada:
db.orders.createIndex({
businessId: 1,
status: 1,
createdAt: -1,
_id: -1
});Crear collection e índices son pasos distintos. La collection no recibe automáticamente índices para los access patterns.
Nombres recomendables:
data o records;Ejemplos:
orders
inventoryMovements
userSessionsEvita crear ordersV2FinalNew. Las versiones del schema deberían manejarse con migraciones, aliases operativos o campos de versión según el caso.
Una dirección embebida no necesita su propia collection si no tiene lifecycle ni queries independientes.
{
deliveryAddress: {
line1: 'Calle 10 # 20-30',
city: 'Bogotá'
}
}En cambio, products merece una collection porque:
Considera separación cuando los grupos tienen:
No separes únicamente porque dos documentos tengan campos distintos. El polimorfismo controlado puede ser válido.
Collation define reglas lingüísticas para comparación y orden de strings:
Puede configurarse como default de collection:
db.createCollection('customers', {
collation: {
locale: 'es',
strength: 2
}
});Los índices tienen collation. Una query con collation incompatible puede no utilizar el índice esperado.
No utilices lowercasing manual como sustituto universal: puede destruir información y manejar mal reglas lingüísticas.
Una capped collection tiene tamaño limitado y conserva orden de inserción. Cuando alcanza su capacidad, sobrescribe documentos antiguos.
db.createCollection('temporaryEvents', {
capped: true,
size: 104857600,
max: 100000
});Posibles usos:
Limitaciones y trade-offs:
No la utilices como queue universal.
Están diseñadas para mediciones asociadas a tiempo y metadata estable:
db.createCollection('temperatureReadings', {
timeseries: {
timeField: 'measuredAt',
metaField: 'sensor',
granularity: 'minutes'
},
expireAfterSeconds: 60 * 60 * 24 * 90
});Documento:
{
measuredAt: ISODate('2026-07-24T12:00:00Z'),
sensor: {
id: 'warehouse-1',
zone: 'cold-room'
},
temperature: 4.2
}MongoDB organiza internamente mediciones en buckets. La colección es apropiada cuando el workload realmente consiste en series de mediciones, no para cualquier documento con createdAt.
Las capacidades de updates, deletes, indexes y sharding dependen de la versión. Deben verificarse antes de diseñar producción.
Una clustered collection organiza documentos físicamente alrededor de una clustered key compatible. Puede reducir almacenamiento en ciertos workloads y cambia algunas decisiones de acceso.
No debe activarse solo porque parece una optimización. Requiere evaluar:
Para la mayoría de aplicaciones generales, el índice _id normal y los índices explícitos son suficientes hasta que exista una necesidad medida.
MongoDB utiliza namespaces internos para metadata y operación. No deben tratarse como colecciones de aplicación ni modificarse manualmente salvo procedimientos documentados.
Ejemplos internos pueden variar por versión y topología. Las herramientas oficiales son preferibles a editar metadata directamente.
db.orders.renameCollection('salesOrders');Renombrar parece simple, pero puede afectar:
$lookup;Estrategia segura:
db.orders.drop();drop elimina collection e índices. Es una acción destructiva y no equivale a borrar documentos con posibilidad de recuperación automática.
Antes de ejecutar:
No incluyas comandos destructivos genéricos en scripts que reciben nombres desde input no confiable.
La definición de collections debe versionarse como código:
001_create_orders_collection
002_add_orders_indexes
003_add_orders_validator
004_backfill_schema_versionCada migración debe ser:
No crees collections manualmente solo en producción y esperes que otros entornos coincidan.
Los roles pueden restringir acceso por database y collection. La aplicación debería utilizar un usuario con operaciones necesarias, no roles administrativos.
Ejemplo conceptual:
application user
→ readWrite sobre domisys
→ sin userAdmin
→ sin clusterAdminProcesos de backup, monitoring y migración pueden necesitar usuarios separados.
Change Streams requieren una topología compatible, normalmente replica set o sharded cluster. La collection no necesita una opción “enable change streams” general, pero features como pre/post images sí requieren configuración específica y soporte de versión.
No diseñes consumidores asumiendo que un standalone local reproduce el comportamiento de producción.
Al crear una collection, añade solo índices justificados:
db.products.createIndex(
{ businessId: 1, sku: 1 },
{ unique: true }
);
db.products.createIndex({
businessId: 1,
active: 1,
name: 1
});Cada índice consume almacenamiento, memoria y trabajo de escritura. Crear uno por cada campo no es una estrategia.
Una migración debe comprobar opciones actuales y no asumir que crear de nuevo es seguro.
Audita y corrige antes de activar errores estrictos.
Queries pueden hacer sort o scan inesperado. Verifica índice y query collation.
Un documento de negocio con updates frecuentes y relaciones complejas no se vuelve time series solo por tener fecha.
Replication copiará el drop; no lo deshace. La recuperación depende de backups o point-in-time recovery.
Crear una collection por cliente puede producir miles de namespaces, índices y migraciones. Normalmente es preferible una collection compartida con tenantId, salvo requisitos fuertes de aislamiento.
Fragmenta el aggregate y aumenta joins.
Escala mal operativamente y complica queries globales.
Puede aceptar datos antes de configurar validation e índices.
No ofrece acknowledgments, retries ni durabilidad equivalente.
Ignora la semántica de mediciones y sus restricciones.
Elimina índices y datos y puede propagarse a réplicas.
Una collection es una frontera de estructura, índices, permisos y operación. La creación implícita es cómoda, pero la creación explícita permite controlar el contrato desde la primera escritura. Las opciones especiales deben responder a un workload real y verificarse según la versión utilizada.
CRUD: inserciones.