Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

395
Vistas
¿Cómo mejorar el rendimiento de las consultas recursivas en MongoDB?

MongoDB ha sido realmente una gran opción para una aplicación que estoy tratando de construir, a excepción de un área potencial para la cual REALMENTE espero que haya una solución. La mayoría de los datos serán un bosque. Para un nodo dado (o mejor dicho, documento) en un árbol en el bosque, me gustaría devolver todos los ancestros hasta la raíz de ese árbol.

Debido a la naturaleza distribuida de Mongo, es posible que los documentos que pertenecen al mismo árbol no residan en el mismo nodo y, por lo tanto, la forma más intuitiva de obtener esta información (a través de la recursividad) puede resultar costosa. He leído que podemos controlar qué nodos contienen qué documentos a través de la clave de partición, por lo que pensé que tal vez cada documento en el árbol pueda contener una referencia al ObjectId del documento raíz del árbol y usarlo como la clave de partición. --de esta manera puedo garantizar que todos los documentos de un árbol en particular pueden residir en un solo nodo, sin embargo, todo el bosque se distribuirá entre los nodos en el clúster fragmentado. Sin embargo, incluso si este es el caso, no sé lo suficiente sobre los mongos para saber que, de hecho, reenviará la solicitud recursiva al único nodo que contiene el árbol y realizará la consulta recursiva en ese nodo y solo en ese nodo. esa es mi primera pregunta, ¿es posible delegar la consulta recursiva a un solo nodo que sepa que contiene todos los documentos que se devolverían en dicha consulta? Si es así, quizás la consulta recursiva no sea demasiado terrible.

Sin embargo, el enfoque anterior plantea un problema: ¿qué pasa si un árbol en particular crece mucho? No puedo pensar en ninguna otra forma de manejar este problema que no sea mover el árbol a un nodo dedicado para tales propósitos, posiblemente usando alguna heurística para reubicar preventivamente un árbol antes de que sea demasiado grande (cuando sería incluso un poco costoso para transferir). Sin embargo, no sé si eso es posible en MongoDB (reubicar datos de un nodo de clúster a otro) y no sé si podría tener ese tipo de control de lógica de fragmentación en el árbol que se ha movido al nodo dedicado, algo así como:

 if shard_key in special_shard_keys: store data in dedicated node else: store data in node using other sharding logic

Si la lógica anterior es posible, entonces resuelve otra preocupación: no todos los documentos deben fragmentarse exactamente de la misma manera. Aparte de los árboles que estaré almacenando, almacenaré otras estructuras que no sean árboles, sería bueno si pudieran tener su propia lógica de fragmentación dedicada basada en otras cosas, por lo que mi última pregunta es: ¿es posible ¿Tiene lógica de fragmentación por tipo de documento?

over 4 years ago · Santiago Trujillo
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda