关于时序数据库:深入分析如何为亿级-GPS-数据处理进行数据库选型实现高效存储和查询

4次阅读

共计 3799 个字符，预计需要花费 10 分钟才能阅读完成。

在车联网场景下，GPS 产生的时序数据量级通常都达到了亿级，高效写入、存储和疾速查问是最根本的数据处理要求，但在具体实际上这却不是一件容易实现的事件。最近某企业就遇到了这样一个问题：服务端接管存储 GPS 相干数据，按 1 次 /30 秒的上传频率，一天的数据条数预计在 1.2 亿条，其想要实现后盾的实时监控和历史轨迹查问，个别用什么样的数据库进行存储？NoSQL（Redis、MongoDB）？MySQL？还是 HBase？

置信上述企业的数据库选型问题并不是个例，抉择到一款适合的数据库，对于打造一个适宜业务倒退的数据架构至关重要。为了找到该问题的最优解，涛思数据解决方案架构师从数据实质登程进行剖析，联合具体实际输入本文，给到大家参考。

不论是 Redis/MongoDB/ElasticSearch 当中的哪一个，在面对上述场景时都会面临同一个问题：压缩率。在车联网当中，依照国标 30s 的采样距离能够计算失去单台车的采集量为 2880 rows/day，在 10W 车辆规模下，就是 2.88 亿 / 天。假如单台车辆采集 250 个信号，每个信号 8 Bytes（相当于 Double），即每行 2000 Bytes，那么 1 天就会有 562.5 GB 的数据量，1 年会有约 200TB 的数据。

在这样的数据规模下，压缩率即便是 50%，也须要 100TB 的空间。而这样的空间规模，通常都须要 10 个节点以上的 NoSQL 集群（用 Redis 的话就更可怕了，须要内存 100TB 的集群）。这个论断的底层原理，就在于 NoSQL 是应用非结构化的形式来存储结构化数据的，这种模式导致了压缩成果差、存储老本高、节点规模大的劣势。

原本这两款数据库作为 SQL 类数据库，存储结构化数据是很适合的。然而，咱们看一下每秒的写入量：均匀 10W/30 = 3333 rows/s，最大值 10W rows/s，因为车联网自身会呈现“车机在一段时间内断网补传数据”、“车机上传按时钟定时”等特点，会有肯定概率触发最大值写入量，甚至超过最大值。因而选用的数据库必须具备高吞吐能力，而且还得留有余力供后续扩容。用过 MySQL 的开发者都会有体验，在没调优的状况下，这种 2KB 的行写入，1k tps 根本把单个节点打满了。

另外一方面，咱们个别都会建设索引，至多建设工夫戳的索引用于按时间段查找数据。而当咱们用 B+ 树存储索引，在单表数据量达到 2000W 行时，索引的保护会导致写入速度的降落，单从这一点看就很难运维，更不要说在建设更多索引的状况下。

再者，MySQL 的横向扩大只能靠中间件来实现，没有更好的形式了，这种分布式的横向扩大能力也为其打了个折扣。正是基于此，PostgreSQL 才会独自出了一个分支来存储时序数据。

HBase 单从诞生的背景看，就不是为了时序数据而设计的。很多程序员通过设计 rowkey 的形式，变相实现了 HBase 对时序数据的存储，其中 OpenTSDB 就是一种开源的实现形式。在 5、6 年前，分布式存储还是 Hadoop 一枝独秀的时代，大家也就自然而然地用上了 HBase/OpenTSDB 这一类数据库。然而从产品设计上看，其设计指标是为了服务爬虫存储这样的场景——反对几千亿行的表（超大表），并且反对随时增加新的列（列族）。从这样的设计外面，咱们能够推导进去上面几个问题：

存储率不高：因为 HBase 里用了 Byte 的类型，以 Column Family 为单位做列存，因而压缩率也上不去。然而比 NoSQL 好一些。
运维简单：用 HBase 就得先上 HDFS/ZooKeeper/MR 这一系列组件，装置运维就是个问题。原本只是为了存储数据，后果倒腾起大数据的组件来了。
计算慢：哪怕是 OpenTSDB 这个基于 HBase 做的时序数据库（Time Series Database），在做一些常见的降采样、排序计算、时间段检索上，都不是特地快。其背地的问题还是在于 HBase 节点自身不提供时序的计算函数，因而查问时都得汇聚到 1 个 OpenTSDB 节点来进行，并发度很无限并且会耗费大量的网络 IO 老本。

综上所述，HBase 也并非很适应车联网场景。

TDengine 在设计的初期就定位要做物联网场景下的数据库，也就是时序数据库。至于上述场景的数据问题，TDengine 曾经从实际层面就给出了答复。

在狮桥团体的网货平台与金融 GPS 零碎业务中，对于车辆轨迹收集与计算有着强需要。GPS 每日产生总量在 40 亿左右，须要为业务方提供实时末次地位查问，近 180 日行驶轨迹查问，相似车辆轨迹比照查问，以及一些危险逾期的智能剖析等等。在狮桥的产品历史中，技术架构一共经验过四个版本的迭代——通过 MQ 接入厂商数据、Kudu+Impala 模式、Hbase + Clickhouse、TDengine。

