共计 3787 个字符，预计需要花费 10 分钟才能阅读完成。
在车联网场景下，GPS 产生的时序数据量级通常都达到了亿级，高效写入、存储和疾速查问是最根本的数据处理要求，但在具体实际上这却不是一件容易实现的事件。最近某企业就遇到了这样一个问题：服务端接管存储 GPS 相干数据，按 1 次 /30 秒的上传频率，一天的数据条数预计在 1.2 亿条，其想要实现后盾的实时监控和历史轨迹查问，个别用什么样的数据库进行存储？NoSQL（Redis、MongoDB）？MySQL？还是 HBase？
置信上述企业的数据库选型问题并不是个例，抉择到一款适合的数据库，对于打造一个适宜业务倒退的数据架构至关重要。为了找到该问题的最优解，涛思数据解决方案架构师从数据实质登程进行剖析，联合具体实际输入本文，给到大家参考。
先谈 NoSQL 数据库
不论是 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 是应用非结构化的形式来存储结构化数据的，这种模式导致了压缩成果差、存储老本高、节点规模大的劣势。
再谈 MySQL/PostgreSQL
原本这两款数据库作为 SQL 类数据库，存储结构化数据是很适合的。然而，咱们看一下每秒的写入量：均匀 10W/30 = 3333 rows/s，最大值 10W rows/s，因为车联网自身会呈现“车机在一段时间内断网补传数据”、“车机上传按时钟定时”等特点，会有肯定概率触发最大值写入量，甚至超过最大值。因而选用的数据库必须具备高吞吐能力，而且还得留有余力供后续扩容。用过 MySQL 的开发者都会有体验，在没调优的状况下，这种 2KB 的行写入，1k tps 根本把单个节点打满了。
另外一方面，咱们个别都会建设索引，至多建设工夫戳的索引用于按时间段查找数据。而当咱们用 B+ 树存储索引，在单表数据量达到 2000W 行时，索引的保护会导致写入速度的降落，单从这一点看就很难运维，更不要说在建设更多索引的状况下。
再者，MySQL 的横向扩大只能靠中间件来实现，没有更好的形式了，这种分布式的横向扩大能力也为其打了个折扣。正是基于此，PostgreSQL 才会独自出了一个分支来存储时序数据。
接下来谈 HBase
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 在设计的初期就定位要做物联网场景下的数据库，也就是时序数据库。至于上述场景的数据问题，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 都能够抉择
- 单机扛不住，然而好分片的，同上一条
- 不好分片，那能够思考 TiDB 这种分布式事务的 HTAP
2. 对于非事务，基本上就是各种 MPP 型的 OLAP：
- 多维分析为主，不晓得本人什么已知维度的剖析，就用 ClickHouse/Doris 这种通用的 OLAP
- 有场景特色的，就选场景通用的，例如 TDengine 做时序场景，Neo4j 做图计算
3. 分布式数据库，看几点：
- Sharding + Partition 策略：这一点基本上决定了性能的上上限
- 分布式架构：这一点影响零碎的容量下限 / 瓶颈模块
- 计算函数：这一点决定好不好用，能不能加重业务开发的工作量。不然都只有读写没计算，啥计算都本人写必定是不适合的。
结语
事实证明，专用的比通用的更能打，大家能够移步到 https://docs.taosdata.com/ 去理解 TDengine 的更多技术细节。如果你也面临时序数据处理难题，欢送退出 TDengine 用户交换群，和更多气味相投的开发者一起探讨解决。
