憑借著較早的入局時(shí)機(jī)， InfluxDB 在物聯(lián)網(wǎng)、時(shí)間序列數(shù)據(jù)場景下成為了第一批流行的時(shí)序數(shù)據(jù)庫，作為一些企業(yè)的首選數(shù)據(jù)庫之一被廣泛應(yīng)用，但經(jīng)過這些年的發(fā)展，伴隨著時(shí)序數(shù)據(jù)庫產(chǎn)品種類的增加，競爭的增大，InfluxDB 也成為了越來越多企業(yè)的“棄子”。本篇文章將會從實(shí)踐出發(fā)深究一下其中原因。

在物聯(lián)網(wǎng)等技術(shù)的快速發(fā)展下，大規(guī)模設(shè)備所產(chǎn)生的時(shí)間序列數(shù)據(jù)爆發(fā)式增長，企業(yè)在調(diào)研時(shí)序數(shù)據(jù)庫時(shí)，尤其看重?cái)?shù)據(jù)庫性能的強(qiáng)弱。聚焦“智慧環(huán)?！蔽锫?lián)網(wǎng)應(yīng)用研發(fā)的中科惠軟，此前就面臨著海量時(shí)間序列數(shù)據(jù)的查詢分析難題，希望能調(diào)研到一款合適的時(shí)序數(shù)據(jù)庫，助力產(chǎn)品發(fā)現(xiàn)深層次的環(huán)境問題，從而幫助污染源企業(yè)節(jié)能減排，增加效益。

由于 InfluxDB集群 版本需要收費(fèi)，最終他們選擇了單實(shí)例進(jìn)行對比測試，開始準(zhǔn)備兩臺配置參數(shù)一致的測試服務(wù)器進(jìn)行多方面的應(yīng)用場景、穩(wěn)定性以及性能測試。

以上中科惠軟所做的性能測試結(jié)果（僅供參考），InfluxDB 在寫入、查詢等方面的性能均遜于同類型產(chǎn)品 TDengine，且在中科惠軟的測試中還發(fā)現(xiàn)，InfluxDB 需要借助 Kafka、MQTT 等消息隊(duì)列中間件實(shí)現(xiàn)批量寫入，從而提升數(shù)據(jù)的寫入性能。綜合智能環(huán)保項(xiàng)目多方面應(yīng)用場景測試，以及后期智慧環(huán)保領(lǐng)域系統(tǒng)國產(chǎn)化需要，中科惠軟最終選型了 TDengine 來解決海量時(shí)間序列數(shù)據(jù)處理難題。

我們在做客戶調(diào)研時(shí)還發(fā)現(xiàn)，很多用戶在選型時(shí)，棄選 InfluxDB 的原因之一是其開源版本只支持一個節(jié)點(diǎn)，即 InfluxDB集群功能未開放，還存在前后版本兼容性問題，非國產(chǎn)化產(chǎn)品。以吉科軟公司為例，他們最初在車輛監(jiān)管項(xiàng)目中使用的就是 InfluxDB+Redis 的組合，但二期項(xiàng)目需要重新升級改版，不得不考慮業(yè)務(wù)規(guī)模的快速增加以及 InfluxDB集群功能不開放導(dǎo)致的單節(jié)點(diǎn)問題。

事實(shí)上，為了積累關(guān)注度以及使用人群，InfluxDB集群在最初也是開源狀態(tài)，后面在積累到一定的知名度后，InfluxDB集群又實(shí)行了閉源，從開源精神出發(fā)，這在一定程度上也是傷害了一眾投入關(guān)注和精力的開發(fā)者。但從公司業(yè)務(wù)角度而言，InfluxDB集群功能閉源也無可厚非，滿足了企業(yè)發(fā)展商業(yè)化的需求。

但不得不說，InfluxDB集群從免費(fèi)獲取到收費(fèi)獲取，成為了其尋求商業(yè)化變現(xiàn)的最有效途徑，也讓其失去了一部分的擁躉。而且對于一眾中國企業(yè)來說，盡管花費(fèi)了高昂的價(jià)格購買了 InfluxDB集群版本，但其產(chǎn)品性能是否真的能夠支撐自身業(yè)務(wù)的發(fā)展還是一個謎題，且作為一款外來的時(shí)序數(shù)據(jù)庫產(chǎn)品，InfluxDB 的本地化服務(wù)也十分有限。

綜上所述，InfluxDB集群不開放且服務(wù)費(fèi)用高昂，本地化服務(wù)質(zhì)量低以及產(chǎn)品性能不配位幾大原因，也算是導(dǎo)致 InfluxDB 在中國企業(yè)中的應(yīng)用逐年降低的“元兇”。