• 请不要在回答技术问题时复制粘贴 AI 生成的内容
向大家请教个问题，如果使用数据存储一些检测日志，每分钟一条日志，那日志长年累月就很多，这些日志还要经常查询，时间越久查询越慢，大家怎么看这个问题
daijinming · Apr 16, 2018 · 4503 viewsThis topic created in 2962 days ago, the information mentioned may be changed or developed.
 |
1
HuHui Apr 16, 2018 via Android
历史数据归档或者删掉
|
 |
2
fredcc Apr 16, 2018  1
时间序列数据库以及日志分析工具生态了解下
|
 |
3
liuzelei Apr 16, 2018
elk 不是标配么？
|
|
4
liuzelei Apr 16, 2018
一分钟一条这点量估计 es 是喂不饱了。。。。。
|
 |
5
lianxiaoyi Apr 16, 2018
1 分钟才一条日志，一小时 60 条，一年 366 天,一年才 527040,十年才 5270400,只能说你索引没建好。。。。。
|
 |
6
virusdefender Apr 16, 2018
partition
|
 |
7
d0m2o08 Apr 16, 2018
elasticsearch 了解一下
|
 |
8
qinrui Apr 16, 2018 via iPhone
一秒几百条的交易数据怎么办？
|
 |
9
changnet Apr 16, 2018 via Android
秒级的按日期分一下表 mysql 都没啥问题
|
 |
10
vegito2002 Apr 16, 2018 via iPad
首先你这个数据量其实很小， 其次就算真的很大现在成熟方案也很多，MapReduce 了解一下
|
 |
11
mafeifan Apr 16, 2018 via Android
分割啊
|
 |
12
daijinming OP @vegito2002 一组设备收集的检测数据确实不太多，可设备会越来越多，并且运行几年后可用性越来越低肯定是个趋势，现在还用 SQL 存储，有没有平滑的过渡方案
|
 |
13
hcymk2 Apr 16, 2018
前面有人说过了 时序数据库。
|
 |
14
Miy4mori Apr 16, 2018
日志这种非关键数据 mongodb 集群存一下，分片做好杠杠的。
|
 |
15
20has Apr 16, 2018 via Android
elk 好像是日志的好归宿～
|
 |
16
iyaozhen Apr 16, 2018 via Android
你这量级基本属于你自己的问题，数据库没有索引？
每天 100w 内的日志不愿折腾的话 MySQL 表分区就行。时间字段按天分区 其它就是看需求，方案很多，elk 是最流行的方案。 |
 |
17
mkeith Apr 16, 2018
表分区啊
|
 |
18
cnbobolee Apr 16, 2018
每分钟一条日志，量比较小了。日志没必要全部保存，有时间区间划分吧。
|
 |
19
projectzoo Apr 16, 2018
这很小吧？都不用 Hadoop 那一套，ES 应该就可以轻松搞定了
|
 |
20
loarland Apr 16, 2018
这个量太少了。。。
|
 |
21
nmgwddj Apr 16, 2018
读取文件不是每次都要从头读到尾的，文件再大不超过文件系统限制，读取的时候设置一下偏移一样很高效啊，怎么会有越来越慢的情况呢？
|
 |
22
LeeSeoung Apr 16, 2018
ELK 了解下。。查询日志的开发都省了。。
|
 |
23
owt5008137 Apr 17, 2018 via Android
分库分表或者 elasticsearch
|
Select Language