我正在尝试将基于文件的组织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 列是json_data
,对吗? 它的平均(未压缩(约为 10KB,对吗? 在文件实现中,每个版本都有多个"版本",对吗? 如果是这样,您如何判断要向用户交付哪一个?
- 大多数压缩技术给你 3:1;InnoDB压缩给你2:1。 这部分是因为它有它不能(或不会(压缩的东西。
- 仅压缩 JSON 列(在客户端代码中(并将其存储在
MEDIUMBLOB
中,在 InnoDB 中可能比使用COMPRESSED
占用更少的空间。 (但这不会是一个巨大的节省。 - 专注于如何选择哪个 JSON "版本"确实会交付给用户。 围绕这一点优化架构。 然后决定如何存储数据。
- 鉴于该表可以有效地说明哪个文件包含所需的 JSON,那么这将是最好的方法。 并使用一些正常的、快速解压缩的技术;不要专注于最大压缩。
- 如果
char(32) COLLATE utf8_bin
是十六进制字符串,请使用ascii
,而不是utf8
。 - 如果是十六进制,那么
UNHEX
进一步将其缩小到仅BINARY(16)
。 - 当一行大于 8KB 时,某些数据(可能
json_data
(被"记录外"存储。 这意味着额外的磁盘访问和磁盘分配更加草率。 因此,将该列存储为文件最终会花费大约相同的时间和空间。 - 操作系统可能以 4KB 块为单位分配空间。 InnoDB使用16KB块。
它是占用太多空间的text
类型。 您可以尝试用较小的文本类型变体替换它,如果您可以理所当然地给出那么长的长度是可以的。 如果这些值并不总是全长,则用varchar(32)
替换char(32)
也会有所帮助。
或者,您甚至可以使用文本字段varchar
,但在这样做之前请留意此答案的内容。
希望我有帮助!