从前世今生聊一聊，大厂为啥亲睐时序数据库
摘要：本文会从时序数据库的基本概念、应用场景、需求与能力等方面一一展开，带你了解时序数据库的前世今生。
时序数据库忽然火了起来。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
