經過春節假期的封閉和攻關，我們完成了FreeTSDB-v0.1.1（https://github.com/freetsdb/freetsdb）開發，並在二月份最后一天進行了發布！
繼FreeTSDB-v0.0.2徹底解鎖了分布式能力（針對META節點和DATA節點數據特點的不同，設計了2種不同的分布式模型，META節點的CP模式，DATA節點的AP模式，並支持水平擴展、自定義一致性級別等），在v0.1.1版本中，我們將性能和生態對齊了InfluxDB。
FreeTSDB與InfluxDB的性能是一致的，而且相比其他第三方InfluxDB集群，FreeTSDB和InfluxDB一樣，都是遙遙領先的。比如，基於公開數據，我們將FreeTSDB/InfluxDB和阿里雲的InfluxDB雲服務做了對比。
在阿里雲ECS（16 vCPU 32 GiB, Ubuntu 18.04 64bit），FreeTSDB的寫性能與InfluxDB是一致的，386985.67 point/sec，約是阿里雲InfluxDB服務(16核64G ：~ 150000 point/sec)的2.58倍。
聊到這里，很多小伙伴可能會發現“作為InfluxDB企業版的開源替代，FreeTSDB的大功能基本開發完成了”，同時也很好奇FreeTSDB的后續規划，這也是我接下來想和大家聊聊的。
俗話說，“不忘初心，方得始終”，那么FreeTSDB的初心是什么呢？
FreeTSDB的初心是“將分布式、高性能、高並發做到極致”，作為一名技術人，FreeTSDB是作為《InfluxDB原理與實戰》配套程序啟動的，承載的是我們的技術理想和技術表達。
我們認為技術不應該只是一堆文字名詞的堆砌，也就是說，我們堅決反對和不認可PPT做產品。
我們認為文字是一種表達，代碼也是一種表達，但有些內容只能通過代碼來表達，僅僅文字是表達不出的。我們選擇了“海量數據、實時、數據庫”這個極其復雜的場景作為“農田”，通過代碼表達技術、觀點和思考，分布式、高性能、高並發、架構設計、實時計算、存儲引擎、低延遲查詢等。
所以，我們接下來會更換技術棧，並重構存儲引擎等核心模塊，目標在讀、寫、時間序列線等核心指標能獲得數量級提升，並將FreeTSDB的高性能、高可用的實時計算、存儲引擎等核心能力，拓展到時序數據之外的數據場景，支持更豐富的系統形態，賦能更多的場景和業務。
另外我想說的是，初心是理想，但實用、務實才是我們的目標，我們希望能解決海量時序數據場景的挑戰，協助大家打造真正的實時監控系統和時序數據中台。
比如我最早接觸InfluxDB，也是為了解決實際場景的問題，打造海量時序數據中台，實現實時高效的接入計算能力、低成本的存儲能力、低延遲的查詢能力等。
當我們在互聯網上和大家交流討論時，也接到了很多來自實際場景的需求，比如阿里某童靴：
我做監控的，選型成本第一，沒有壓縮時間的都不能購買
期待有個和官方對齊的分布式版
我們也測試過XXX那個高可用版本，性能不行，不如單機，所以只能無奈分庫分表，但是中間層做了半年做不出來
這個分布式真的是硬核技術，期待beta早日出來，我馬上上
再比如，來自工業互聯網場景疑問和需求：
influxdb數據庫如何和plc通訊？ 或者說如何用influxdb數據庫實時監控plc的工作狀態？
這些問題的解決和需求支撐，也是FreeTSDB后續路線圖中的重中之重。
所以，接下來FreeTSDB會更加開放，它會在在兼容InfluxDB生態的同時，聯接其他開放的生態和系統。我們會在生態和場景上持續深耕，服務好來DevOps、IoT以及工業互聯網場景的需求，實事求是、腳踏實地的解決實際場景的問題，賦能業務！
最后我想說的是，如果你在時序數據場景（DevOps、IoT、工業互聯網等）上面臨痛點和挑戰，包括但不局限於實時計算、高效存儲、低延遲查詢、OLAP等，歡迎和我們聯系，我希望FreeTSDB能幫助到你！
延伸閱讀：
《為什么是InfluxDB | 寫在《InfluxDB原理和實戰》出版之際》
《我想和你聊聊：FreeTSDB不只是InfluxDB集群》
歡迎交流討論:
微信公眾號：influxdb-dev
FreeTSDB技術交流群（QQ）：663274123