En mongoDB3 apareció un nuevo motor de almacenamiento: WiredTiger . Sin embargo, MMAPv1 sigue siendo la opción predeterminada en Mongo .

Uno puede no ser mejor que el otro, a menudo es una cuestión de uso y elegir la herramienta adecuada para el trabajo. ¿Pero qué motor es el adecuado para cada trabajo?

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

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

Encontré una tabla de comparación 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 de WiredTiger y MMAPv1 .

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 es bien entendido y probado en la batalla de arriba a abajo, de ida y vuelta y más allá. WiredTiger ha tenido algunos problemas serios (vea http://jira.mongodb.com para más detalles) hace poco, y no estoy dispuesto a que mis clientes encuentren el próximo de la manera difícil.

Razón 2: características

Dado, WT tiene algunas características increíblemente increíbles. La cuestión es: no he visto a nadie que se beneficie de ellos. ¿Compresión? De cualquier manera, sacrificas bastante duro para lograr el rendimiento por un espacio en disco bastante barato. ¿Falta el problema de migración de documentos para expandir documentos? Bueno, todavía tenemos el límite de tamaño de 16 MB y la complejidad adicional para los documentos incrustados, especialmente cuando la incrustación está exagerada.

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

Razón 3: costo total de propiedad

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

Hacer migraciones de datos es costoso. Debe planificarse, el plan debe ser acordado por todos los interesados, los planes de contingencia de emergencia deben crearse y acordarse, 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 disparan. El retorno de la inversión, por otro lado, parece bastante pequeño. Puede escalar bastante en lugar de hacer una migración si tiene en cuenta esos factores. Para darle una impresión: estimaría aproximadamente una "semana-hombre" por parte interesada si una 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 asciende a $ 12,000. Tenga en cuenta que esta es una estimación conservadora.

Conclusión

Todos los factores anteriores me han llevado a la conclusión de no usar WT en absoluto. En el momento.

Actualizar

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

En 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 aún tienen cierta validez, en mi humilde opinión.

Compresión

Sin embargo, cuando se trata de un 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 pequeños 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 tener encriptados los almacenes WiredTiger. Para los datos con necesidades de seguridad mejoradas, esta es una característica excelente y hace que WT sea el único motor de almacenamiento elegido, tanto técnicamente (MMAPv1 no admite cifrado) como conceptual. Dejando de lado la posibilidad de particiones de disco encriptadas, por supuesto, aunque es posible que no tenga esa opción en algunos entornos.

Nivel de documento bloqueado

Tengo que 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 concurrentes, esta característica puede proporcionar un gran aumento de rendimiento.

Sobre el costo total de propiedad

Hacer migraciones sigue siendo costoso. Sin embargo, teniendo en cuenta los cambios en la madurez y la vista modificada de 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 absoluta y puede ahorrar dinero a largo plazo (calcular de forma conservadora) utilizando la compresión
• Tiene muchos procesos escribiendo simultáneamente, ya que el aumento en el rendimiento puede ahorrarle escala vertical u horizontal.

Conclusión actualizada

Para nuevos proyectos, uso WiredTiger ahora. 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 experiencia de usuario, migro a WiredTiger sin comprimir.

Para proyectos con muchos escritores concurrentes, la respuesta a si migrar o no es casi siempre "Sí", a menos que el presupuesto del proyecto prohíba la inversión. A la larga, el aumento del rendimiento debería pagarse solo, si la implementación se planificó razonablemente. Sin embargo, debe agregar algo de tiempo de desarrollo al cálculo, ya que en algunos casos el controlador debe actualizarse, y puede haber problemas que deben abordarse.

Para proyectos que tienen poco presupuesto 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 pone un poco de carga en la CPU, algo inaudito con MMAPv1. Además, los costos de migración pueden ser prohibitivamente costosos para dicho proyecto.

Mis dos centavos:

El registro en diario en WiredTiger puede perder actualizaciones en los apagados duros porque utiliza el almacenamiento en búfer en memoria para almacenar los registros del diario.

Entre las operaciones de escritura, mientras los registros del diario permanecen en los búferes WiredTiger, las actualizaciones se pueden perder después de un cierre de mongod.

El registro en diario en MMAPv1 escribe los cambios en los archivos de registro en disco.

Si la instancia de mongod se bloqueara sin haber aplicado las escrituras a los archivos de datos, el diario podría reproducir las escrituras en la vista compartida para una eventual escritura en los archivos de datos.

Cambiamos a WiredTiger de MMAPv1 con el atractivo de una ganancia de rendimiento de 7x a 10x. Tuvimos que volver a MMAPv1 ya que MongoDB se bloquearía cuando el caché de WiredTiger alcanzara el 100%. Hemos documentado nuestra experiencia aquí: https://blog.clevertap.com/sleepless-nights-with-mongodb-wiredtiger-and-our-return-to-mmapv1/