问一个 mysql 数据表设计问题。

[holinhot]

需要统计每个网站使用的流量记录。数据主要来至多个 ELK 集群.定期更新到 mysql 方便前端展示和画图。

如果设计为每 1 分钟同步更新至 mysql 这个表怎么来设计好好呢。

traffic_logs table:
+---------------+------------+------------+------------+---------------------+
| website | date | inbound | outbound | last_updated

如果这样,1 分钟同步一次，数据保留一年，1440*365=525600 这样一来一个站一年有 50 万条记录。如果有 1 万个 host，这表里高达 5256000000(52 亿)条记录。一个表这么大，这肯定玩完啊。一般一个表几百万查询统计就很慢了。

[Raymon111111]

貌似数据类型是时间序列, 那有比 mysql 更好的解决方案

至于如果真的用 mysql 怎么搞

首先就像你说的, 每分钟一个点, 一年数据存死了, 怎么办?

考虑业务妥协, 比如

1. 真的需要一年前的数据吗, 业务价值在哪, 谁会去用它?
2. 六个月以前的数据聚合行不行? 十五分钟一个平均点
3. 六个月以前的数据换存储方案(比如文件), 要查可以, 接受查询比较慢
4. 这个数据最后会怎么用, 是聚合还是真的需要一分钟一个点去展示, 如果是聚合那定时任务聚合好直接用聚合好的数据展示行不行


(最后像是这种统计类的数据, mysql 存储全量肯定是不行的, 一般都是存个最近几天的数据, 查起来快, 历史数据全部扔到类似文件存储, 存储量大查询满. 另外 50 亿的数据分库分表也是可以搞定, 但这么大的成本为了存这个数据得考虑考虑投入产出比啊

[holinhot]

@Raymon111111 可能要做一些妥协和优化。可能改成最近 1 小时的为每分钟一个点，最近 6 小时为 15 分钟一个点，最近 12 小时为 30 分钟一个点，最近 24 小时为 60 分钟一个点。

超过 24 小时都按天计了。

怎么设计表好一点

[dorothyREN]

加一个历史表，一周以前的全部扔进历史表里面。真的需要历史数据的时候再去查

[altboy]

萌新疑惑🤔,即然都是 ELK 了,即然要展示和画图了,不知道 mysql 究竟方便在哪了? Kibana 它不香吗?

[holinhot]

@altboy Kibana 数据量太大，只保留一个月的日志