项目是 GPS 业务，每天有约 2w+台车传数据到我们这里储存。每天数据量大概在 1 亿左右。
数据主要用于做报表，查询历史轨迹（查询频率高，基本上每次查出过万的数据）
没做过这么大数据量的业务场景，想问下这场景应该怎么做？感谢
This topic created in 2361 days ago, the information mentioned may be changed or developed.
 |
ByteRanMay 27, 2020
1
如果查询条件复杂，且有文本查询，那就 Hbase + ElasticSearch ；如果用云产品，那就是阿里云的 OTS + OpenSearch
|
 |
cominghomeMay 27, 2020
2
没做过这种业务，不过可以说下看法。
2w 台车，数据量一亿，那看来单位是请求数？ 给你往大了说，一个请求按 10 KB 算， 算下来一天也就 1T 左右，正常的大数据仓库都能 hold 住的吧 |
 |
shadowyueMay 27, 2020
3
有接触过相关业务，量应该没你这么大，5k-1w 量车，mongodb 就 hold 住
|
 |
xman99May 27, 2020
4
考虑下 新的分布式数据库？ tidb 、hbase 等超大型分布式数据库吧
|
 |
daozhihunMay 27, 2020
5
你这个很适合 hbase
|
 |
6
hbase+es 吧，hbase 用时间年月划分 region，es 按天建索引
|
1 |
HEROicMay 27, 2020 via Android
7
单纯的过车数据大概就 2KB 左右，一天就 200G
|
 |
toleranceMay 27, 2020
8
时序数据库考虑一下
|
 |
miceanMay 27, 2020
9
没做过大数据业务的话就按一般情况考虑吧
每台车每天发 5 千条，平均不到 1 秒一条。 不代表每条都要存储吧，地图上也不需要展示这么精细 可以 15 秒以上存一次，这样数量级就降到百万级以下了 |
 |
rockyou12May 27, 2020
10
你这该用各种时序数据库，hbase 不是特别好。优先考虑 influxdb 这类的吧
|
 |
liangliangleeMay 27, 2020 via Android
11
这种场景多适合时序数据库啊
|
 |
ychostMay 27, 2020
12
时序数据库 InfluxDB +1，特别适合做 IOT 数据存储，再配合 grafana 美滋滋，谁用谁知道
|
 |
rrfengMay 27, 2020
13
看数据结构，只说数据量就是耍流氓啊。
|
 |
wellscMay 27, 2020
14
时序数据库+1
|
 |
irockmanMay 27, 2020
15
传统数据库 mysql：一台车一张表，按 gps 每十秒上报一条数据，一年数据量 6*60*24*365=3153600 条数据，单表查询压力不大。或者选择时序数据库 influxdb，不过集群方案收费。
|
 |
alienx717May 27, 2020
16
大众的车联网项目自己都用的 HBASE
你可以参考以下。 另外，非得每 10 秒钟一条么，我记得 15 秒一条也可以吧，应该能少不少数据 |
 |
WhoMercyMay 27, 2020
17
冷热分离，多级缓存，数据预聚合，Data Partition/Sharding，DDB （ Distributed DB ）...
具体怎么实施看情况而定，一方面看已有痛点在哪，一方面估计会有的瓶颈，一方面平衡开发的复杂度 |
 |
18
同行啊 😂我这公司有好几个同类型平台，我待的这个平台设备量 30W+
用的 MongoDb 轻轻松松 一天设备上报的报文一亿多条，设备实时状态一定不要存数据库，放缓存中间件，不然后期真的改不动 轨迹的话按天分表，超过几个月的轨迹定期移到另一个空间大的冷存储（机械盘之类 原始报文只保存几天，接收上报的模块一定不要有存库操作，数据库挂掉会导致大量 TCP CLOSE_WAIT 建议接收上报的模块把原始报文发 kafka ,再由消费者存到另一个原始报文库 只要解耦解的好，并不需要用到时序数据库 用时序数据库会存在的问题在于设备可能定位漂移，或者突然报了一个有问题的包，这个时候再去时序数据库里修改它就非常困难了，这也是我们这没有采用时序数据库的原因 |
 |
