日增 3 亿数据如何存储？

[chi1st]

如题，目前有日增大概 3 亿条的网络会话数据，写多读少，目前的需求是保存七天数据供用户查询（没有太复杂的查询条件）
公司内部可供选择的数据库有 MySQL ，MongoDB, TiDB

以上 3 种该如何选型？或者有无其他方案？

[D0n9]

如果用上述三种库，查询不方便，库表设计也不友好

最方便的使用 elasticsearch + kibana ，基本开箱即用

[CodeCodeStudy]

用时序数据库 InfluxDB ，适合大量数据写入，不更新数据，进行单表查询，定期删除数据的场合

[SbloodyS]

扔数仓里就好

[CodeCodeStudy]

InfluxDB 的 Continuous Queries 可以定时汇总数据到一个表里，Retention Policies 可以定期删除旧数据，保留近期数据

[chi1st]

@D0n9 如果只存一天数据，以目前的需求来看 MySQL 问题也不大，ES 也在考虑范围内，确实开箱即用，不过需要自己去运维

@CodeCodeStudy 据我了解时序数据库的确很适合目前的需求，不过我没玩过且公司没有对应的服务，运维成本也就增加了

[CodeCodeStudy]

@chi1st 运维成本并没增加多少，InfluxDB 可以自动汇总数据，自动删除旧数据，增加的是开发的时间

[chi1st]

@CodeCodeStudy 都是新开发，开发成本差不多，公司内部有上面三种数据库的云服务，省心很多，目前准备先用 mongo 测下

[gabon]

clickhouse

[Mithril]

MongoDB 带这些数据没什么问题的。
首先要确定查询的场景，如果只是简单的连续区段按 id 搜索，你甚至都可以直接存文件。
如果需要做字符串的通配符或者分词检索，考虑使用 ES 。
更复杂的查询就得看你具体需求了。
但本质上是要确定你的需求和范围，不要为了基本没啥人用的功能增加成本，无论是技术成本，人员成本或是硬件成本都是如此。
如果一个功能你估计只有几个人每个月用几次，那最好的办法就是告诉它这功能坏掉了，没准以后哪天会修好。

[netnr]

SQLite 按小时存储

[chi1st]

@SbloodyS @gabon @netnr 感谢大家，目前准备用 MongoDB 了

[chi1st]

@Mithril 感谢，目前决定先使用 MongoDB ，这个功能领导挺看中的，发生网络异常时对异常定位还是有所帮助的，功能使用次数也许如你所说，但是我们是对公司层面提供私有云服务的，如果一个使用频次不高但领导很关注的功能使用时发现它坏了，这种也挺尴尬的。。。

[mk98]

掏钱的话国内有很多这种产品，比如日志易