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

• 資深大佬 : 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

  同行啊

• 資深大佬 : 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