python - Postgresql/Python 压缩带有大量冗余行的文本列

Question

注意:

• 我们使用的是 Amazon RDS，因此我们可以使用的 PostgreSQL 扩展的数量非常有限。
• 我之所以说 RDS 上的 PostgreSQL，是因为 1) 我们必须使用 AWS，2) 我们想要最安全的数据完整性解决方案，同时花费最少的维护时间。 (因此，如果其他服务更适合这些要求，我们愿意接受建议)
• 我们有数 TB 的所述数据，因此空间效率很重要(但我们可以根据来源轻松分片)

我们希望将“日志”存储在具有以下最小字段集的表中(出于优化目的可能会添加更多字段):

• 来源
• 时间
• 等级
• 留言

消息列具有以下特殊性 * 99% 的时间非常短(< 64 个字符，但对于异常(exception)情况，它们可能会很长 > 1024 个字符) * 一些识别良好的消息最多可以占消息数量的10% * 大量“几乎”重复的消息(即像这个系统已经启动并运行了 X 秒)
* 一长串“独特”的信息 * 获取典型一天的消息并通过 gzip 运行它们很容易将大小除以 15

目前我正在考虑两种可能的解决方案

接受用户定义的“标记”字典的压缩算法

我们的想法是拥有某种压缩算法，该算法可以根据我们识别的“重复文本”列表使用用户提供的“字典”并存储结果。由于我们的“应用程序”是唯一可以写入和读取的应用程序，因此我们将能够“即时”解压缩

• Pro:肯定会允许有一个很好的压缩比
• 缺点:我不知道在哪里搜索(LZ77？但我不知道如何搜索)

“完全”匹配预定义消息的字典表

• LOGS_TABLE
• 来源
• 时间
• 等级
• dictionnary_id
• 消息(可为空)

_

• DICTIONNARY_TABLE
• dictionnary_id
• 留言

_

• Pro:我完全明白如何实现它，而且很容易“更新”
• 缺点:不涵盖“接近”匹配

对于这类问题是否已经有了“最先进”的解决方案？

Answer 1

我终于接受了字典表的想法

对于 dictionnary_id 我实际上使用了 murmurhash 64 位(并将 id 命名为 hash_message 这样我就可以先在 python 端预先计算它，因为它是一个非密码学，它的调用很漂亮，对于 python，它有一个纯 C 实现 mmh3 模块)。

我在字典表中预加载了我从“典型一天”的日志中获得的 5.07 亿条消息中最常见(和重复)的 50 万条日志。然后我加载了执行以下 INSERT 请求的数据:

        INSERT INTO my_logs (
            service_id,
            creation_date,
            level,
            hash_message,
            message
        )
        SELECT
            %(hash_robot)s,
            %(creation_date)s,
            %(hash_message)s,
            NULLIF (
                %(message)s,
                min(message)
            )
        FROM dictionnary
        WHERE hash_message = %(hash_message)s;

通过这样做，如果 message 已经存在，则自动插入，如果词典中不存在，则仅将实际文本插入我的日志表中。

我的日志表的 message 列平均只使用了 3 个字节!这意味着大多数时候消息表是空的，虽然在我的词典中添加更多日志是不值得的(并且从 bigint 为我的 service_id 切换到 int 实际上是一个更好的主意)