MongoDB: ¿Está buscando en matrices tan rápido como buscar en claves simples?

Question

decir que haya el siguiente diseño:

id | participant_ids 
...| [ObjectId(...), ObjectId(...)] 

Ahora estoy consulta de esta manera:

db.events.find({ 
    participant_ids: ObjectId(...) 
}); 

que es idéntica a esto:

db.events.find({ 
    participant_ids: { 
     $in: ObjectId(...) 
    } 
}); 

Asumo que ISN es una diferencia en el rendimiento entre esos dos (¡pero corrígeme si estoy equivocado!).

---

Para cada evento, hay al menos 1 y como máximo 2 participantes. Así que también podría utilizar el siguiente diseño:

id | participant_1_id | participant_2_id 

... y consultar así ...:

db.events.find({ 
    $or: { 
     participant_1_id: ObjectId(...), 
     participant_2_id: ObjectId(...) 
    } 
}); 

---

Si yo no usaría la indexación, esto probablemente doesn' realmente hace la diferencia, pero, por supuesto, lo soy.

Para el primer diseño, I'ld ir con el siguiente índice:

db.events.ensureIndex({ 
    participant_ids: 1 
}); 

Para la segunda, I'ld ir con esto:

db.events.ensureIndex({ 
    participant_1_id: 1, 
    participant_2_id: 1 
}); 

---

dieron dos desventajas cuando miras su desempeño.

• primera consulta: El uso de un Array es probablemente más lento que usar una llave normal.
• Segunda consulta: El uso del operador $or no es muy rápido.
• Segunda consulta: No es muy escalable, por ejemplo, quiero liberar el límite de participantes en algún momento, eso no sería posible (tendría claves ilimitadas y elementos ilimitados en el $or -parte del consultas).

---

Mis preguntas son: - ¿Qué diseño debería usar? - ¿Puedo indexar Array s? Los documentos no dicen nada sobre esto, y no estoy seguro de que Array s (ya que sus contenidos pueden variar mucho).

Answer 1

Primera consulta: El uso de una matriz es probablemente más lento que con una tecla simple.

No lo creo. Debería ser exactamente la misma ruta de acceso basada en índice si tiene un valor ("clave simple") o múltiple ("matriz").

participant_1_id, participant_2_id es simplemente terrible.