摘要：本文会从时序数据库的基本概念、利用场景、需要与能力等方面一一开展，带你理解时序数据库的前世今生。
时序数据库突然火了起来。Facebook 开源了 beringei 时序数据库，基于 PostgreSQL 打造的时序数据库 TimeScaleDB 也开源了。时序数据库作为物联网方向一个十分重要的服务，业界的频频发声，正阐明各家企业曾经急不可待的拥抱物联网时代的到来。
本文会从时序数据库的基本概念、利用场景、需要与能力等方面一一开展，带你理解时序数据库的前世今生。
利用场景
时序数据库是一种针对时序数据高度优化的垂直型数据库。在制造业、银行金融、DevOps、社交媒体、卫生保健、智慧家居、网络等行业都有大量适宜时序数据库的利用场景：
- 制造业：比方轻量化的生产治理云平台，使用物联网和大数据技术，采集、剖析生产过程产生的各类时序数据，实时出现生产现场的生产进度、指标达成情况，以及人、机、料的利用情况，让生产现场齐全通明，进步生产效率。
- 银行金融：传统证券、新兴的加密数字货币的交易系统，采集、剖析交易过程中产生的时序数据，实现金融量化交易。
- DevOps：IT 基础设施和利用的运维零碎，采集、剖析设施运行和应用服务运行监控指标，实时把握设施和利用的衰弱状态。
- 社交媒体：社交 APP 大数据平台，跟踪用户交互数据，剖析用户习惯、改善用户体验；直播零碎，采集直播过程中包含主播、观众以及两头各环节的监控指标数据，监控直播品质。
- 卫生保健：商业智能工具，采集智能手表，智能手环中的衰弱数据，跟踪要害指标和业务的总体衰弱状况
- 智慧家居：居家物联网平台，采集家居智能设施数据，实现近程监控。
- 网络：网络监控零碎，实时出现网络延时、带宽应用状况。
时序数据的需要
在上述场景中，特地在 IoT 物联网以及 OPS 运维监控畛域，存在海量的监控数据须要存储管理。以华为云 Cloud Eye Service(CES) 服务为例，单个 Region 须要监控 7000 多万个监控指标，每秒须要解决 90 万个上报的监控指标项，假如每个指标 50 个字节，一年的监控数据有 1PB；主动驾驶的车辆一天各种传感器监测数据就 80G。
传统关系型数据库很难撑持这么大的数据量以及这么大的写入压力，Hadoop 大数据解决方案以及现有的时序数据库也会面临十分大的挑战。大规模 IoT 物联网，以及私有云规模的运维监控场景，对时序数据库的需要次要包含：
- 继续高性能写入：监控指标往往以固定的频率采集，局部工业物联网场景传感器的采集频率十分高，有的曾经达到 100ns，私有云运维监控场景根本也是秒级采集。时序数据库须要反对 7 *24 小时不中断的继续高压力写入。
- 高性能查问：时序数据库的价值在于数据分析，而且有较高的实时性要求，典型剖析工作如异样检测及预测性保护，这类时序剖析工作须要频繁的从数据库中获取大量时序数据，为了保障剖析的实时性，时序数据库须要能疾速响应海量数据查问申请。
- 低存储老本：IoT 物联网及运维监控场景的数据量曾现指数级增长，数据量是典型的 OLTP 数据库场景的千倍以上，并且对老本十分敏感，须要提供低成本的存储计划。
- 反对海量工夫线：在大规模 IoT 物联网及私有云规模的运维场景，须要监控的指标通常在千万级甚至亿级，时序数据库要能反对亿级工夫线的治理能力。
- 弹性：监控场景也存在业务突发增长的场景，例如：华为 Welink 服务的运维监控数据在疫情期间暴增 100 倍，时序数据库须要提供足够灵活的弹性伸缩能力，可能疾速扩容以应答突发的业务增长。
开源时序数据库能力
过来 10 年，随着挪动互联网、大数据、人工智能、物联网、机器学习等相干技术的疾速利用和倒退，涌现出许多时序数据库，因为不同数据库采纳的技术和设计初衷不一样，所以在解决上述时序数据需要上，他们之间也体现呈现较大的差别，本文在上面内容将抉择应用最多的几种开源时序数据库为剖析对象进行探讨。
- OpenTSDB
OpenTSDB 基于 Hbase 数据库作为底层存储，向上封装本人的逻辑层和对外接口层。这种架构能够充分利用 Hbase 的个性实现了数据的高可用和较好的写入性能。但相比 Influxdb，OpenTSDB 数据栈较长，在读写性能和数据压缩方面都还有进一步优化的空间。
- InfluxDB
Influxdb 是业界比拟风行的一个工夫序列数据库，它领有自研的数据存储引擎，引入倒排索引加强了多维条件查问的性能，非常适合在时序业务场景中应用。因为时序洞察报表和时序数据聚合剖析，是时序数据库次要的查问利用场景，每次查问可能须要解决上亿数据的分组聚合运算，所以在这方面，InfluxDB 采纳的火山模型对聚合查问性能影响较大。
- Timescale
TimeScale 是一个基于传统关系型数据库 postgresql 革新的工夫序列数据库，继承了 postgresql 许多长处，比方反对 SQL，反对轨迹数据存储，反对 join，可扩大等等，读写性能好。TimeScale 采纳固定 schema，数据占用空间大，对于时序业务长期绝对固定且对数据存储老本不敏感的业务来说，也是一种抉择。
GaussDB（For Influx）的呈现
针对高性能写入、海量工夫线和高数据压缩的需要，以后还未能有比拟好的开源解决方案。GaussDB（For Influx）吸取了开源各家之长，设计了云原生架构的时序数据库。架构如下图所示。
相比现有的开源时序数据库，架构设计上有以下两方面的思考：
- 存储与计算拆散
存储计算拆散，一方面利用成熟的分布式存储系统进步零碎的可靠性。监控数据始终继续高性能写入，同时还有大量的查问业务，任何系统故障导致业务中断甚至数据失落都会造成重大的业务影响，而利用通过验证的成熟的分布式存储系统，可能显著的晋升系统可靠性，升高数据失落危险，并显著缩短构建本零碎的工夫。
另一方面，解除在传统 Share Nothing 架构下，数据和节点物理绑定的束缚，数据只是逻辑上归宿于某个计算节点，使得计算节点无状态化。这样在扩容计算节点时，能够防止在计算节点间迁徙大量的数据，只须要逻辑上将局部数据从一个节点移交给另外一个节点即可，能够将集群扩容的耗时从以天为单位缩短为分钟级别。
再一方面，通过将多正本复制从计算节点卸载到分布式存储节点，能够防止用户以 Cloud Hosting 状态在云上自建数据库时，分布式数据库和分布式存储别离做 3 正本复制导致总共 9 正本冗余的问题，可能显著升高存储老本。
- Kernel Bypass
为了防止在用户态内核态来回拷贝数据带来的性能损失，GaussDB（for Influx）零碎端到端思考 Kernel bypass 设计，没有抉择应用规范的分布式块或分布式文件服务，而是定制的针对数据库设计的分布式存储，对外裸露用户态接口，计算节点采纳容器化部署，通过专用存储网络间接和存储节点通信
除了架构之外，GaussDB（for Influx）还针对 IoT 物联网及运维监控场景的其余需要做了如下优化：
- 写优化的 LSM-Tree 布局和异步 Logging 计划，相比以后时序数据库晋升 94% 写性能。
- 通过向量化查问引擎，ARC Block Cache，以及 Aggregation Result Cache 晋升聚合查问性能，相比以后时序数据库晋升最高可达 9 倍
- 设计针对时序数据分布特色的压缩算法，压缩率相比 Gorilla 晋升 2 倍，并主动将冷数据分级到对象存储，升高 60% 存储老本
- 优化海量工夫线的索引算法，晋升索引效率，在千万工夫线量级下，写入性能是以后时序数据库的 5 倍。
编辑
删除
GaussDB（for Influx）胜利保障了公司 welink 和云监控 CES 两大服务之后上线商用，接下来咱们还将摸索如何在海量数据中寻找有价值数据的高效分析方法，为用户提供更加适合的剖析和洞察能力。
参考文献
https://zhuanlan.zhihu.com/p/32709932
https://www.cnblogs.com/jpfss/p/12183214.html
点击关注，第一工夫理解华为云陈腐技术~