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