我遇到了一个有趣的情况，虽然不是一个实际的问题，但我不明白为什么会发生这种情况。
我们有一个 mongo 数据库，主要由存储在数组中的一些批量数据组成。由于团队中超过 90% 的人熟悉 mysql，而只有少数人熟悉 mongo，再加上这不是关键数据库，所有查询都是在 2 个字段（客户端或产品）上完成的）我们决定将数据移到mysql中，在这样的表中
[idProduct (bigint unsigned), idClient (bigint unsigned), data (json)]
其中 data 是一个巨大的 json，包含数百个属性及其值。
我们还通过 idClient 上的哈希将其划分为 100 个分区。
PARTITION BY HASH(idClient)
PARTITIONS 100;
一切正常，但我注意到一个有趣的事实：
原始的 mongo 数据库大约有 70 GB，或多或少。 mysql 版本（实际上包含较少的数据，因为重新删除了我们在 mongo 中用作索引的一些重复项）超过 400 GB。
为什么它需要这么多空间？理论上bson实际上应该比json略大（至少在大多数情况下）。即使 mysql 中的索引更大...差异也是巨大的（超过 5 倍）。
我做了一个演示如何在 MySQL 中错误地使用 JSON https://www.slideshare.net/billkarwin/how-to-use-json-in-mysql-wrong (video https://www.percona.com/resources/videos/how-use-json-mysql-wrong），其中我将 Stack Overflow 数据转储导入到 MySQL 中的 JSON 列中。我发现我测试的数据比使用每列的常规数据类型将相同数据导入到普通表和列中所占用的空间多出 2 到 3 倍。
JSON 对相同的数据使用更多的空间，例如，因为它将整数和日期存储为字符串，还因为它在每一行上存储键名称，而不是只在表头中存储一次。
这是将 MySQL 中的 JSON 与 MySQL 中的普通列进行比较。我不确定 MongoDB 如何存储数据以及为什么它要小得多。我读到 MongoDB 的 WiredTiger 引擎支持压缩选项，并且从 MongoDB 3.0 开始默认启用 snappy 压缩 https://www.mongodb.com/blog/post/new-compression-options-mongodb-30。也许你应该启用MySQL 中的压缩格式 https://dev.mysql.com/doc/refman/8.0/en/innodb-row-format.html看看这是否可以提高存储效率。
MySQL 中的 JSON 存储方式类似于 TEXT/BLOB 数据，因为它被映射到一组 16KB 的页面中。前 32 页（即最多 512KB）一次分配一个页。如果内容长于此，则以 64 页 (1MB) 为增量进行进一步分配。因此，如果单个 TEXT/BLOB/JSON 内容为 513KB，则可能会分配 1.5MB。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
