摘要：本文会从时序数据库的基本概念、应用场景、需求与能力等方面一一展开，带你了解时序数据库的前世此生。
时序数据库突然火了起来。Facebook开源了beringei时序数据库，基于PostgreSQL打造的时序数据库TimeScaleDB也开源了。时序数据库做为物联网方向一个很是重要的服务，业界的频频发声，正说明各家企业已经火烧眉毛的拥抱物联网时代的到来。html
本文会从时序数据库的基本概念、应用场景、需求与能力等方面一一展开，带你了解时序数据库的前世此生。算法
应用场景
时序数据库是一种针对时序数据高度优化的垂直型数据库。在制造业、银行金融、DevOps、社交媒体、卫生保健、智慧家居、网络等行业都有大量适合时序数据库的应用场景：sql
- 制造业：好比轻量化的生产管理云平台，运用物联网和大数据技术，采集、分析生产过程产生的各种时序数据，实时呈现生产现场的生产进度、目标达成情况，以及人、机、料的利用情况，让生产现场彻底透明，提升生产效率。
- 银行金融：传统证券、新兴的加密数字货币的交易系统，采集、分析交易过程当中产生的时序数据，实现金融量化交易。
- 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