我想和你聊聊：FreeTSDB不只是InfluxDB集群

FreeTSDB-v0.0.2（https://github.com/freetsdb/freetsdb)发布了！它是第一个，也是唯一一个支持InfluxDB企业版原生集群能力的开源系统。它彻底解锁了大家期待的各种分布式姿势，针对META节点和DATA节点数据特点的不同，设计了2种不同的分布式模型，META节点的CP模式，DATA节点的AP模式，并支持水平扩展、自定义一致性级别等。

众所周知，高可用、水平扩展的InfluxDB分布式集群能力是InfluxDB企业版的护城河，数年来，虽多个团队在跟进和研究，仍未有团队真正实现类似的集群能力；它也是InfluxDB企业版的核心竞争力和最大卖点（一个节点一年1.5万美刀的LICENSE费）；还是当前各公司、各业务团队对InfluxDB开源版最大、最恳切的期待。比如阿里某童靴：

我们选型，成本是第一，没有压缩实现的，都不能购买

期待有个和官方对齐的分布式版

我们也测试过XXX那个高可用版本，性能不行，不如单机，所以只能无奈分库分表，但是中间层做了半年做不出来

这个分布式真的是硬核技术，期待beta早日出来，我马上上

我们认为，数据爆炸，时序数据领域缺乏优秀的软件，而这些软件缺少不仅仅是水平扩展、高可用的分布式能力，还缺少实时高效的接入计算能力、低成本的存储能力、低延迟的查询能力等。具体来说：

能否做到实时：实时是种质变的能力，将一个离线监控平台，提升为一个实时决策系统。难点在于能否设计实现足够高性能的架构，能否实现水平扩展等。

能否支持海量时间序列线：流量大，相对容易解决，主要涉及到分集群、系统性能和水平扩展等，但不能分拆的单个业务，它的流量大小、标签集多少是关键，在海量标签、海量时间序列线的情况下，如何高效实现分布式迭代器，如何做查询优化，是挑战。比如，笔者遇到一些业务上报的监控数据，几十维度的标签，并将QQ号和URL作为标签值，非常海量的时间序列线。

能否做到低成本：比如，针对时序数据多写少读、成本敏感的特点，如何设计高效的存储引擎？再比如，如何充分发挥硬件性能，并在高效压缩存储的同时保障查询效率？

在我们看来，InfluxDB虽在DB-Engines上排名第一，遥遥领先第二名，但它仍是一个在发展中的软件，并存在耗内存、查询延迟高、海量时间序列线场景下性能下降等痛点。另外，我们也发现，尽管InfluxDB团队非常优秀，对分布式等前沿技术理解的非常深刻，工程化能力也非常强，但他们对语言、内核、硬件等系统技术理解是不够的，对高性能的理解是不够的，比如，我们曾做了几个优化，就轻松越过了他们认为的不易做到的75万points的性能值；再比如，Golang其实性能不高，对于性能敏感、成本敏感的PaaS而言，GC更是痛点。

所以，关于FreeTSDB，我们是这么考虑的，我们规划了两个版本，具体来说：

0.x版本：我们希望它是InfluxDB企业版的开源替代，即这个版本会对标和完全兼容influxdb企业版，但在这个版本中，我们会修复InfluxDB企业版的痛点，比如高内存、查询延迟大等痛点。

1.x版本：我们计划更换技术栈，并重构存储引擎等核心模块，目标在读、写、时间序列线等核心指标能获得数量级提升，并将FreeTSDB的高性能、高可用的实时计算、存储引擎等核心能力，拓展到时序数据之外的数据场景，支持更丰富的系统形态，赋能更多的场景和业务。

最后我想说的是，我们喜欢技术，有点狂热；我们也曾开发过在写性能、查询延迟、海量时间序列线等核心指标领先InfluxDB企业版的时序数据库；FreeTSDB承载的是我们的技术理想和表达自由，FREE，自由的享受技术的乐趣，将分布式、高性能、高并发做到极致！

感谢所有参与FreeTSDB的小伙伴，来自阿里、腾讯、华为以及工业互联网的小伙伴，Happy Hacking！

欢迎交流讨论:

微信公众号：influxdb-dev

FreeTSDB技术交流群（QQ）：663274123