Empresas
Empregos
  • Sobre nós
  • Soluções
    • Publicação de vagas
      Publique sua vaga e receba candidatos qualificados em 48h.
    • Avaliações de candidatos
      Mais de 500 testes técnicos e psicológicos, mais anti-fraude.
    • Headhunting
      Busca executiva personalizada do início ao fim.
    • Folha de Pagamento + EOR
      Dispersão de folha e EOR em mais de 15 países da LATAM.
  • Preços
  • Empregos

0

488
Visualizações
¿Cuál es la forma más eficiente de consultar dos colecciones en MongoDB para obtener resultados de búsqueda con paginación?

Aquí está el escenario:

  • Hay dos colecciones
  • La primera colección tiene una relación de uno a muchos con la segunda colección. La segunda colección tiene un uno a uno con la primera colección.
  • La consulta se realiza en 3 campos, todos los cuales son índice
  • 2 de esos índices están en la primera colección y 1 está en la segunda colección
  • Los resultados deben admitir la paginación.

Actualmente, lo mejor que se me ocurrió es usar una agregación. Las etapas se ven así:

Agregación -> coincidencia en 2 valores indexados en la primera colección -> ordenación -> búsqueda con una tubería que tiene una coincidencia en la propiedad de relación en ambas colecciones Y coincidencia basada en el valor de búsqueda potencial en un valor indexado en la segunda colección -> haga coincidir con OR que mira 2 campos de búsqueda en la primera colección usando expresiones regulares o si el proyecto de la búsqueda contenía algún resultado -> límite -> proyecto con valores

Las preocupaciones son que la búsqueda hará una combinación de todos los documentos de la primera colección con la segunda colección durante la búsqueda. Tenga en cuenta que todo lo que se busca es un índice, pero la búsqueda es la principal preocupación aquí. ¿Sugerencias para hacer esto de la manera correcta? ¿Mejor manera?

Ejemplo de código:

 db.collection1.aggregate( [ { $match: { // initial filters based on indexed values field1: "somevalue", field2: "somevalue" }, }, { $sort: { firstSortField: -1, _id: -1 // sort results by needed order } }, { $lookup: // join with another collection to search on a specific value { from: collection2, localField: someLocalField, foreignField: someForeignField, as: "someJoinedFields" } }, { $addFields: { extraField: ["$someJoinedFields.someExtaField"] // add potential array of values } }, { $match: ( { $or: [ { field3: {$regex: ""}}, // potential search field { field4: {$regex: ""}}, // potential search field { extraField: {$regex: ""}} // potential search field ] } ) }, { $limit: 100 // limit to 100 results for pagination }, { $project: { // final results finalField: 1, finalField2: 1, finalField3: 1 } } ])
over 4 years ago · Santiago Trujillo
1 Respostas
Responde à pergunta

0

Problema

Lamentablemente, sus esquemas no se ajustan de manera eficiente a sus necesidades por las siguientes razones:

  • La paginación necesita una clasificación inmutable en la colección para realizar un seguimiento del último elemento y asegurarse de que no se omita ni se repita ningún elemento.
    • Lo haces con _id , lo cual es bueno ya que está garantizado que es único.
    • No realiza un seguimiento del último elemento (básicamente usando $skip en su ejemplo)
  • La búsqueda debe realizarse después del $limit (como dijiste: D)
    • al hacerlo, evita fusionar muchos elementos. (¡Se vuelve lento muy rápido!)
  • No se debe hacer ninguna coincidencia después del $limit (como lo hace actualmente: D)
    • Si pones una coincidencia después, no mantendrás la cantidad de elementos que querías

Básicamente, está preguntando algo que le permite hacer $skip before $lookup , $match before $skip y $lookup before $skip . ¡Esto no es posible!

Soluciones

Todas las soluciones que vienen a la mente son en realidad difíciles de implementar.

Haz tu base de datos incrustada

https://docs.mongodb.com/manual/tutorial/model-embedded-one-to-many-relationships- between-documents/

Una de las mejores cosas de MongoDB es lo fácil que es cambiar la estructura de los documentos. Si puede hacerlo, sin destruir alguna otra característica, hágalo. Al incrustar el documento, ya no necesita la $lookup , lo que elimina el problema por completo (incluso puede hacer que el límite sea mucho más grande, ya que lo único "lento" será la fase de recopilación)

Crear una vista materializada

https://docs.mongodb.com/manual/core/materialized-views/

Esto le permitirá no cambiar la estructura original mientras tiene la velocidad de la consulta incrustada. Este método ralentizará su velocidad de escritura, ya que tendrá que recrear la vista en cada inserción o editar en una de las colecciones, pero la lectura será más rápida.

Mongo 5 $lookup mejorada

https://docs.mongodb.com/manual/reference/operator/aggregation/lookup/#correlated-subqueries-using-concise-syntax

Con este método, fusionará muchos menos documentos y podrá descartarlos fácilmente.

Resumir

Cuándo cambiar la estructura

El camino a seguir es cambiar la estructura de la base de datos. Entiendo aunque, que puede ser imposible de hacer por varias razones.

Cuándo usar la vista materializada

No tiene muchas operaciones de escritura y no tiene problemas de espacio (ya que esto ocupará el doble de espacio)

Cuándo usar $búsqueda

Utilice la búsqueda si no puede cambiar la estructura y no puede permitir escrituras más lentas. Este es, con mucho, el más lento de los 3 métodos, pero aún así te dará un impulso. A largo plazo, este método podría no ser una solución en absoluto, todo depende de cuáles sean sus casos de uso: D

over 4 years ago · Santiago Trujillo Relatório
Responde à pergunta
Encontrar trabalhos remotos

Descubra a nova forma de encontrar um emprego!

melhores empregos
Principais categorias de trabalho
Empresas
Postar vaga Preços Comercial
Jurídico
Termos e Condições Política de privacidade
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomende algumas ofertas para mim
Preciso de ajuda