1
HuHui 2018-04-16 09:42:00 +08:00 via Android
历史数据归档或者删掉
|
2
fredcc 2018-04-16 09:42:56 +08:00 1
时间序列数据库以及日志分析工具生态了解下
|
3
liuzelei 2018-04-16 09:45:46 +08:00
elk 不是标配么?
|
4
liuzelei 2018-04-16 09:46:28 +08:00
一分钟一条这点量估计 es 是喂不饱了。。。。。
|
5
lianxiaoyi 2018-04-16 10:04:10 +08:00
1 分钟才一条日志,一小时 60 条,一年 366 天,一年才 527040,十年才 5270400,只能说你索引没建好。。。。。
|
6
virusdefender 2018-04-16 10:10:25 +08:00
partition
|
7
d0m2o08 2018-04-16 10:24:52 +08:00
elasticsearch 了解一下
|
8
qinrui 2018-04-16 10:26:40 +08:00 via iPhone
一秒几百条的交易数据怎么办?
|
9
changnet 2018-04-16 10:27:42 +08:00 via Android
秒级的按日期分一下表 mysql 都没啥问题
|
10
vegito2002 2018-04-16 10:42:30 +08:00 via iPad
首先你这个数据量其实很小, 其次就算真的很大现在成熟方案也很多,MapReduce 了解一下
|
11
mafeifan 2018-04-16 10:43:40 +08:00 via Android
分割啊
|
12
daijinming OP @vegito2002 一组设备收集的检测数据确实不太多,可设备会越来越多,并且运行几年后可用性越来越低肯定是个趋势,现在还用 SQL 存储,有没有平滑的过渡方案
|
13
hcymk2 2018-04-16 10:49:25 +08:00
前面有人说过了 时序数据库。
|
14
Miy4mori 2018-04-16 11:10:13 +08:00
日志这种非关键数据 mongodb 集群存一下,分片做好杠杠的。
|
15
20has 2018-04-16 11:17:43 +08:00 via Android
elk 好像是日志的好归宿~
|
16
iyaozhen 2018-04-16 11:25:01 +08:00 via Android
你这量级基本属于你自己的问题,数据库没有索引?
每天 100w 内的日志不愿折腾的话 MySQL 表分区就行。时间字段按天分区 其它就是看需求,方案很多,elk 是最流行的方案。 |
17
mkeith 2018-04-16 12:01:00 +08:00
表分区啊
|
18
cnbobolee 2018-04-16 12:18:11 +08:00
每分钟一条日志,量比较小了。日志没必要全部保存,有时间区间划分吧。
|
19
projectzoo 2018-04-16 13:45:00 +08:00
这很小吧?都不用 Hadoop 那一套,ES 应该就可以轻松搞定了
|
20
loarland 2018-04-16 15:29:57 +08:00
这个量太少了。。。
|
21
nmgwddj 2018-04-16 15:52:44 +08:00
读取文件不是每次都要从头读到尾的,文件再大不超过文件系统限制,读取的时候设置一下偏移一样很高效啊,怎么会有越来越慢的情况呢?
|
22
LeeSeoung 2018-04-16 17:11:26 +08:00
ELK 了解下。。查询日志的开发都省了。。
|
23
owt5008137 2018-04-17 08:49:05 +08:00 via Android
分库分表或者 elasticsearch
|