这是一个创建于 2122 天前的主题，其中的信息可能已经有所发展或是发生改变。
业务场景
1. 每天数据量 100w 左右
2. 数据量有时间顺序的特性
3. 数据查询低频率，基本都是历史版本数据
4. 如果查询，大概率是定位到单条或者同批次(10w 左右)
请教各位大神上什么持久合适，暂时觉得 ES 不错，考虑到写入的并发量不大可控，对于查询的并发量可能大一些，暂时想到的方法是 应用层 mysql， 大数据持久层 es，靠谱吗？还请各位大神帮忙看看或者推荐推荐
1. 每天数据量 100w 左右
2. 数据量有时间顺序的特性
3. 数据查询低频率，基本都是历史版本数据
4. 如果查询，大概率是定位到单条或者同批次(10w 左右)
请教各位大神上什么持久合适，暂时觉得 ES 不错，考虑到写入的并发量不大可控，对于查询的并发量可能大一些，暂时想到的方法是 应用层 mysql， 大数据持久层 es，靠谱吗？还请各位大神帮忙看看或者推荐推荐
 |
1
superrz 2019-03-07 12:11:21 +08:00  1
典型的时序数据特性，大量写，少量查。推荐 influxdb
|
 |
2
iyaozhen 2019-03-07 12:16:30 +08:00 via Android
其实吧，没上亿都可以用 MySQL
还得看现在和未来的规模 |
 |
3
hikarisama OP @superrz 谢谢推荐，influxdb 确实是一个可以考虑的 db。有个问题请教一下，我忘记罗列在上面了，我们这里可能还有部分查询是模糊查询，这个 influxdb 的表现也不错吗？
|
|
4
hikarisama OP @iyaozhen 谢谢回答，眼前规模可能不大，但是后期数据肯定会上亿的，预计年数据量 5 亿~10 亿，所以对我们来讲 mysql 持久并不是一个很好的选择
|
 |
6
lyc1116 2019-03-07 13:26:03 +08:00
数据量大的话建议 ES 只 store primary key，然后拿着 PK 到 mysql 中取数据
|
|
7
hikarisama OP @lyc1116 你好，你的意思是还是用 mysql 去 store data 吗？如果是这样，分库分表去存一些不是很常用的历史数据太占地方了有点，而且增加了维护的工作量。
|
 |
8
hxt 2019-03-07 14:38:04 +08:00
单用 es 吧，按时间段分索引库，要查询的字段用 index 类型，其他详情字段就只用存储类型。分下片，多设几个副本，可靠。用消息队列异步写入吧，不过一天 100w 数据量峰值也就几百 tps。
|
 |
9
misaka19000 2019-03-07 14:42:55 +08:00 via Android
我们每天 2 亿写入用的 es 没啥问题
不过你这个数据量如果对搜索没有要求的话选用 MySQL 应该也可以 |
 |
10
zhchyu999 2019-03-07 14:45:43 +08:00
试试 NewSQL 的 TiDB
|
|
11
hikarisama OP @hxt 你好，单用 es 指的是数据持久层吧，应用逻辑层主要还是关系型的就丢在 mysql，持久层按照你提议的感觉是比较可靠的，我打算测试一下 es 和 influxdb 的可行性
|
|
12
hikarisama OP @misaka19000 ok~ 搜索的话主要三种场景
1. 模糊搜索做分析使用 2. 精确提取某一个指标值 3. 按照批次查询某一批数据 Mysql 性能上感觉不是很乐观，其实也在接收的范围内啦，但是它的存储真的很大，亿级别就快上 T 了 |
|
13
hikarisama OP @zhchyu999 你好，这个 tidb 符合当前我描述的场景吗，还没有深入了解过这款
|
|
14
hxt 2019-03-07 15:05:43 +08:00 1
@hikarisama 嗯，指历史版本数据。业务复杂的数据是不太适合存 es 的。
|
 |
15
wph95 2019-03-07 15:22:49 +08:00 1
> 1. 每天数据量 100w 左右
每条数据多大，存几天啊 2. 数据量有时间顺序的特性 > 说明可以按时序优化 3. 数据查询低频率，基本都是历史版本数据 > 历史版本数据没太懂 4. 如果查询，大概率是定位到单条或者同批次(10w 左右) > 同批次(10w 左右) 指的是搜索到的结果有 10w+ 还是 搜索的范围里 有 10w --- 首先 这个量不大，好的机器一天 1B/1TB 量 es 都能随便写入 其次 推荐 influxdb 感觉推荐错了，influxdb 是 metric 不是 log 感觉 lz 要的是一个能查到指定一条数据的 db，而不是对某一时间段做聚合。 Tidb 和 ES 在 lz 描述的情况里感觉都能用，感觉 tidb 更适合。 当然 如果模糊搜索 ~= 要有分词 ~= 全文搜索， 那就老实用 es。 没有分词没全文搜索需求就 tidb。毕竟是个 DB 用起来简单运维起来也舒服些。 如果不用 log search，只需要时序聚合，influxdb / prometheus |
|
16
lyc1116 2019-03-07 16:09:40 +08:00 1
@hikarisama 是的，这样可以最大化查询性能，先 query 再 facet 分析的话，还是免不了要把数据放在 ES。后面提到 influxdb，ES 基于 inverted index，influxdb 基于 LSM tree，单从两个数据结构看 ES 的查询性能会比 influxdb 好。
|
|
17
hikarisama OP @wph95 你好
1. 每条数据暂定 5 列左右， 有两个 varchar(50) 剩下都 int，暂定存 5 年 2. 3. 简单解释就是每次提交 10w 批次的数据生成一个版本，一个版本查询就是 10w 条 4. 结果有 10w+ 是的，需要定位到一条，某段时间的聚合有，但是场景比较少。 模糊搜索目前是会有的，不过我可以看下是否可以通过系统和业务优化解决掉模糊搜索场景。 感谢，我会参考一下 Tidb 的。 |
 |
18
yuankui 2019-03-07 16:46:09 +08:00
es 很棒，记得按天分索引
|
 |
19
JonyOang 2019-03-07 17:06:22 +08:00
mark 学习，准备入门了解 ES 做日志存储分析。
|
 |
20
ducklyl 2019-03-08 09:14:38 +08:00
solr,es 都可以，mysql 不太适合查询
|
Select Language