为什么是InfluxDB | 写在《InfluxDB原理和实战》出版之际

1年前写的一篇旧文，文中的分析，以及探讨的问题和观点，至今仍有意义。

从2016年起，笔者在腾讯公司负责QQ后台的海量服务分布式组件的架构设计和研发工作，例如微服务开发框架SPP、名字路由CMLB、名字服务、配置中心、NoSQL存储等，在分布式架构、高性能架构、海量服务、过载保护、柔性可用、负载均衡、容灾、水平扩展等方面做了大量的工作，以公共组件的形式，支撑了来自QQ后台和其他BG海量服务的海量流量。后来在2018年底，笔者负责监控大数据平台的研发工作，目标是解决现有监控后台成本高昂的痛点，和支撑内部和外部的海量监控数据的需求，打造千亿级监控大数据平台。 笔者发现当前在监控技术领域缺乏优秀的监控系统，尤其是在海量监控数据场景，很多团队常用的一种做法是堆机器和堆开源软件，比如采用大量高配置的机器，单机百CPU核数、TB内存、数十TB的SSD存储，堆了一堆开源软件，例如Elasticsearch、Druid、Storm、Kafka、Hbase、Flink、OpenTSDB、Atlas、MangoDB等。

但从实际效果看，效果并不好，众多开源软件的组合只是以非常高昂的成本，在增加了系统的运营成本和数据的处理延迟的情况下解决了接入计算，但在海量标签和时间序列线情况下，查询的痛点突出，常出现的一种情况是查询超时、数据拉不出来的问题。 笔者认为，海量或千亿级，是整体的量，是个笼统的概念，可通过分而治之解决，通过分集群的方法来解决，海量监控数据的真正挑战在于以下几点：

• 能否做到实时，实时是种质变的能力，将一个离线监控平台，提升为一个实时决策系统。难点在于能否设计实现足够高性能的架构，能否实现水平扩展等。
• 分集群后，单个业务的流量大小、标签集多少是关键。流量大，相对容易解决，主要涉及到系统性能和水平扩展等。标签集多，海量标签，海量时间序列线，如何做查询优化，是挑战，如笔者遇到一些业务上报的监控数据，几十维度的标签，并将QQ号和URL作为标签值，非常海量的时间序列线。
• 针对监控数据多写少读、成本敏感的特点，如何设计高效的存储引擎？充分发挥硬件性能，并在高效压缩存储的同时保障查询效率。

为了更好的打造有竞争力的监控系统，我们将技术理念定位为“技术降成本，坚决反对开源软件堆砌”。

之所以定下这个理念是有原因的，技术降成本，是因为我们认为云计算是一种非常有突破性的技术形态，它将技术服务化，决定它能否成功的关键在于能否在基础技术上突破，打造出相比开源软件更有成本优势的云原生软件。

坚决反对开源软件堆砌，是因为现在开源软件非常繁荣，基于开源软件，我们很容易搭建一个基础系统，将功能跑起来，但绝大部分开源软件侧重的是功能，不是针对海量监控数据场景而设计的，或多或少都有各种痛点或限制，再堆砌更多的开源能力，即使弱化了痛点，但成本也是非常高昂的，这时，我们需要借助强大的技术和工程能力，直面问题，在架构和源码层面，解决它，而不是引入和堆砌更多的开源软件。

基于工程效率的考虑，我们选择了基于开源软件进行二次开发，使用开源软件的部分代码，按照我们的想法进行架构设计和功能开发，提升开发效率。在调研了众多的开源软件后，最终选择了以InfluxDB源码为基础进行二次开发。

选择InfluxDB源码，主要是因为我们对InfluxDB源码背后的技术和工程实力是认可的，InfluxDB研发团队是能真正的解决场景的痛点的，也是在认真的打造一款优秀的监控产品，而不是仅仅营销，比如基于读写性能和可用性的考虑，InfluxDB研发团队3次重构存储引擎。

在笔者着手以InfluxDB源码为基础开发集群等功能时，在业界中仍没有团队实现真正可用的InfluxDB集群能力。

一些团队只是通过Proxy实现了负载均衡，无法突破单机接入计算和存储的限制，缺乏一致性能力，并增加了查询和仪表盘的数据显示不一致性。

有些团队在学习研究了多年的InfluxDB后，最终考虑到基于时序分片的复杂度，直接放弃基于InfluxDB开发集群能力，而选择基于Rocksdb、Zookeeper等开源软件，自己搭建一套。在这里，我想说的是，一个缺乏大系统工程化能力的团队，又如何能用已经证明不合适的开源软件，再“堆砌”出比InfluxDB性能和成本优秀的软件呢？

再如，某云厂商，推出了InfluxDB集群版，选择Raft协议实现DATA节点的一致性，但性能低，集群的接入性能不如单机。

笔者在三个月内快速的开发出CP和AP架构分离、基于时序分片、水平扩展等基本集群能力，根据业务的特点和场景痛点，我们在索引引擎、冷热分离、查询实现、第三方协议、高可用性、运营性、连续查询、备份还原等方面也做了大量的工作。

最终的效果，也是符合预期的，例如从替换现有监控系统的后台的实施对比看，我们用了不到10%的机器成本，就支撑了原来Flink、Druid等在支撑的海量监控数据，降低了90%+的成本，成本优势突出，最重要的是，解决了查询超时、数据拉不出来的问题。

InfluxDB是DB-Engines上时序数据库排名第一的时序数据库，是一款非常优秀的软件，直接推动了监控技术进入实时、纳秒级的新时代，除了类SQL查询语言、RESTful API等现代特性，读写性能高、存储压缩率高，生态丰富、强大。

为了更好的推动监控技术的发展，和帮助更多的读者掌握构建实时监控系统的方法、分布式时序型数据库的架构设计和开发技巧，笔者规划了2本书和1个开源软件：

• 第一本书，也就是本书，侧重InfluxDB的原理和实战，帮助读者吃透InfluxDB的功能原理和掌握实战技巧；
• 第二本书，在筹划中，侧重InfluxDB的设计实现剖析、分布式技术、InfluxDB集群能力开发实战等，关于第二本书的更多信息和进展，敬请关注机械工业出版社的微信订阅号“华章电子书”上的鲜读；
• 开源软件，就是FreeTSDB（https://github.com/freetsdb/freetsdb），FreeTSDB的v0.x版本定位为InfluxDB企业版的开源替代，完全对标InfluxDB企业版。

最后，笔者衷心希望《InfluxDB原理与实战》和FreeTSDB能帮助读者更快地掌握InfluxDB的核心特性、功能原理和实战技巧，打造更有竞争力的监控产品，赋能业务。

欢迎交流讨论:

微信公众号：influxdb-dev

FreeTSDB技术交流群（QQ）：663274123