第三阶段改版中，狮桥曾尝试应用 Hbase、Clickhouse 替换 Kudu，但从存储性能而言，狮桥心愿可能读写兼顾、反对 SQL，同时还有正当的分区策略，这一点 HBase 必定不能满足，Clickhouse 尽管体现还算不错，但也没有齐全满足需要。从业务需要登程，狮桥开始进行时序数据库选型，最初抉择了 TDengine，实现了他们“心愿找到一个存储技术既能够合并读写性能，又能够符合到本身业务场景，且还是 SQL 原生”的数据库选型诉求。

在利用 TDengine 后，狮桥的整体数据存储缩减超过 60% 以上，集群更是指数级的下线——末次地位查问的 Redis、轨迹查问的 Hbase 集群个体下掉、Clickhouse 也不再用作轨迹存储，把裸金属用在了更须要蛮力干活的中央，真正实现了降本增效。

有着同样场景的还有南京津驰。此前他们的 GPS 服务采纳的存储技术计划是 Redis + MySQL + CSV，实时数据存储到 Redis 队列，通过服务生产后将原始数据存储到 MySQL，凌晨执行定时工作将前一天 MySQL 中的原始数据存储到 CSV 文件。随着业务的倒退以及数据量的增长，各种问题也逐步凸显，开始影响工作效率，呈现查问效率低、数据安全性低、数据占用空间大、数据使用不够灵便等问题。在进行选型调研后，他们抉择将 TDengine 搭建在 GPS 服务中，轻松抗住了业务中每秒靠近 400MB 左右的写入量，并且压缩率喜人，存储空间降为原计划的 3%。

同样的车联网落地案例还有蔚来汽车、现实汽车、零跑汽车等，感兴趣能够点击链接查看，本篇文章就不多做赘述了。

而 TDengine 之所以能达到上述成果，还要从 Jeff（TDengine 创始人 & CEO 陶建辉）演绎的十条时序数据处理特点说起：

所有采集的数据都是时序的 —— 就只解决时序数据
数据都是结构化的 —— 结构化是所有优化的第一切入点
每个数据流的数据源是惟一的 —— 在写入过程中不必过分思考随机写入
数据少有更新或单条删除操作 —— 抉择数据结构的重要依据
数据个别是按到期日期来删除的 —— 主动淘汰数据是短暂运维的必需品
数据要优先保障写入操作，读操作为辅 —— 写入吞吐量是第一指标
数据流量安稳，能够较为精确的计算 —— 不像 MySQL 的业务场景，压力根本可预测
数据肯定是指定时间段和指定区域查找的 —— 查问优化的次要动手点
数据多有统计、聚合等实时计算操作 —— 提供时序独有的函数
数据量微小，一天的数据量就超过 100 亿条 —— 针对性的压缩率、横向扩大架构

从上述时序数据特点登程，TDengine 打造了以下的翻新技术点：

创立一个设施一张表、超级表，压缩率达到到 10% 的级别
行式存储 + 列式存储，进一步晋升压缩率
LSM Tree 构造的引擎，SkipList 的 MemTable
Union all + tag 的超级表语法糖
降采样 / 状态窗口 / 会话窗口函数

作为时序数据库引擎，TDengine 不须要基于 Hadoop 生态搭建，也不须要拼装 Kafka、Redis、HBase 等诸多组件，它将数据处理中的缓存、音讯队列、数据库、流式计算等性能都对立在了一起，这样轻量级的设计不仅让它的安装包很小、对集群资源耗费很少，同时也在肯定水平上升高了研发、运维老本，因为须要集成的开源组件少，因此零碎能够更加强壮，也更容易保证数据的一致性。

上面延长一个话题，分享一下我总结的数据库选型准则，以此帮忙大家更好地进行数据库选型。
讲讲数据库的选型准则

如果是事务的：
1. 单机扛得住的，MySQL/PG 都能够抉择
2. 单机扛不住，然而好分片的，同上一条
3. 不好分片，那能够思考 TiDB 这种分布式事务的 HTAP
对于非事务，基本上就是各种 MPP 型的 OLAP：
1. 多维分析为主，不晓得本人什么已知维度的剖析，就用 ClickHouse/Doris 这种通用的 OLAP
2. 有场景特色的，就选场景通用的，例如 TDengine 做时序场景，Neo4j 做图计算
分布式数据库，看几点：
1. Sharding + Partition 策略：这一点基本上决定了性能的上上限
2. 分布式架构：这一点影响零碎的容量下限 / 瓶颈模块
3. 计算函数：这一点决定好不好用，能不能加重业务开发的工作量。不然都只有读写没计算，啥计算都本人写必定是不适合的。
结语

事实证明，专用的比通用的更能打，大家能够移步到 https://docs.taosdata.com/ 去理解 TDengine 的更多技术细节。如果你也面临时序数据处理难题，欢送增加小 T vx：tdengine1 申请加入 TDengine 用户交换群，和更多气味相投的开发者一起探讨解决。