摘要：随着物联网数据量的增长，“时序数据库”成为企业面临的“必答题”。
据研究机构Forrester预测，物联网所带来的产业价值要比互联网高30倍，到2020年，中国物联网产业将成长为一个超过五万亿规模的巨大市场。
5G、AI、区块链等新一代信息技术与物联网加速融合。在智能互联的愿景中，物联网系统的机器、设备和传感器收集的数据，通过人工智能技术进行分析与关联，以更有意义的方式服务用户。然而，随着物联网数据量的增长，“时序数据库”成为企业面临的“必答题”。
高性能时序数据库，是物联网的数据存储底座
时序数据库是一种针对时序数据进行垂直优化的数据库，专门用于存储和管理时序数据。向宇举例到，某个酒店在晚上8：00有200个房间被入住，那个8：00时间点上存储的200的数字就是时序数据。
在物联网和运维监控场景下，如服务器CPU和内存使用量、电动汽车的工况数据、或是应用服务的业务指标等等，各种被采集的数据指标项多达千万甚至上亿，甚至一次采集的指标数据就可能超过数10GB，这些数据都必须要在规定时间内全部写入数据库。并且，指标数据通常间隔几秒就会被采集一次，如此海量的时序数据必然要求数据库要具备大并发写入能力和很高的数据压缩效率。
此外，时序业务通常还需要将数据从数据库中检索出来，以近乎实时的可视化方式展现，方便分析和决策，这对数据库的查询性能也有着严格的要求。在这种场景下，传统的关系型数据库最大的问题在于数据缺少压缩，查询效率低下，时序数据库一开始就被设计为高吞吐、低时延、高数据压缩率，以满足物联网和运维监控场景下对性能和储存成本的诉求。也正是因为时序数据库的这些特点，在制造业、银行金融、社交媒体、能源、智慧家居等行业领域都有大量的应用场景。
凝结10多年软硬件技术经验，未来挑战重重
根据IDC的一份白皮书预测，到2025年全球数据总量将达到175ZB，这其中30%为时序数据。时序数据库是在最近10年才真正发展起来，这期间出现了许许多多的时序数据库，光DBEngines网站收录的全球时序数据库就多达有30多种。
向宇谈到，相比关系型数据库，时序数据库略微简单一些，没有复杂的事务支持，也没有针对单条数据的更新和删除操作。但要做好一个时序数据库并非易事，就像造车一样，要造好一辆车，单纯购买零件组装测试是远远不够的，还需要考虑质量、性能、舒适性、功能性、安全性等等，一辆车凝结着人类智慧与文化的结晶。
打造一款时序数据库，需要凝结数十年数据库领域发展的硬件和软件技术和经验，如存储、安全、分布式系统、编译、算法、数据结构、架构设计等等，更要做到系统安全、可靠、稳定、高效和多场景通用。“未来会有越来越多的企业希望利用时序数据库挖掘出更多有价值的信息，时序数据库在海量时间线管理、数据压缩、读写性能等方面正面临着巨大的技术挑战。”向宇讲到。
云原生存算分离架构，华为云数据创新Lab实践
时序数据库，作为整个物联网的数据存储底座，同时也是云厂商基础设施的重要部分。作为全球云服务提供商，华为云的迅速发展，其背后是大量基础设施的扩张，如何能把所有的基础设施和云服务完全监控起来，是摆在运维团队面前不得不去解决的技术问题。现有的开源时序数据库已经不能满足华为云监控数据日益增长的诉求，监控指标数量从数百万迅速增加到数十亿，每秒数据写入量从数亿条迅速增长到数十亿条，迫切需要一款自研的时序数据库可以支撑运维团队的监控系统。
在2018年开始，向宇所在的华为云数据创新Lab开始着眼于未来物联网和运维监控场景下的时序数据存储与管理，自研时序数据库GaussDB（for Influx）。在经过内部场景的验证后，GaussDB（for Influx）于2020年正式上线对外商用。
GaussDB(for Influx)采用云原生存储与计算分离架构，支持分钟级弹性节点扩缩容，做到不迁移数据的同时还把事情给做了；支持亿级时间线，每天万亿条数据写入不是问题；支持数据无损压缩，采用自适应数据压缩算法，将数据压缩比提高到1:20；运用MPP架构、向量化、预聚合等相关技术，相比开源的OpenTSDB、InfluxDB等时序数据库，对于像单时间线条件查询和多维聚合查询这类在时序数据库中较为常见的查询，性能上有很大幅度的提升。
向宇介绍到，华为云的一个业务从Cassandra切换到GaussDB(for Influx)后，计算节点从总共39个（热集群18个，冷集群9个，大数据分析集群 12个）降低到了9个节点，缩减4倍计算节点。存储空间消耗从每天1TB降低到100GB以内，缩减10倍存储空间消耗。
目前华为云时序数据库GaussDB(for Influx)已经服务15+内部和外部客户，已成为华为云基础设施重要组成部分。
研发之路没有现成的参考答案，迎难而上正面“刚”
回想时序数据库GaussDB（for Influx）研发过程的时候，向宇说道，一个系统从诞生到成熟，往往伴随着长期的Bug修复和结合场景的持续优化。因为任何人都无法提前把所有的应用场景都想到并且测试覆盖到，GaussDB(for Influx) 也不例外。
当初研发GaussDB(for Influx)时，向宇团队遇到的第一个问题就是“进程OOM（内存耗尽触发操作系统保护机制）退出”。大家都知道，出现OOM只可能有两个原因，一是内存泄漏，二是内存真实使用过多。
众所周知，数据库里面的数据是存放到磁盘文件，高效率的数据检索往往需要在内存中建立文件索引，方便快速定位数据在文件中的位置。在时序数据库中，当数据在数据库中保留的时间越长，数据文件就会越大，文件数量也就越多。程序重启过程中，需要将每个数据文件的元数据读取到内存组织为索引，这里的元数据主要包括当前文件存放有多少时间线，每个时间线的数据在文件中的偏移量等等。在运维监控的场景下，时间线的数量是呈指数增长，当时序数据库的时间线超过亿级，虚拟机规格不变的情况下，问题出现了，元数据无法全部存放内存再转化为索引，于是程序出现OOM无法重启。
向宇进一步阐述道，时序数据库难就难在这里，因为绝大部分用户或者场景不会达到出现问题的时间线和数据量，面对计算资源有限，而数据量太大的情况，行业中并无行之有效的现成方法，解决这样的问题，往往需要结合技术和经验。举个例子，程序重启过程中加载元数据，为避免在内存积压太多数据，可以选择限流的方式，那么每次处理的数据量阈值应当如何设置就依赖长期的系统开发经验，太大可能问题还会存在，太小又耗时过长。
“有问题不可怕，可怕的是没有问题。当问题发生时，我们的选择是正面‘硬刚’，出现一个消灭一个！”向宇谈到。不难看出，也正是他们的这种不畏艰难，用“匠人”精神开发出华为云基础设施重要组成部分，并且已经服务15+内部和外部客户的华为云时序数据库GaussDB(for Influx)。