MongoDB
Explica find, findOne, filtros, proyecciones, ordenamiento, límites y cursores para recuperar documentos sin transferir ni examinar datos innecesarios.
Leer en MongoDB significa construir una query que seleccione documentos, decidir qué campos devolver, definir un orden y consumir los resultados sin utilizar más memoria, red o permisos de los necesarios.
findOne devuelve un documento o null. find devuelve un cursor que obtiene resultados por batches.
access pattern
↓
filter
↓
index / query plan
↓
projection + sort + limit
↓
cursor y batches
↓
DTO de respuestaconst order = await db.orders.findOne({
_id: orderId,
businessId: authenticatedBusinessId
});La consulta incluye el tenant autorizado. Buscar solo por _id y autorizar después puede exponer diferencias entre “no existe” y “no pertenece”, además de facilitar errores en código.
findOne devuelve null cuando no existe coincidencia:
if (!order) {
throw new Error('Order not found');
}No utilices non-null assertions para esconder ese caso.
const cursor = db.orders.find(
{
businessId,
status: 'pending'
},
{
projection: {
customer: 1,
total: 1,
status: 1,
createdAt: 1
}
}
).sort({
createdAt: -1,
_id: -1
}).limit(20);La query expresa:
Una query puede ser correcta funcionalmente y costosa operacionalmente. La verificación necesita explain() y datos representativos.
El filter debe construirse mediante campos permitidos:
const filter = {
businessId: session.businessId,
status: validatedStatus
};No hagas esto:
orders.find(request.body);Un objeto no confiable puede introducir operadores, campos fuera del tenant o queries costosas.
Projection limita los campos devueltos:
{
customer: 1,
total: 1,
createdAt: 1
}Beneficios:
No reemplaza DTOs. La respuesta todavía puede necesitar renombrar, convertir ObjectId y Decimal128, ocultar campos o calcular enlaces.
Sin un sort explícito, no debes depender del orden natural.
.sort({ createdAt: -1, _id: -1 })_id funciona como tie-breaker. El índice debe evaluarse junto con filtros y sort:
db.orders.createIndex({
businessId: 1,
status: 1,
createdAt: -1,
_id: -1
});Un límite protege API y servidor:
const pageSize = Math.min(validatedPageSize, 100);No permitas que el cliente elija límites arbitrarios. Incluso una query indexada puede transferir millones de documentos.
Un cursor no contiene todos los documentos desde el inicio. El driver obtiene batches.
for await (const order of cursor) {
await processOrder(order);
}Esto controla memoria mejor que:
const allOrders = await cursor.toArray();toArray() es adecuado cuando el resultado está estrictamente acotado. No lo utilices para exports o migraciones grandes.
batchSize controla cuántos documentos se solicitan por batch, no el número total de resultados.
Un batch grande reduce round trips, pero aumenta memoria y tiempo de respuesta del lote. Un batch pequeño aumenta viajes de red.
Debe medirse con tamaño de documento y workload reales.
Existen distintas necesidades:
No ejecutes countDocuments costoso si solo necesitas existencia:
const exists = await db.orders.find({ businessId }).limit(1).hasNext();Para paginación, el total exacto puede ser más costoso que la página y cambiar entre requests. Decide si realmente se necesita.
db.orders.distinct('status', { businessId });distinct puede ser útil para conjuntos pequeños de valores, pero resultados grandes consumen memoria y red. Para agrupación y métricas, aggregation suele ser más apropiada.
Read concern define qué nivel de consistencia o aislamiento se solicita. No debe configurarse por intuición.
Ejemplos conceptuales:
local puede observar datos locales del nodo.majority devuelve datos confirmados según majority commit point.snapshot se utiliza en contextos compatibles para una vista consistente.La elección depende de topología, latencia y requisito del caso de uso.
Por defecto, operaciones suelen leer del primary. Enviar lecturas a secondaries puede producir stale data.
Puede ser útil para analytics tolerante a retraso, pero no para una lectura crítica inmediatamente después de escribir sin diseñar consistencia causal o estrategia adecuada.
Una lista sin coincidencias debe ser un resultado normal:
{
"items": [],
"nextCursor": null
}No la conviertas automáticamente en error 404. findOne de un recurso específico sí puede mapearse a not found.
Esta consulta:
{ discount: null }puede coincidir con null y, según semántica, campos ausentes. Si necesitas distinguir:
{
discount: null,
$expr: { $eq: [{ $type: '$discount' }, 'null'] }
}También puedes combinar $exists y $type. Diseña el schema para evitar ambigüedad permanente.
Para exportar muchos documentos:
const cursor = db.orders.find(filter).batchSize(500);
for await (const order of cursor) {
await writer.write(transform(order));
}El consumidor debe aplicar backpressure. Leer más rápido de lo que se escribe acumula memoria.
Si se interrumpe el proceso, cierra cursor y registra checkpoint.
Las queries deben tener límites operativos:
maxTimeMS para ciertas operaciones;Cancelar en la aplicación no siempre significa que el servidor detenga inmediatamente todo el trabajo; verifica el comportamiento de la API utilizada.
Projection no es autorización. Una query debe incluir scope:
{
_id: orderId,
businessId: session.businessId
}Además:
Puede escanear y transferir toda la collection.
Aumenta payload y exposición.
No ofrece contrato estable para paginación.
Consume memoria y espera a reunir todo.
Puede romper read-after-write y mostrar datos antiguos.
Añade coste y puede no representar la misma vista que los items.
Timeout, autorización y fallo de servidor son categorías distintas.
Para una query lenta:
explain('executionStats');nReturned, keys y docs examinados;COLLSCAN, SORT y FETCH costosos;Una lectura segura y eficiente combina filter autorizado, projection mínima, orden estable, límite y consumo controlado del cursor. find no es una operación inocente: su coste depende del plan, volumen, consistency settings y forma de consumo.
findOne y find?toArray()?explain()?Filtros y operadores de consulta.