Volcamos los registros de transacciones y depuración en MongoDB.
Nos gusta mucho MongoDBporque:
- Rendimiento de inserción ardiente
- orientado a documentos
- Capacidad para dejar que el motor suelte insertos cuando sea necesario para mejorar el rendimiento
Pero existe un gran problema MongoDB: el índice debe caber en la RAM física. En la práctica, esto nos limita a 80-150 GB de datos sin procesar (actualmente ejecutamos un sistema con 16 GB de RAM).
Entonces, para que tengamos 500 GB o un tb de datos, necesitaríamos 50 gb u 80gb de RAM.
Sí, sé que esto es posible. Podemos agregar servidores y usar MongoDB sharding. Podemos comprar una caja de servidor especial que puede soportar 100 o 200 GB de RAM, ¡pero esto es la cola que mueve al perro! Podríamos gastar mucho dinero en hardware para ejecutarlo FOSS, cuando SQL Server Express puede manejar MUCHO más datos en MUCHO menos hardware que Mongo(SQL Server no satisface nuestros deseos arquitectónicos, ¡o lo usaríamos!). No vamos a gastar mucho. $ en hardware aquí, porque es necesario sólo por la Mongoarquitectura, no por las necesidades inherentes de procesamiento/almacenamiento. (¿Y la fragmentación? Dejando de lado los costos, ¿quién necesita la complejidad constante de tres, cinco o más servidores para administrar una carga relativamente pequeña?)
En pocas palabras: MongoDBlo es FOSS, pero ¿tenemos que gastar $$$$$$$ en hardware para ejecutarlo? ¡Preferimos comprar software comercial!
Estoy seguro de que no somos los primeros en enfrentar este problema, por eso le preguntamos a la comunidad:
¿A dónde vamos después?
(Ya ejecutamos Mongo v2)
Respuesta1
Si se encuentra en un punto en el que el rendimiento actual es demasiado lento o se alcanzan los límites, tiene tres opciones. Y son válidos para cualquier problema.
- Escalar verticalmente: Significa aumentar la potencia de su máquina. Más CPU o más RAM.
- Escalar horizontalmente: Es decir, aumentar la cantidad de trabajadores. Más procesos, más hilos, más máquinas.
- Cambiar diseño: Hazlo diferente. Otro software, otros algoritmos, otro sistema de almacenamiento, otro lo que sea.
Como excluiste 1) y 2) de tus opciones, solo queda la solución 3). Así que adelante...
Respuesta2
Publicamos esta misma pregunta en el foro de Mongo y el CTO de Mongo respondió diciendo que revisemos su presentación sobre cómo optimizar los índices.
http://www.10gen.com/presentations/mongosf2011/schemascale
En esta presentación, el Sr. Horowitz afirma explícitamente que la fragmentación/escalado horizontal puede ser excesivo en muchas situaciones, y que los enfoques de diseño (incluidos algunos enfoques bastante no intuitivos que son específicos de Mongo) pueden hacer que un servidor determinado escale mucho más.
Esto presentó algunos conceptos interesantes, incluido el uso de la lógica del lado del cliente para optimizar cómo se usa la base de datos en varias formas "no normalizadas". Hay un subtexto claro en la presentación en el sentido de "si simplemente construyes según el libro, puedes encontrar fácilmente problemas no deseados relacionados con el escalado". Por ejemplo, el Sr. Horowitz (el CTO de 10Gen, creador de MongoDB) presenta un diseño "híbrido" en el que en lugar de un documento por "registro", se colocan quizás 100 "registros" en un documento, lo que da como resultado un tipo de "cubo". de acercamiento. Esto se hace explícitamente para reducir la huella del índice. Esto es algo que está codificado en el cliente y no es una "característica" de MongoDB. Este enfoque híbrido puede funcionar para nosotros y podría brindarnos una mejora de 4 u 8 veces en el tamaño del índice.
También analiza los btrees "equilibrados a la derecha", que básicamente optimizan el diseño del índice para que la mayoría de las consultas accedan sólo a la "parte derecha" del índice (a diferencia del acceso aleatorio a través del índice, que, para funcionar bien, requiere que el todo el índice cabe en la RAM). Este enfoque no nos ayudará, ya que necesitamos consultar todo el índice.
Vamos a utilizar estos conceptos como parte de una revisión de nuestro sistema.
(Es interesante que de todos los lugares donde publiqué esta pregunta, la única persona con una respuesta constructiva es el CTO de MongoDB).
ACTUALIZACIÓN (2017)
En última instancia, descubrimos que Mongodb no era apropiado en un entorno de producción. Cada dos meses, descarga/desecha toda la base de datos y se pierden todos los datos. (No es una fuente de datos primaria, por lo que podemos vivir con el problema, aunque no felices).
Ahora hemos completado un proyecto para pasar a la pila de elasticsearch y ahora lo estamos llevando a producción. (Hemos utilizado elasticsearch con éxito durante años). Los datos de Elasticsearch no son tan duraderos como, por ejemplo, Microsoft SQL Server (hemos tenido clústeres de elasticsearch que fallaron con una pérdida de datos irrecuperable), pero elasticsearch es al menos 10 veces mayor (por experiencia, más de 100 veces). ) más confiable que Mongodb. (Elasticsearch, inteligentemente, no pretende admitir Windows como plataforma de producción, uno de los grandes pecados de Mongodb).
Esperamos haber eliminado todo nuestro entorno de Mongodb en las próximas semanas.
¡Adelante!
ACTUALIZACIÓN (2018-2019)
La pila de elasticsearch ha cumplido. Hemos descubierto que es muy confiable, muy escalable y no hemos mirado atrás en absoluto. Mongo olía muy bien en ese momento, pero hace años que desapareció, y que se vaya. Hemos estado ejecutando dos clústeres elásticos, uno para datos de registro (que reemplazó a nuestro servidor Mongo) y un segundo para datos de aplicaciones reales. Cada clúster tiene entre 1 y 2 TB de datos. tomó unlotedel trabajo de arquitectura (particularmente en el lado de la aplicación) para volverse elástico tanto en escala como en rendimiento, pero lo logra.
Respuesta3
Es posible que no le gusten las respuestas a su problema de "escalamiento" porque en realidad no tiene un problema de escala; tiene un problema de diseño e implementación. No estás indexando de manera eficiente.
En serio, si cree que es absolutamente necesario mantener índices de ese tamaño, tendrá el mismo problema de mantener índices abominablemente enormes en la RAM en cualquier producto de base de datos que busque. Tendría que comprar un servidor de alta capacidad (DL380 G7 puede hacerlo, y es un servidor básico de rango medio; nada exótico) para almacenar esos índices.
A modo de ayuda, una búsqueda de "índices de optimización de mongodb" arroja varios enlaces útiles:
http://www.mongodb.org/display/DOCS/Optimization
http://www.10gen.com/events/indexingmatters
http://www.deanlee.cn/programming/mongodb-optimize-index-avoid-scanandorder/
http://www.slideshare.net/kbanker/mongo-indexoptimizationprimer
Puede que te pongas a la defensiva por haber hecho tu investigación, pero los que usamos MongoDB en Producción sabemos que te faltan muchos puntos.
Además, el comentario "En pocas palabras: MongoDB es software libre, pero ¿tenemos que gastar $$$$$$$ en hardware para ejecutarlo? ¡Preferiríamos comprar software comercial!" Gritos de ignorancia y arrogancia.
Respuesta4
¿Por qué diría "SQL Server Express puede manejar MUCHO más datos en MUCHO menos hardware que Mongo (SQL Server no satisface nuestros deseos arquitectónicos, o lo usaríamos!)". Si necesita cambiar la arquitectura de su base de datos (dado que su otra base de datos no puede escalarse como la necesita y usaría el servidor SQL, la respuesta para mí es arreglar el diseño de su base de datos para que funcione con el servidor SQL. Lo único que puedo Se puede pensar que eso no es "reparable" si realmente desea una base de datos sin ACID (lo que me parecería extraño que las inserciones de registro de transacciones y depuración estén bien para eliminarse)