mysql - 用于日志分析的数据库类型？

Question

我正在运行一个数据库进行日志分析。目前我使用 MySQL 数据库，用于分析的表如下所示:

• UUID
• REQUEST_ID
• REQUEST_TIMESTAMP
• RESPONSE_TIMESTAMP
• 运行时
• SERVER_NAME

我使用此表为每个条目、5 分钟聚合和每日聚合创建 View 。我每天插入大约 400.000 个条目。目前该表中约有 7000 万行。

我的实际问题是，我的查询、插入/更新查询以及聚合查询变得越来越慢。

因此，我为每日聚合创建了第二个表。每天都会运行一次作业，以对最后一天进行聚合。第二个作业将从原始表中删除超过 30 天的所有条目。

我的问题:这是正确的方法还是使用不同的表结构甚至另一个数据库(例如 NoSQL、图形数据库等)会更好？

Answer 1

除非必要，否则不要索引 UUID。它非常随机，会导致大量 I/O。请参阅here .

按照您的讨论，构建汇总表；它们是使数据仓库表现良好的主要方式。但是，让我们看看您有什么 - SHOW CREATE TABLE 和 SELECTs，以及表大小。

你的摄取情况如何？ Here有一些关于扩展此类的技巧。 400K/天，表中70M对于MySQL来说没问题。

server_name(可能还有其他列)的标准化 - 请参阅摄取链接。

为什么会有更新？日志往往不需要更新。汇总表可能会使用批量 IODKU，这是一种更新；你用的是这个吗？

对于删除旧数据，PARTITION BY RANGE(TO_DAYS(...)) 具有 32 个分区，并每晚使用DROP PARTITION。这将比DELETE快得多:Partition tips

多少内存？使用InnoDB？ 70M行大约需要7GB？ innodb_buffer_pool_size 的值是多少？

在什么情况下您会接触超过一天的数据？如果“从不”，那么缓存应该不是问题。如果“经常”，让我们研究一下这些案例。