jwdstefaniMay 27, 2020
19
我们之前的车贷 GPS 监控系统，一台车接了 3 个厂商的 GPS，也是用的 MongoDB,数据只保留一个月的，数据量也是大的一批，就是轨迹查询的时候吃内存
|
 |
tolbkniMay 27, 2020
20
结构化数据只新增不更新的场景可以用 ClickHouse 数据库
|
 |
dkerssMay 27, 2020
21
推荐 ClickHouse 神器！
|
 |
Magic347May 27, 2020
24
hive?
|
 |
25
这个场景，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/
|
|
yjhatfdu2May 27, 2020
27
顺便，现在如果是少量数据的 update，clickhouse 可以使用 mutations 完美完成，如果量大的话，可以用 collaspemergetree 引擎，变相实现标记删除并且不影响查询结果
|
 |
ahmcsxccMay 27, 2020
28
同 clickhouse
|
|
29
@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 希望对楼主有帮助 |
 |
gainsurierMay 27, 2020 via Android
30
歪个楼问下，为啥车每天要传那么对数据回来
|
 |
calpiswaterMay 27, 2020 via iPhone
31
可以考虑下清华的 IoTDB
|
 |
likukuMay 27, 2020
32
aws s3，还有啥存不了的？
直接进大数据服务 EMR，要么数据湖，简单查询，直接来 Athena 查 s3 也没问题啊 实时处理分析？ aws 有 kinesis 啊，各种并行实时处理，本来就是很适合搭配 IoT / GPS 业务场景的 非实时分析，还有 redshift 数据仓库服务可以用，更可以联合查询，操作型关系数据库。 跨一个或多个 Amazon RDS 和 Aurora PostgreSQL 数据库查询实时数据，支持大规模并行数据处理。 有兴趣欢迎继续交流～ |
 |
wdMay 28, 2020 via iPhone
33
@gainsurier #30 一般都会认为，数据就是钱呀，越多的数据越多的钱。每天几亿出去和投资人好吹牛逼。
|
 |
34
@yjhatfdu2 非常感谢大佬这么上心帮我，太感谢了，连性能测试都给我举例出来了。我现在还需要学习下 clickhouse 。从来没用过。
感觉这个方案不错，先参考你这个方案吧 |
|
35
@gainsurier 因为我们需要对车进行实时监控和历史轨迹回放。还要做一些报表之类的。
|
 |
rockcatMay 28, 2020
37
ClickHouse 或者 Green Plum 。
|
|
yjhatfdu2May 28, 2020
40
@rapperx2 对了，时间戳精度要求不高的话，可以用不需要用 DateTime64，可以 DateTime （精确到秒），经度维度可以用 UInt32 CODEC(DoubleDelta),方向不需要的话可以不存，这样估计还能小一倍，也能快一些。
|
 |
caotianMay 28, 2020
42
TDEngine
|
 |
chinvoMay 28, 2020 via iPhone
43
TimescalaDB
|
|
44
@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.) 这个查询时间属于正常的吗？ |
|
yjhatfdu2May 29, 2020
46
@rapperx2 渐变语句要加上 oder by(车牌,时间),我怀疑你这边是直接按照日期排序了，这样找一辆车的数据也要扫全表，然后数据类型建议也再看一下车牌最好用个足够小的 int 作为，再建一张表用来存车牌和 ID 的映射，查询时使用 join，这样能显著减少查询的数据量（ 2300w 行就 2.17GB 太大了），数据结构越高效性能越高
|
 |
raywongMar 1, 2023
51
楼主后续选了什么方案，遇到相似的场景，方便加个 qq 么。base64: MTU1MjkzNzAwMA==
|
Select Language