向大家请教个问题，如果使用数据存储一些检测日志，每分钟一条日志，那日志长年累月就很多，这些日志还要经常查询，时间越久查询越慢，大家怎么看这个问题

2018 年 4 月 16 日
 daijinming
4446 次点击
所在节点    程序员
23 条回复
HuHui
2018 年 4 月 16 日
历史数据归档或者删掉
fredcc
2018 年 4 月 16 日
时间序列数据库以及日志分析工具生态了解下
liuzelei
2018 年 4 月 16 日
elk 不是标配么？
liuzelei
2018 年 4 月 16 日
一分钟一条这点量估计 es 是喂不饱了。。。。。
lianxiaoyi
2018 年 4 月 16 日
1 分钟才一条日志，一小时 60 条，一年 366 天,一年才 527040,十年才 5270400,只能说你索引没建好。。。。。
virusdefender
2018 年 4 月 16 日
partition
d0m2o08
2018 年 4 月 16 日
elasticsearch 了解一下
qinrui
2018 年 4 月 16 日
一秒几百条的交易数据怎么办？
changnet
2018 年 4 月 16 日
秒级的按日期分一下表 mysql 都没啥问题
vegito2002
2018 年 4 月 16 日
首先你这个数据量其实很小， 其次就算真的很大现在成熟方案也很多，MapReduce 了解一下
mafeifan
2018 年 4 月 16 日
分割啊
daijinming
2018 年 4 月 16 日
@vegito2002 一组设备收集的检测数据确实不太多，可设备会越来越多，并且运行几年后可用性越来越低肯定是个趋势，现在还用 SQL 存储，有没有平滑的过渡方案
hcymk2
2018 年 4 月 16 日
前面有人说过了 时序数据库。
Miy4mori
2018 年 4 月 16 日
日志这种非关键数据 mongodb 集群存一下，分片做好杠杠的。
20has
2018 年 4 月 16 日
elk 好像是日志的好归宿～
iyaozhen
2018 年 4 月 16 日
你这量级基本属于你自己的问题，数据库没有索引？

每天 100w 内的日志不愿折腾的话 MySQL 表分区就行。时间字段按天分区

其它就是看需求，方案很多，elk 是最流行的方案。
mkeith
2018 年 4 月 16 日
表分区啊
cnbobolee
2018 年 4 月 16 日
每分钟一条日志，量比较小了。日志没必要全部保存，有时间区间划分吧。
projectzoo
2018 年 4 月 16 日
这很小吧？都不用 Hadoop 那一套，ES 应该就可以轻松搞定了
loarland
2018 年 4 月 16 日
这个量太少了。。。

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://study.congcong.us/t/447100

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX