Ser esquemático es una de las características clave de MongoDB. En el lado positivo, esto permite a los desarrolladores modificar fácilmente el esquema de sus colecciones sin esperar a que la base de datos esté lista para aceptar un nuevo esquema. Sin embargo, schemales no es gratuito y uno de los inconvenientes es la amplificación de la escritura. Centrémonos en este tema.

¿Escribes la amplificación?

El vínculo entre el esquema y la amplificación de escritura no es obvio a primera vista. Así que primero veamos una tabla en el mundo relacional:

Dado que todos los registros tienen exactamente los mismos campos, los nombres de los campos se guardan una vez en un archivo separado (archivo .frm). Entonces, los nombres de los campos son metadatos, mientras que el valor de cada campo para cada registro es, por supuesto, datos.

Ahora veamos una colección equivalente en MongoDB:

Una diferencia con una tabla en el mundo relacional es que MongoDB no sabe qué campos contendrá cada documento. Por lo tanto, se dan los nombres de los campos, no los metadatos, y deben guardarse con cada documento.

Entonces, la pregunta es: ¿qué tan grande es la sobrecarga en términos de espacio en disco? Para tener una idea, inserté 10M de esos discos en una tabla InnoDB (agregando un índice en la contraseña y en birth_year para que la tabla pareciera una tabla real): el tamaño del disco es alrededor. 1,4 GB.

También inserté exactamente los mismos 10 millones de discos en una colección MongoDB usando el motor de almacenamiento MMAPv1 normal, volviendo a agregar un índice en la contraseña y en birth_year, y esta vez el tamaño del disco es… 2,97 GB!

Por supuesto, esta no es una comparación de manzanas con manzanas, ya que el formato de almacenamiento InnoDB y el formato de almacenamiento MongoDB no son idénticos. Sin embargo, una diferencia del 100% sigue siendo significativa.

Compresión

Una forma de lidiar con la amplificación de la escritura es usar la compresión. Con MongoDB 3.0, usted tigre con cable El motor de almacenamiento está disponible y una de sus ventajas es la compresión (algoritmo predeterminado: rápido). Percona TokuMX también tiene compresión incorporada con zlib por defecto.

La reconstrucción de la colección con 10 millones de documentos y 2 índices ahora arroja los siguientes resultados:
Tigre con cable: 1,14 GB
TokuMX: 736 MB

Esta es una reducción del tamaño de los datos de 2,5x a 4x, ¡muy bien!

WiredTiger también proporciona compresión zlib y, en este caso, la colección es solo eso. 691 megabytes. Sin embargo, el uso de la CPU es mucho mayor en comparación con Snappy, por lo que zlib no se podrá utilizar en todas las situaciones.

Conclusiones

El diseño impecable de MongoDB es atractivo, pero viene con varios intercambios. La amplificación de escritura es una de ellas y usar WiredTiger con MongoDB 3.0 o Percona TokuMX es una forma muy sencilla de resolver el problema.