Estoy experimentando una situación interesante y, aunque no es un problema real, no puedo entender por qué sucede esto.
Teníamos una base de datos mongo, que constaba principalmente de algunos datos masivos almacenados en una matriz. Debido al hecho de que más del 90% del equipo estaba familiarizado con mysql mientras que solo unos pocos de nosotros estábamos familiarizados con mongo, combinado con el hecho de que no es una base de datos crítica y todas las consultas se realizan en 2 de los campos (cliente o producto ) decidimos mover los datos en mysql, en una tabla como esta
[idProduct (bigint unsigned), idClient (bigint unsigned), data (json)]
Donde data es un json enorme que contiene cientos de atributos y sus valores.
También particionamos en 100 particiones mediante un hash sobre idClient.
PARTITION BY HASH(idClient) PARTITIONS 100;Todo funciona bien, pero noté un hecho interesante:
El mongo db original tenía alrededor de 70 GB, más o menos. La versión mysql (que en realidad contiene menos datos porque eliminó algunos duplicados que estábamos usando como índices en mongo) tiene más de 400 GB.
¿Por qué ocupa mucho más espacio? En teoría, bson debería ser un poco más grande que json (al menos en la mayoría de los casos). Incluso si los índices son más grandes en mysql... la diferencia es enorme (más de 5x).
Hice una presentación How to Use JSON in MySQL Wrong ( video ), en la que importé el volcado de datos de Stack Overflow en columnas JSON en MySQL. Descubrí que los datos con los que probé ocupaban de 2 a 3 veces más espacio que importar los mismos datos en tablas y columnas normales usando tipos de datos convencionales para cada columna.
JSON usa más espacio para los mismos datos, por ejemplo, porque almacena números enteros y fechas como cadenas, y también porque almacena nombres clave en cada fila, en lugar de solo una vez en el encabezado de la tabla.
Eso es comparar JSON en MySQL con columnas normales en MySQL. No estoy seguro de cómo MongoDB almacena datos y por qué es mucho más pequeño. He leído que el motor WiredTiger de MongoDB admite opciones de compresión, y la compresión rápida está habilitada de forma predeterminada desde MongoDB 3.0 . Tal vez debería habilitar el formato comprimido en MySQL y ver si eso le brinda una mejor eficiencia de almacenamiento.
JSON en MySQL se almacena como datos de TEXTO/BLOB, ya que se asigna a un conjunto de páginas de 16 KB. Las páginas se asignan de una en una para las primeras 32 páginas (es decir, hasta 512 KB). Si el contenido es más largo que eso, la asignación adicional se realiza en incrementos de 64 páginas (1 MB). Por lo tanto, es posible que si un solo contenido de TEXTO/BLOB/JSON es, digamos, 513 KB, asignaría 1,5 MB.
Hola, creo que la razón principal podría deberse al hecho de que internamente Mongo almacena json como bson ( http://bsonspec.org/ ) y en las especificaciones se destaca que esta representación es liviana.
El motor de almacenamiento WiredTiger en MongoDB usa compresión de forma predeterminada. No sé el comportamiento predeterminado de MySQL.
A diferencia de MySQL, MongoDB está diseñado para almacenar JSON/BSON, en realidad no almacena nada más. Por lo tanto, este tipo de "competencia" podría ser un poco injusto para MySQL, que almacena datos JSON como TEXT/BLOB.
Si tuviera datos relacionales, es decir, valores basados en columnas, lo más probable es que MySQL sea más pequeño, como lo indica @Bill Karwin. Sin embargo, con el almacenamiento inteligente en MongoDB, puede reducir significativamente el tamaño de los datos.