关于是否上 ES 的问题

典型的时序数据特性，大量写，少量查。推荐 influxdb

其实吧，没上亿都可以用 MySQL

还得看现在和未来的规模

@superrz 谢谢推荐，influxdb 确实是一个可以考虑的 db。有个问题请教一下，我忘记罗列在上面了，我们这里可能还有部分查询是模糊查询，这个 influxdb 的表现也不错吗？

@iyaozhen 谢谢回答，眼前规模可能不大，但是后期数据肯定会上亿的，预计年数据量 5 亿~10 亿，所以对我们来讲 mysql 持久并不是一个很好的选择

@iyaozhen 三个月就上亿了

数据量大的话建议 ES 只 store primary key，然后拿着 PK 到 mysql 中取数据

@lyc1116 你好，你的意思是还是用 mysql 去 store data 吗？如果是这样，分库分表去存一些不是很常用的历史数据太占地方了有点，而且增加了维护的工作量。

单用 es 吧，按时间段分索引库，要查询的字段用 index 类型，其他详情字段就只用存储类型。分下片，多设几个副本，可靠。用消息队列异步写入吧，不过一天 100w 数据量峰值也就几百 tps。

我们每天 2 亿写入用的 es 没啥问题

不过你这个数据量如果对搜索没有要求的话选用 MySQL 应该也可以

试试 NewSQL 的 TiDB

@hxt 你好，单用 es 指的是数据持久层吧，应用逻辑层主要还是关系型的就丢在 mysql，持久层按照你提议的感觉是比较可靠的，我打算测试一下 es 和 influxdb 的可行性

@misaka19000 ok~ 搜索的话主要三种场景

1. 模糊搜索做分析使用
2. 精确提取某一个指标值
3. 按照批次查询某一批数据

Mysql 性能上感觉不是很乐观，其实也在接收的范围内啦，但是它的存储真的很大，亿级别就快上 T 了

@zhchyu999 你好，这个 tidb 符合当前我描述的场景吗，还没有深入了解过这款

@hikarisama 嗯，指历史版本数据。业务复杂的数据是不太适合存 es 的。

> 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

@hikarisama 是的，这样可以最大化查询性能，先 query 再 facet 分析的话，还是免不了要把数据放在 ES。后面提到 influxdb，ES 基于 inverted index，influxdb 基于 LSM tree，单从两个数据结构看 ES 的查询性能会比 influxdb 好。

@wph95 你好

1. 每条数据暂定 5 列左右， 有两个 varchar(50) 剩下都 int，暂定存 5 年
2.
3. 简单解释就是每次提交 10w 批次的数据生成一个版本，一个版本查询就是 10w 条
4. 结果有 10w+

是的，需要定位到一条，某段时间的聚合有，但是场景比较少。

模糊搜索目前是会有的，不过我可以看下是否可以通过系统和业务优化解决掉模糊搜索场景。
感谢，我会参考一下 Tidb 的。

es 很棒，记得按天分索引

mark 学习，准备入门了解 ES 做日志存储分析。

solr,es 都可以，mysql 不太适合查询