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