lol que raro, una persona que curra en mongo defendiendo mongo. tranquilo, amigo mongolongo, que saco los crayons y las muñecas y te lo explico en plan dora la exploradora meets barrio sésamo. > las inconsistencias no se generan por arte de magia no, amigo mongolongo, obviamente no. las inconsistencias se generan cuando tu "base de datos" no es una "base de datos", sino que es un almacén de cualquier tipo de porquería jsoniana que le lances. la única razón por la que mongodb (y nosql en general) se puso de moda hace 15 años es porque se vendió como esa herramienta mágica para la que no necesitas schemas (lol), ni integridad de datos (lol) porque "ya lo haces en el código" (lol), ni indices (lol) porque "todo va rápido" (lol). el marketing entero giraba entorno a "mira que fácil es montarlo, y no necesitas hacer absolutamente nada mas que empezar a lanzarle los jsons que quieres guardar!! es que ni t⃥a⃥b⃥l⃥a⃥s⃥ colecciones necesitas crear!! ni usuarios!!", lo cual (como era de esperar) atrajo a la gente mas vaga y inepta que existía en nuestro mundo. Y ahí empezaron a hacer bolitas de kaka con el stack MEAN, donde lo que el usuario generaba en Angular, se leía y guardaba tal cual en Mongo, pasando por Express.js únicamente porque no se podía quitar de la ecuación. > no entiendo por que las queries le funcionaban con 1M, pero no con 10M, ¿es por timeouts? no, amigo mongolongo, es por el memory pressure de los indexes. Verás (tela que trabajando en mongolongo SL no sepas esto), en una base de datos relacional, creas un indice y es (probablemente) un B-Tree donde cada entry guarda el key y el TID. el key es el valor que has indexado. Si has indexado la columna "email" pues el key será "[email protected]". Y el TID es (normalmente) una tupla de 2 numeritos que le dicen al motor de la base de datos el archivo y offset exactos donde puede encontrar el row al que pertenece ese key. entries pequeños -> btree pequeño -> eso hace que normalmente un indice ocupe una fracción del tamaño de la tabla. en mongolongolandia, el key es un fukin blob que contiene el nombre del campo en sí (porque eso es lo que ocurre cuando no tiene un schema, que no sabes ni lo que buscas ni donde buscarlo, así que tus indices contienen el json-path para no cagarse encima), el valor del campo, el tipo del campo y, dios no quiera, el indice lo hayas puesto sobre un nested path y un array, que en ese caso se añaden ochocientos mil novecientos sesenta y dos incoherencias mas al key. y eso se traduce en entries gigantescos y un btree mas gordo que la tua mamma después de su trigésimo octava liposucción. el indice no crece de manera lineal y predecible (como en un motor relacional), sino como un tumor puesto hasta arriba de cocaína. y ahí tienes la explicación 100tifika de por que con 1M de documentos tu rendimiento es bueno y con 10M la base de datos se caga encima. > la sintaxis y el funcionamiento de mongolongo no es tan complicado, no debería ser complicado encontrar a gente no, amigo mongolongo, complicado no es. el problema es que esa inmundicia oligofrenica no la quiere tocar nadie que no esté enganchado al sadomasoquismo. El overlap porcentual de los 2 círculos en un diagrama de Venn entre la gente técnicamente solvente en temas de bases de datos, gestión de datos, análisis de datos (etc...) y la gente que querría hacerlo con mongolongo es menor que las probabilidades de que te toque la lotería. 8 veces. con el mismo boleto. > mongolongo es superior en sistemas write heavy; te va a costar escalar psql amigo mongolongo, el único escenario donde mongolongo es más rápido que psql es en operaciones de write en colecciones donde no tienes indices ni journal. es decir, donde lo usas como si tus datos fuesen paquetes enviados por UDP. "si entra y se guarda, pos bien, y sino, pos bien también". y en escenarios así existen alternativas que van a ser más rápidas que mongolongo y van a tragar menos memoria. en cualquier otro escenario donde tus datos te importan siquiera mínimamente, mongolongo va a ser más lento (que psql). y si me hablas de high volume time-series, oooooohhhhhhhhhhh, amigo mongolongo, ahí timescale (psql con una extensión por encima) domina mongolongo como la dominatrix de tailandia que te dominó en tu despedida de soltero. El indice de mongolongo se cagaría encima y la presión de ram (y luego, cuando esté tragando mas ram que chrome con 900 pestañas, de IO) lo convertirían es un caracol tetrapléjico. > si necesitas escalado horizontal, el sharding es facilísimo hiiiiiiiiiiiiiiiiiiiiijo de cien mil trillones de volquetes de hienas. hay que ser mongolongo malintencionado, malandrín perverso y troll de mala baba para soltar semejante zurraspa verbal. en mongolongo, como hagas el sharding mal, la única manera de arreglar el error es graparte los cojones al escritorio y saltar con todas tus fuerzas. eso, o crear una nueva colección y copiar toooooooooooooooodos los datos de la vieja a la nueva + cambiar la lógica de tu app para que escriba en ambas colecciones hasta que termines de hacer el cambio + buena suerte con la integridad. > cuando necesitas velocidad de desarrollo mongolongo te da flexibilidad la flexibilidad de la que hablas es "ponte a picar incoherencias y guárdalas en la base de datos sin planificar absolutamente ningún tipo de estructura". Tu mismo caes en el marketing barato de invitar al slop-driven development, donde no pararte a pensar 30m en la estructura de los datos de alguna manera compensa las decenas de horas que vas a tardar en depurar todo el caos creado porque en cada prueba que has hecho has guardado una bola distinta de esquizofrenia mezclada con jack daniels. No se en que momento no pensar en como se van a relacionar tus datos y explorar posibles inconsistencias se ha convertido en algo deseable y recomendable. esto es lo equivalente a soltar un "no te pongas a pensar en como estructurar tu código, mete todo en un archivo porque eso te da flexibilidad y velocidad".