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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 2448 天前的主题，其中的信息可能已经有所发展或是发生改变。

日志

查询

长年累月

请教

23 条回复 • 2018-04-17 08:49:05 +08:00

HuHui

2018-04-16 09:42:00 +08:00 via Android

历史数据归档或者删掉

fredcc

2018-04-16 09:42:56 +08:00

时间序列数据库以及日志分析工具生态了解下

liuzelei

2018-04-16 09:45:46 +08:00

elk 不是标配么？

liuzelei

2018-04-16 09:46:28 +08:00

一分钟一条这点量估计 es 是喂不饱了。。。。。

lianxiaoyi

2018-04-16 10:04:10 +08:00

1 分钟才一条日志，一小时 60 条，一年 366 天,一年才 527040,十年才 5270400,只能说你索引没建好。。。。。

virusdefender

2018-04-16 10:10:25 +08:00

partition

d0m2o08

2018-04-16 10:24:52 +08:00

elasticsearch 了解一下

qinrui

2018-04-16 10:26:40 +08:00 via iPhone

一秒几百条的交易数据怎么办？

changnet

2018-04-16 10:27:42 +08:00 via Android

秒级的按日期分一下表 mysql 都没啥问题

vegito2002

2018-04-16 10:42:30 +08:00 via iPad

首先你这个数据量其实很小，其次就算真的很大现在成熟方案也很多，MapReduce 了解一下

mafeifan

2018-04-16 10:43:40 +08:00 via Android

分割啊

daijinming

2018-04-16 10:46:52 +08:00

@vegito2002 一组设备收集的检测数据确实不太多，可设备会越来越多，并且运行几年后可用性越来越低肯定是个趋势，现在还用 SQL 存储，有没有平滑的过渡方案

hcymk2

2018-04-16 10:49:25 +08:00

前面有人说过了时序数据库。

Miy4mori

2018-04-16 11:10:13 +08:00

日志这种非关键数据 mongodb 集群存一下，分片做好杠杠的。

20has

2018-04-16 11:17:43 +08:00 via Android

elk 好像是日志的好归宿～

iyaozhen

2018-04-16 11:25:01 +08:00 via Android

你这量级基本属于你自己的问题，数据库没有索引？

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

其它就是看需求，方案很多，elk 是最流行的方案。

mkeith

2018-04-16 12:01:00 +08:00

表分区啊

cnbobolee

2018-04-16 12:18:11 +08:00

每分钟一条日志，量比较小了。日志没必要全部保存，有时间区间划分吧。

projectzoo

2018-04-16 13:45:00 +08:00

这很小吧？都不用 Hadoop 那一套，ES 应该就可以轻松搞定了

loarland

2018-04-16 15:29:57 +08:00

这个量太少了。。。

nmgwddj

2018-04-16 15:52:44 +08:00

读取文件不是每次都要从头读到尾的，文件再大不超过文件系统限制，读取的时候设置一下偏移一样很高效啊，怎么会有越来越慢的情况呢？

LeeSeoung

2018-04-16 17:11:26 +08:00

ELK 了解下。。查询日志的开发都省了。。

owt5008137

2018-04-17 08:49:05 +08:00 via Android

分库分表或者 elasticsearch