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

文章来源于互联网:我想和你聊聊:FreeTSDB不只是InfluxDB集群

发表评论