Json 到 mariadb 的存储大小增加了三倍答案

【问题标题】：Json to mariadb triples in storage sizeJson 到 mariadb 的存储大小增加了三倍
【发布时间】：2020-01-13 11:09:26
【问题描述】：

我正在尝试将基于组织 json 文件的文件移动到 mariadb。在我的基于文件的系统中，大约有 2,000,000 个 json 文件被压缩。压缩后的 json 文件的总存储空间为 7GB。

当我将所有记录插入 Mariadb 时，表存储空间变为 35GB。我将我的表格更改为压缩表格，表格大小为 15GB。有没有办法进一步减小表格大小？

向mariadb添加数据时存储翻倍正常吗？

这是我的桌子

CREATE TABLE `sbpi_json` (
  `fileid` int(11) NOT NULL,
  `json_data` longtext COLLATE utf8_bin NOT NULL,
  `idhash` char(32) COLLATE utf8_bin NOT NULL,
  `sbpi` int(15) NOT NULL,
  `district` int(2) NOT NULL,
  `index_val` int(2) NOT NULL,
  `updated` text COLLATE utf8_bin NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin ROW_FORMAT=COMPRESSED;

ALTER TABLE `sbpi_json`
  ADD PRIMARY KEY (`fileid`),
  ADD UNIQUE KEY `idhash` (`idhash`),
  ADD KEY `sbpi` (`sbpi`);

【问题讨论】：

文件系统中json文件的编码是什么？更新的字段是什么？ 16GB - 是仅用于数据的空间还是包括各种 MySQL 日志文件以及 innodb？
json 文件是 UTF-8。更新的字段用于重复的 mysql。更新字段的字符少于 10 个。
"mariadb 中添加数据时存储量翻倍正常吗？" 无法将磁盘上压缩的“文本”文件与 innoDB 文件进行比较，两者都可以解决不同的问题...您还在比较不同的压缩算法...此外，在 InnoDB 中，您添加更多列，并且 innoDB 引擎将添加有关如何使用/读取存在记录的信息并添加记录标题。
我进行这种从基于文件到 mariadb 的传输的主要原因是性能。我使用 php 脚本访问文件并将其回显给用户，但我注意到有很大的延迟（获取 zip、解压缩、找到最新的 json 文件并回显它）。加快进程的替代解决方案是迁移到 mariadb，但存储空间显着增加。欢迎提出任何最小化存储大小的建议
为什么不单独压缩文件？那么你的流程就是：查找、解压、回显

标签： mysql json mariadb storage space

【解决方案1】：

有问题的 JSON 列是 json_data，对吗？它平均（未压缩）大约 10KB，对吗？在文件实现中，每个都有多个“版本”，对吗？如果是这样，您如何确定要交付给用户的是哪一个？

大多数压缩技术为您提供 3:1； InnoDB 压缩为您提供 2:1。这部分是因为它有一些不能（或不会）压缩的东西。
仅压缩 JSON 列（在客户端代码中）并将其存储在 MEDIUMBLOB 中可能会比使用 COMPRESSED 在 InnoDB 中占用更少的空间。（但这不会节省大量资金。）
关注如何选择 JSON 的哪个“版本”交付给用户。围绕它优化架构。然后决定如何存储数据。
鉴于该表可以有效地说明哪个文件包含所需的 JSON，那么这将是最好的方法。并使用一些正常的、快速解压缩的技术；不要专注于最大压缩。
如果char(32) COLLATE utf8_bin 是十六进制字符串，请使用ascii，而不是utf8。
如果是十六进制，则将UNHEX 进一步缩小为仅BINARY(16)。
当一行大于 8KB 时，一些数据（可能是json_data）被“不记录”地存储。这意味着额外的磁盘访问和磁盘分配有点草率。因此，将该列存储为文件最终会花费大约相同的时间和空间。
操作系统可能会分配 4KB 块的空间。 InnoDB 使用 16KB 块。

【讨论】：

是的，json_data 是显着增加存储空间的列。是的，平均 10KB。是的每个文件的多个版本。最新的是要交付的。 hash值用于比较文件是否有变化，每次变化index_value都会增加，因此最大的index_val是最新版本。我尝试过压缩单列和 blob 数据类型，但存储空间没有显着变化。我没想到 php zip 算法与 sql compress 如此不同

【解决方案2】：

text 类型占用了太多空间。你可以尝试用a smaller variant of text type 替换它，如果你可以理所当然地认为那么长是可以的。如果这些值并不总是全长，也将 char(32) 替换为 varchar(32) 会有所帮助。

或者您甚至可以在文本字段中使用varchar，但在这样做之前请注意this answer 上的内容。

希望我能帮上忙！

【讨论】：

我没有投反对票，但这个答案不正确。所有可变长度类型，VARCHAR、VARBINARY、BLOB、TEXT 以及它们的所有表亲都不会占用更多空间，具体取决于类型。它们只存储您放入其中的字符串值的长度。
ι 无法缩减为更小的数据类型。我尝试使用文本而不是长文本，并且无法添加一些 json 数据。目前检测到的最大的是 2mb uncompress
文本字段的实际存储需求主要取决于您存储在这些字段中的数据。仅仅因为潜在的最大数据大小存在巨大差异，并不意味着在这些字段中存储少量数据时存在很大差异。 idhash 名称表示该字段将存储一个哈希，该哈希具有恒定的长度。
2MB 需要MEDIUMTEXT。