mysql json vs mongo - storage space

Question

我正在经历一个有趣的情况，尽管这不是一个实际的问题，但我不明白为什么会发生这种情况。

我们有一个mongo数据库，主要由存储在数组中的一些批量数据组成。由于团队中超过90%的人熟悉mysql，而我们中只有几个人熟悉mongo，再加上它不是一个关键的数据库，并且所有查询都是在两个字段(客户端或产品)上完成的，我们决定在mysql中移动数据，在一个像这样的表中。

[idProduct (bigint unsigned), idClient (bigint unsigned), data (json)]

其中data是一个巨大的json，包含数百个属性及其值。

我们还通过idClient上的散列将分区划分为100个分区。

PARTITION BY HASH(idClient)
PARTITIONS 100;

一切都很好，但我注意到一个有趣的事实：

最初的mongo数据库大约有70 GB，或多或少。mysql版本(实际上包含更少的数据，因为re删除了一些我们在mongo中用作索引的重复项)有超过400 GB的空间。

为什么它要占用这么多的空间？理论上，bson实际上应该比json稍大一些(至少在大多数情况下是这样)。即使mysql中的索引更大...差异是巨大的(超过5倍)。

Answer 1

我做了一个演示How to Use JSON in MySQL Wrong (video)，在其中我将Stack Overflow数据转储导入到MySQL中的JSON列中。我发现我测试的数据占用的空间是使用常规数据类型导入普通表和列的2倍到3倍。

JSON为相同的数据使用了更多的空间，例如，因为它将整数和日期存储为字符串，还因为它将键名存储在每一行上，而不是只在表头中存储一次。

这是将MySQL中的JSON与MySQL中的普通列进行比较。我不确定MongoDB是如何存储数据的，也不知道为什么它这么小。我读到MongoDB的WiredTiger引擎支持压缩和snappy compression is enabled by default since MongoDB 3.0选项。也许你应该启用compressed format in MySQL，看看它是否能提供更好的存储效率。

MySQL中的JSON像文本/BLOB数据一样存储，因为它被映射到一组16KB的页面中。对于前32页，一次分配一个页(即最多512KB)。如果内容超过这个长度，则以64页(1MB)为增量进行进一步的分配。因此，如果单个文本/BLOB/JSON内容是513KB，它可能会分配1.5MB。

Answer 2

嗨，我认为主要原因可能是因为Mongo内部将json存储为bson ( http://bsonspec.org/ )，并且在规范中强调这种表示是轻量级的。

Answer 3

默认情况下，MongoDB中的WiredTiger存储引擎使用compression。我不知道MySQL的默认行为。

与MySQL不同，MongoDB被设计为存储JSON/BSON，实际上它不存储任何其他内容。因此，这种“竞争”对于像文本/BLOB数据一样存储JSON的MySQL来说可能有点不公平。

如果你有关系数据，也就是基于列的值，那么正如@Bill Karwin所说的，MySQL很可能会更小。但是，使用MongoDB中的smart bucketing可以显著减小数据大小。