MongoDB MMAPv1 frente a los motores de almacenamiento WiredTiger

Question

En mongoDB3 apareció un nuevo motor de almacenamiento: Tigre cableado. Todavía, MMAPv1 sigue siendo la opción predeterminada en Mongo.

Puede que uno no sea mejor que el otro; a menudo es una cuestión de caso de uso y de elegir la herramienta adecuada para el trabajo.¿Pero qué motor es el adecuado para cada trabajo?

De hecho, mientras que MMAPv1 es el motor predeterminado, WiredTiger parece mejor en casi todos los campos.Tiene las mismas características que MMAPv1 más:

• mejor rendimiento de escritura,
• simultaneidad a nivel de documento,
• compresión,
• Sistema de instantáneas y puntos de control.

Encontré una tabla comparativa en El blog de MongoDB:

Entonces, excepto si está en Solaris, ¿hay alguna razón para no elegir WiredTiger?

---

EDITAR

Aquí hay dos videos que explican en detalle los aspectos internos deTigre cableado y MMAPv1.

Answer 1

Personalmente, prefiero el motor de almacenamiento mmapv1 a partir de ahora por tres razones.

Razón 1:Madurez

No es que WiredTiger sea inmaduro.Pero mmapv1 se entiende bien y se prueba en batalla de arriba a abajo, de ida y vuelta y más allá.WiredTiger ha tenido algunos problemas serios (ver http://jira.mongodb.com para más detalles) bastante recientemente, y no estoy dispuesto a que mis clientes encuentren el siguiente por las malas.

Razón 2:Características

Dado, WT tiene algunos f...características absolutamente impresionantes.La cosa es:No he visto a nadie beneficiarse de ellos.¿Compresión?De cualquier manera, sacrifica bastante para lograr rendimiento por espacio en disco bastante barato.¿Falta el problema de migración de documentos para ampliar documentos?Bueno, todavía tenemos el límite de tamaño de 16 MB y una mayor complejidad para los documentos incrustados, especialmente cuando la incrustación es excesiva.

Hay otras características, pero en general:No les veo mucho beneficio a partir de ahora.

Razón 3:Costo total de la propiedad

Para proyectos nuevos, WT podría estar bien, especialmente desde 3.2, ya que lo siguiente no se aplica.

Hacer migraciones de datos es caro.Es necesario planificarlo, el plan debe ser acordado por todas las partes interesadas, deben crearse y acordarse planes de contingencia de emergencia, la migración debe prepararse, ejecutarse y revisarse.Ahora multiplique el tiempo necesario con las partes interesadas que forman parte de este proceso y los costos de la migración de datos se dispararán.Por otra parte, el retorno de la inversión parece bastante pequeño.Puedes escalar bastante en lugar de realizar una migración si tienes en cuenta esos factores.Para darte una impresión:Calculo aproximadamente una "semana-hombre" por parte interesada si la migración se planifica, ejecuta y revisa adecuadamente.Con costos de $100 por hora por persona, y solo tres personas involucradas (gerente, DBA y desarrollador), eso equivale a $12.000.Tenga en cuenta que esta es una estimación conservadora.

Conclusión

Todos esos factores anteriores me han llevado a la conclusión de no utilizar WT en absoluto. En este momento.

---

Actualizar

Esta publicación tiene algunos meses, por lo que merece una actualización.

Sobre la madurez

Mis comentarios originales sobre la madurez son algo obsoletos.WiredTiger no ha tenido problemas importantes desde hace un tiempo y se ha convertido en el motor de almacenamiento predeterminado a partir de MongoDB 3.2.

En características

Mis comentarios originales todavía tienen cierta validez, en mi humilde opinión.

Compresión

Sin embargo, cuando el presupuesto ajustado o, en términos más generales, el rendimiento no es la principal preocupación, la compensación del rendimiento es bastante pequeña y básicamente se intercambian ligeros impactos en el rendimiento (en comparación con WT sin comprimir) por espacio en disco, utilizando lo que de otro modo estaría inactivo. alrededor:la CPU.

Cifrado

MongoDB 3.2 Enterprise introdujo la capacidad de cifrar los almacenamientos de WiredTiger.Para datos con necesidades de seguridad mejoradas, esta es una característica excelente y convierte a WT en el único motor de almacenamiento de elección, tanto técnicamente (MMAPv1 no admite cifrado) como conceptualmente.Dejando de lado la posibilidad de particiones de disco cifradas, por supuesto, aunque es posible que no tengas esa opción en algunos entornos.

Bloqueo a nivel de documento

Debo admitir que básicamente omití esa característica de WT en mi análisis anterior, principalmente porque no se aplicaba a mí ni a mis clientes cuando escribí la respuesta original.

Dependiendo de su configuración, principalmente cuando tiene muchos clientes de escritura simultáneos, esta función puede proporcionar una gran mejora en el rendimiento.

Sobre el coste total de propiedad

Hacer migraciones sigue siendo caro.Sin embargo, teniendo en cuenta los cambios en la madurez y el cambio de visión sobre las características, una migración podría valer la inversión si:

• Necesita cifrado (¡solo Enterprise Edition!)
• El rendimiento no es su principal preocupación y puede ahorrar dinero a largo plazo (calcule de forma conservadora) utilizando la compresión.
• Tiene muchos procesos escribiendo simultáneamente, ya que el aumento en el rendimiento podría ahorrarle el escalado vertical u horizontal.

Conclusión actualizada

Para nuevos proyectos, ahora uso WiredTiger.Dado que la migración de un almacenamiento WiredTiger comprimido a uno sin comprimir es bastante fácil, tiendo a comenzar con la compresión para mejorar la utilización de la CPU ("obtener más por el dinero").Si la compresión tiene un impacto notable en el rendimiento o la UX, migro a WiredTiger sin comprimir.

Para proyectos con muchos escritores simultáneos, la respuesta a si migrar o no es casi siempre "Sí", también, a menos que el presupuesto del proyecto prohíba la inversión.A largo plazo, el aumento del rendimiento debería amortizarse por sí solo, si la implementación se planificó razonablemente.Sin embargo, es necesario añadir algo de tiempo de desarrollo al cálculo, ya que en algunos casos es necesario actualizar el controlador y es posible que haya problemas que deban solucionarse.

Para proyectos que tienen un presupuesto ajustado y no pueden permitirse más espacio en disco por el momento, migrar a un WiredTiger comprimido puede ser una opción, pero la compresión supone un poco de carga para la CPU, algo inaudito con MMAPv1.Además, los costos de migración podrían ser prohibitivamente elevados para un proyecto de este tipo.

Answer 2

Mis dos centavos:

diario en wiretiger Puede perder actualizaciones en paradas duras porque utiliza búferes en memoria para almacenar los registros de la revista.

entre operaciones de escritura, mientras que los registros de la revista permanecen en el WiredTiger Buffers, las actualizaciones se pueden perder después de un apagado duro de mongod.

diario en mmapv1 Escribe cambios en los archivos de diario en disco.

Si la instancia de Mongod se bloqueó sin haber aplicado las escrituras a los archivos de datos, la revista podría reproducir las escrituras al compartido Ver para la escritura eventual a los archivos de datos.

Answer 3

Nos trasladamos a WiredTiger desde MMAPV1 en el señuelo de 7x a 10x.Tuvimos que volver a volver a MMAPV1, ya que Mongodb se bloquearía cuando el caché de WiredTiger golpeara al 100%.Hemos documentado nuestra experiencia aquí - >https://blog.clevertap.com/slogepless-nights-with-mongodb-wiredtiger-and-our-return-to-mmmapv1/