我正在运行一个数据库进行日志分析。目前我使用 MySQL 数据库,用于分析的表如下所示:
- UUID
- REQUEST_ID
- REQUEST_TIMESTAMP
- RESPONSE_TIMESTAMP
- 运行时
- SERVER_NAME
我使用此表为每个条目、5 分钟聚合和每日聚合创建 View 。我每天插入大约 400.000 个条目。目前该表中约有 7000 万行。
我的实际问题是,我的查询、插入/更新查询以及聚合查询变得越来越慢。
因此,我为每日聚合创建了第二个表。每天都会运行一次作业,以对最后一天进行聚合。第二个作业将从原始表中删除超过 30 天的所有条目。
我的问题: 这是正确的方法还是使用不同的表结构甚至另一个数据库(例如 NoSQL、图形数据库等)会更好?
最佳答案
除非必要,否则不要索引 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
的值是多少?
在什么情况下您会接触超过一天的数据?如果“从不”,那么缓存应该不是问题。如果“经常”,让我们研究一下这些案例。
关于mysql - 用于日志分析的数据库类型?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/42227562/