主页 / dba / 问题 / 343093
Accepted
hz lin
Asked: 2024-10-19 23:18:00 +0800 CST

是否可以为 mariadb 压缩或分区现有的大表？

  • 772

我设置了一个 mariadb 数据库来记录实验数据。在其中一个表中，我每行都存储了巨大的原始图像。由于每行包含 3 张 512*512px 图像，几百万行数据已经耗尽了磁盘空间。我有 12TB 的磁盘，数据库已经占用了约 10TB。图像之间的差异很小，所以我相信有很大的压缩空间。我想考虑压缩数据库，但由于可用空间有限，我想要一种方法来就地压缩它。我在 Ubuntu 20.04 上使用 mariadb 10.3.39。我不是数据库专家，但我很乐意学习更多。我试过：

ALTER TABLE images ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8 ALGORITHM=INPLACE;

我得到了：

ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'ALGORITHM=INPLACE' at line 1

我还考虑过是否可以将表分成多个块，然后单独压缩每个分区。但是我也不确定对现有表进行分区是否需要更多空间。在盲目尝试之前，我想得到一些建议。

mariadb

2 个回答

  1. Best Answer

    简短回答：否

    长答案：

    • 它们是什么类型的图像？大多数格式（.jpg 等）都已经压缩，因此压缩没有任何好处。
    • 即使在最佳情况下（数字和字符串，而非图像），InnoDB 的 COMPRESSED 也只能提供大约 2:1 的压缩率。另一方面，压缩是自动的，因此无需压缩某些部分而不压缩其他部分。
    • 最大的表是什么？它有多大？对表进行许多类型的更改都需要复制表。也就是说，在操作期间，您需要空间来复制表。具体来说，INPLACE这行不通。
    • MariaDB 没有办法计算两幅图像之间的差异。这正是您所需要的。即使您找到了，也需要大量的编程来实现它。
    • 最初PARTITION您的 10GB 会占用多余的 10GB（您没有）。
    • 单个 上只能执行极少的操作PARTITION；这消除了分区的假设好处。

    这是一个想法...

    1. 使用示例 BLOB（每个 512MB？）进行实验。在您的应用程序中执行此操作，而不是 MariaDB。
    2. 如果出现明显收缩，则继续。
    3. 通过其 遍历表PRIMARY KEY。读取 blob、压缩它们，然后将它们存储回表中。这将花费很长时间，而且显然不会节省磁盘空间。（稍后会详细介绍。）
    4. 同时，通过以下两种方式之一更改应用程序代码：（1）跟踪压缩的程度 - 以便知道在读取时是否解压缩。 （2）或者查看前几个字节以查看 blob 是否被压缩（如果需要则解压缩）。
    5. 完成后，表仍为 10GB，但其中会有很多漏洞。这些漏洞大部分应在将来重新使用INSERTs。警告：BLOB 列可能存储在“非记录”中；我不知道释放的块是否可以重新使用。因此我建议进行一些测试。
    6. 最终，这些洞会被用完，而新的行将导致桌子不断增大。

    或者...

    如果您可以接受删除“旧”行，请参阅此内容以了解如何以最小的影响执行此操作： https ://mysql.rjweb.org/doc.php/deletebig

    • 0

  2. 基本上，即使是好的压缩图像，如果它完美无缺，也会比压缩的行更好。

    但由于 MARIAFB 不支持ALTER TABLE中的压缩

    你可以做的是

    CREATE tABLE tmp1(Images blob)

    INSERT INTO tmp1 VALUES(RPAD('', 65535, CHAR(7)));

    CREATE TABLE cmp2 (i Blob COMPRESSED=zlib)
SELECT images FROM tmp1

    Records: 1  Duplicates: 0  Warnings: 0

    小提琴

    • 0

相关问题