求友们帮助，每天亿级数据怎么储存

[rapperx2]

项目是 GPS 业务，每天有约 2w+台车传数据到我们这里储存。每天数据量大概在 1 亿左右。

数据主要用于做报表，查询历史轨迹（查询频率高，基本上每次查出过万的数据）

没做过这么大数据量的业务场景，想问下这场景应该怎么做？感谢

[tanranran]

如果查询条件复杂，且有文本查询，那就 Hbase + ElasticSearch ；如果用云产品，那就是阿里云的 OTS + OpenSearch

[cominghome]

没做过这种业务，不过可以说下看法。

2w 台车，数据量一亿，那看来单位是请求数？ 给你往大了说，一个请求按 10 KB 算， 算下来一天也就 1T 左右，正常的大数据仓库都能 hold 住的吧

[shadowyue]

有接触过相关业务，量应该没你这么大，5k-1w 量车，mongodb 就 hold 住

[xman99]

考虑下 新的分布式数据库？ tidb 、hbase 等超大型分布式数据库吧

[daozhihun]

你这个很适合 hbase

[HEROic]

hbase+es 吧，hbase 用时间年月划分 region，es 按天建索引

[HEROic]

单纯的过车数据大概就 2KB 左右，一天就 200G

[tolerance]

时序数据库考虑一下

[micean]

没做过大数据业务的话就按一般情况考虑吧
每台车每天发 5 千条，平均不到 1 秒一条。
不代表每条都要存储吧，地图上也不需要展示这么精细
可以 15 秒以上存一次，这样数量级就降到百万级以下了

[rockyou12]

你这该用各种时序数据库，hbase 不是特别好。优先考虑 influxdb 这类的吧

[lianglianglee]

这种场景多适合时序数据库啊

[ychost]

时序数据库 InfluxDB +1，特别适合做 IOT 数据存储，再配合 grafana 美滋滋，谁用谁知道

[rrfeng]

看数据结构，只说数据量就是耍流氓啊。

[wellsc]

时序数据库+1

[irockman]

传统数据库 mysql：一台车一张表，按 gps 每十秒上报一条数据，一年数据量 6*60*24*365=3153600 条数据，单表查询压力不大。或者选择时序数据库 influxdb，不过集群方案收费。

[alienx717]

大众的车联网项目自己都用的 HBASE
你可以参考以下。
另外，非得每 10 秒钟一条么，我记得 15 秒一条也可以吧，应该能少不少数据

[WhoMercy]

冷热分离，多级缓存，数据预聚合，Data Partition/Sharding，DDB （ Distributed DB ）...

具体怎么实施看情况而定，一方面看已有痛点在哪，一方面估计会有的瓶颈，一方面平衡开发的复杂度

[soulzz]

同行啊 😂我这公司有好几个同类型平台，我待的这个平台设备量 30W+
用的 MongoDb 轻轻松松
一天设备上报的报文一亿多条，设备实时状态一定不要存数据库，放缓存中间件，不然后期真的改不动
轨迹的话按天分表，超过几个月的轨迹定期移到另一个空间大的冷存储（机械盘之类
原始报文只保存几天，接收上报的模块一定不要有存库操作，数据库挂掉会导致大量 TCP CLOSE_WAIT
建议接收上报的模块把原始报文发 kafka ,再由消费者存到另一个原始报文库
只要解耦解的好，并不需要用到时序数据库
用时序数据库会存在的问题在于设备可能定位漂移，或者突然报了一个有问题的包，这个时候再去时序数据库里修改它就非常困难了，这也是我们这没有采用时序数据库的原因

[jwdstefani]

我们之前的车贷 GPS 监控系统，一台车接了 3 个厂商的 GPS，也是用的 MongoDB,数据只保留一个月的，数据量也是大的一批，就是轨迹查询的时候吃内存

[tolbkni]

结构化数据只新增不更新的场景可以用 ClickHouse 数据库