MongoDB MMAPv1 vs motores de almacenamiento WiredTiger


25

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 :

Comparación de WiredTiger y MMAPv1

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 .


Todas las personas aquí ... pueden visitar blog.clevertap.com/… para una muy buena explicación sobre el tema
therealprashant

Respuestas:


26

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.


Gracias Markus por tu respuesta. Entiendo tus argumentos. ¿Recomendaría incluso volver a MMAPv1 por defecto para nuevos proyectos? Quiero decir, si el rendimiento es una preocupación, la compresión también se puede desactivar por completo. El espacio en disco es económico, pero la compresión puede ayudar a que el conjunto de trabajo se ajuste en la RAM ... y, por lo tanto, gane rendimiento. ¿O estoy equivocado?
Buzut

1
Hasta donde sé, la compresión solo se aplica a los archivos de datos. En cuanto a los nuevos proyectos, permítanme decirlo así: pediría una decisión de gestión, mostrando ventajas y desventajas. Personalmente utilizo WT en uno de mis proyectos y todavía no tuve problemas, pero podría haber otros factores como SLA (que puedo calcular bastante bien en función de la experiencia con mmapv1), presupuestos ajustados (lo que requeriría WT comprimido para ahorrar espacio en disco) y muchos otros factores. Sopesar los riesgos y las oportunidades no es una decisión de los DBA. Un DBA tiene que proporcionar la información necesaria para hacer una llamada.
Markus W Mahlberg

1
Este artículo parece indicar que la forma en que se almacenan los índices es un beneficio bastante grande porque puede reducir el espacio que ocupan sus índices en 10 veces: ilearnasigoalong.blogspot.com/2015/03/… . El espacio en disco es barato, pero el ram no lo es.
BT

Estoy un poco confundido acerca de su punto en Características, ¿está diciendo que hay características que MMAPv1 tiene que WiredTiger no tiene? Sería bueno si esa sección fuera un poco más clara.
BT

@BT en absoluto. Lo que estaba tratando de decir es que WT tiene algunas características geniales que para algunos casos de uso pueden ser útiles, pero en general no lo son. Prefiero un motor de almacenamiento probado en batalla sobre la vanguardia cuando se trata de almacenamiento de datos. Según el artículo: Sí, es posible con la compresión del prefijo ahorrar RAM, y esta podría ser una buena idea si no hubiera otra preocupación. Imagine que podría ser considerado confiable por pérdida de datos o problemas de rendimiento.
Markus W Mahlberg

5

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.


4

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/


2
Buen artículo. Me recuerda un poco a Uber que pasó de MySQL a PostgreSQL en 2013 y luego regresó a MySQL en junio de 2016.
RolandoMySQLDBA

así se explica también tenemos misma experiencia con el tigre por cable para que revreted a MMAPV1
viren
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.