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

[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 数据库

[dkerss]

推荐 ClickHouse 神器！

[rapperx2]

@soulzz 大佬啊。哈哈，能加个 V 交流学习下吗？

[soulzz]

@rapperx2 不是大佬，架子别人搭的，我在这天天修修补补

[Magic347]

hive?

[yjhatfdu2]

这个场景，clickhouse 使用 mergetree 引擎，根据日期做分区，车辆 ID,timestamp 排序，clickhouse 对于 float 类型时序数据也有类似时序数据库的 Gorilla codec，有效压缩时序浮点数据。clickhouse 本身的话，支持分布式、高可用，支持 SQL （部分），可以用 http 接口直接访问，使用难度很低。性能的话，我们做过一些测试，单节点 64 核 epyc2+256G 内存，单表 15 亿行 20 多列的纽约出租车数据，单个全表级的 group by+sum 大概 200ms 左右，多个维度的 group by+多个聚合能在 700ms 内完成，基本上是现在分析库的上限了。https://clickhouse.tech/docs/en/getting-started/example-datasets/nyc-taxi/

[yjhatfdu2]

@yjhatfdu2 比 hive 或者 HBase+mr/spark 之类的的方案大概也就快几百倍把

[yjhatfdu2]

顺便，现在如果是少量数据的 update，clickhouse 可以使用 mutations 完美完成，如果量大的话，可以用 collaspemergetree 引擎，变相实现标记删除并且不影响查询结果

[ahmcsxcc]

同 clickhouse

[yjhatfdu2]

@rapperx2 我还真造了点数据来测试一下 clickhouse 。
表结构：
create table ts_test
(
ts DateTime64 CODEC(DoubleDelta),
car_id Int32,
lat Float32 CODEC(Gorilla),
log Float32 CODEC(Gorilla),
dir Float32 CODEC(Gorilla)
) engine MergeTree() order by (car_id, ts) partition by toDate(ts);
其中，方向 dir 平均 100s 随机刷新，速度 0-100 之间随机，ts 的间隔 1s±100ms 并加入随机抖动，20000 辆车，每辆车起始位置随机，然后模拟每辆车运动，生成 csv 数据导入 clickhouse 。共使用了 20 分钟导入了 983725233(9.8 亿)行数据，占用硬盘空间 9.45 GiB，大概每 1 亿行 1G 。
然后测试了一些简单的查询。
Q1: 查询某个车的完整轨迹: select * from ts_test where car_id=1;
行数和耗时：49187 rows in set. Elapsed: 0.041 sec.
Q2: 查询表总行数: select count(*) from ts_test;
行数和耗时：1 rows in set. Elapsed: 0.001 sec. （估计缓存了）
Q3: 查询每辆车的数据点数量: select car_id,count(*) from ts_test group by car_id;
行数和耗时：20000 rows in set. Elapsed: 0.129 sec.
Q4: 查询每辆车的活动范围（矩形）:select car_id,min(lat),max(lat),min(log),max(log) from ts_test group by car_id;
行数和耗时：20000 rows in set. Elapsed: 0.568 sec.
Q5: 查询一辆车的活动范围（矩形）:select min(lat),max(lat),min(log),max(log) from ts_test where car_id=100;
行数和耗时：1 rows in set. Elapsed: 0.003 sec.
Q6: 查询每小时的数据点（每小时约 7200w ）数量: select count(*),toYYYYMMDD(ts)+toHour(ts) as hour from ts_test group by hour;
行数和耗时：14 rows in set. Elapsed: 0.347 sec.

测试硬件：单机 AMD EPYC 7702P 64-Core Processor 64 核，256G 内存，SSD
希望对楼主有帮助

[gainsurier]

歪个楼问下，为啥车每天要传那么对数据回来

[calpiswater]

可以考虑下清华的 IoTDB

[likuku]

aws s3，还有啥存不了的？

直接进大数据服务 EMR，要么数据湖，简单查询，直接来 Athena 查 s3 也没问题啊

实时处理分析？ aws 有 kinesis 啊，各种并行实时处理，本来就是很适合搭配 IoT / GPS 业务场景的

非实时分析，还有 redshift 数据仓库服务可以用，更可以联合查询，操作型关系数据库。
跨一个或多个 Amazon RDS 和 Aurora PostgreSQL 数据库查询实时数据，支持大规模并行数据处理。

有兴趣欢迎继续交流～

[wd]

@gainsurier #30 一般都会认为，数据就是钱呀，越多的数据越多的钱。每天几亿出去和投资人好吹牛逼。

[rapperx2]

@yjhatfdu2 非常感谢大佬这么上心帮我，太感谢了，连性能测试都给我举例出来了。我现在还需要学习下 clickhouse 。从来没用过。
感觉这个方案不错，先参考你这个方案吧

[rapperx2]

@gainsurier 因为我们需要对车进行实时监控和历史轨迹回放。还要做一些报表之类的。

[cqdx02]

@yjhatfdu2 能否进行数据聚合呢，比如按分钟级，15 分钟级统计数据

[rockcat]

ClickHouse 或者 Green Plum 。

[0987363]

@soulzz 状态不存数据库的话，那要用状态排序岂不是凉😅

[yjhatfdu2]

@cqdx02 当然可以，group by 就可以，看上面的 Q6，使用对应的函数对时间进行处理就行

[yjhatfdu2]

@rapperx2 对了，时间戳精度要求不高的话，可以用不需要用 DateTime64，可以 DateTime （精确到秒），经度维度可以用 UInt32 CODEC(DoubleDelta),方向不需要的话可以不存，这样估计还能小一倍，也能快一些。

[soulzz]

@0987363 这个要看应用场景，实时状态存库的话数据库压力非常高

[caotian]

TDEngine

[chinvo]

TimescalaDB

[rapperx2]

@yjhatfdu2 我根据车牌 查询时间范围一个月的数据

58516 rows in set. Elapsed: 19.415 sec. Processed 23.93 million rows, 2.17 GB (1.23 million rows/s., 111.70 MB/s.)

这个查询时间属于正常的吗？

[yjhatfdu2]

@rapperx2 不正常，方便看一下表定义和查询嘛？

[yjhatfdu2]

@rapperx2 渐变语句要加上 oder by(车牌,时间),我怀疑你这边是直接按照日期排序了，这样找一辆车的数据也要扫全表，然后数据类型建议也再看一下车牌最好用个足够小的 int 作为，再建一张表用来存车牌和 ID 的映射，查询时使用 join，这样能显著减少查询的数据量（ 2300w 行就 2.17GB 太大了），数据结构越高效性能越高

[rapperx2]

@yjhatfdu2 能方便加个 V 吗？

[yjhatfdu2]

@rapperx2 qq 吧，base64:MjUxNjUwMjky

[Huayx9]

@rapperx2 请问最后你选用了什么技术方案，方便加个 v 么，我的 vx 是 base64:Zm9yX215Xzc3

[rapperx2]

@Huayx9 加你了

[raywong]

楼主后续选了什么方案，遇到相似的场景，方便加个 qq 么。base64: MTU1MjkzNzAwMA==