這是InfluxData的時代

對於InfluxDB來說，這是一個令人振奮的時代，它是世界上最受歡迎的時間序列資料庫，根據DB-Engines.com，它是過去兩年中增長最快的資料庫類別。不過當Paul Dix和他的夥伴在十年前創立它的時候，並不是今天看到的InfluxDB的樣子。事實上，InfluxDB經歷了幾次轉型，才有了今天的成就，這反映了時間序列資料庫類別的演變。而且，更多的變化也即將出現。

Dix和Todd Persen於2012年6月共同創辦了InfluxData的前身Errplane，他們的想法是建立一個SaaS指標和監控平臺，就像Datadog或New Relic一樣。該公司已經從Y Combinator的2013年冬季班畢業，吸引了一些種子資金，並有大約20個付費客戶。

擁有正確的基礎技術對於Errplane的成功至關重要。幾年前曾在一家金融技術公司從事大規模時間序列資料工作的Dix，評估了當時的技術。

當然，當時還沒有打包的現成時間序列資料庫，所以他基本上是利用開源元件從頭開始建立一個。他用Apache Cassandra作為持久層，用Redis作為快速實時索引層，用Scala將其連線起來，並作為一個網路服務公開。這就是Errplane後臺的第一版。

到2013年底，Dix已經開發了第二版，在Errplane內部執行，使得Errplane從市場上眾多SaaS指標和監控供應商的中脫穎而出。他再一次從開源這個偉大的工具箱中尋找答案。

InfluxData聯合創始人&CTO  Paul Dix

“我拿起LevelDB，這是一個儲存引擎，最初是由Jeff Dean和Sanjay Ghemawat在谷歌編寫的，他們是谷歌有史以來最棒的兩個程式設計師，”Dix說。他用一種叫做Go的新語言編寫了V2的功能，並將這些功能作為REST API公開。

雖然產品執行良好，但越來越明顯的是，該公司正在掙扎。“我說，'你知道嗎，Errplane這個應用做得不好，是不可能起飛的。我們不會在這方面脫穎而出，”Dix說。“但我認為這裡的基礎設施有搞頭”。

事實證明，Errplane的客戶對該產品的伺服器指標和監控方面並不感興趣，而是對處理大量時間序列資料的能力感興趣。他的注意力被激起，Dix在那年秋天參加了在德國柏林舉行的Monitorama會議，這時他的懷疑得到了證實。

“我看到的是，從後端技術的角度來看，每個人都在試圖解決同樣的問題，”Dix告訴Datanami。“大公司的人正試圖推出自己的堆疊。他們正在尋找一個解決方案來儲存、查詢和處理大規模的時間序列資料。我們試圖建立更高階別的應用程式，而我們自己也在嘗試這樣做，這對供應商來說是一樣的。”

“退化”的用例

時間序列資料本身並不特別。任何資料都可以成為時間序列的一部分，這僅僅因為它有一個時間戳。但是，使用時間序列資料的應用型別確實有特殊的屬性，正是這些屬性推動了對管理時間序列資料的專業資料庫的需求。

在Dix看來，大量使用時間序列資料的應用屬於混合了OLAP和OLTP工作負載元素的類別，但兩者都不適合。

“實時性方面使它看起來有點像交易型工作負載，但事實上，它是大規模執行的歷史資料，你在上面做大量的分析，使它看起來像OLAP工作負載。”他說。

Dix說指出可以使用交易型資料庫來處理時間序列資料，而且人們經常這樣做，但是規模很快就會成為一個問題。“即便在達到真正的大規模之前，你每天都要插入幾百萬甚至幾十億條新記錄。”他指出。

Dix介紹，OLAP系統，比如如面向列的MPP資料庫和Hadoop風格的系統，常被設計用來處理大量的時間序列資料。但是OLAP系統的設計並不是為了對新資料提供連續的實時分析，使用時會有代價。

“他們(OLAP系統)會有一些時間段，在這些時間段裡，你攝入資料並將其轉換為更容易大規模查詢的格式，然後你每小時或每天執行一次報告。”"Dix說。

資料驅逐是時間序列資料需要特別處理的另一個方面的問題。時間序列資料的價值通常會隨著時間的推移而下降，因此為了降低成本，使用者通常會刪除舊的時間序列。

“現在，在事務性資料庫中，它並不是設計來刪除你放入資料庫中的每一條記錄的，”Dix說。“大多數事務性資料庫實際上是為了永久儲存資料而設計的。就像，你永遠不想失去它。因此，這些資料庫設計的目的不是為了自動清除過時的資料。”

由於這些挑戰，所有的大型伺服器指標和監控公司最終都建立了他們自己的時間序列資料庫，Dix說。“他們甚至不再使用現成的資料庫，因為這些不同的東西使時間序列成為我所說的‘退化’的用例。”

適時的新開端

到2015年，Dix和他的夥伴準備放棄Errplane，開始將後端作為時間序列資料庫出售。好訊息是他們已經走在了前面，因為他們已經有一個可以出售的資料庫。

“當我們釋出InfluxDB時，人們立即產生了興趣，”Dix說。“很明顯，我們馬上就發現了一些東西。開發人員有這個問題，他們需要這種技術來解決它。你如何儲存和查詢時間序列資料?不僅僅是在大規模上，而是如何在較低的規模上也能輕鬆做到這一點?”Dix說。

InfluxDB不需要大量的工作就能落地。最初的版本和Errplane V2後臺最大的不同是對查詢語言的需求，Dix把查詢語言比作灑在上面的 “語法糖”。這是以一種類似於SQL的語言的形式出現的，稱之為InfluxQL，使用者可以用它來編寫查詢(而不是僅僅使用REST API)。

但這項工作還沒有完成。InfluxData籌集了一些額外的資金，並開始開發新版本的資料庫，以及周邊的工具(ETL，視覺化，警報)，最終成為TICK平臺的一部分。

Dix也著手重建資料庫，InfluxDB 1.0在2016年9月首次亮相。

“那個版本的InfluxDB，我們從頭開始建立自己的儲存引擎，”Dix解釋說。“它在很大程度上受到LevelDB和那種設計的影響，但我們稱它為時間序列合併樹，LevelDB被稱為分層合併樹。因此，我們有自己的儲存引擎，但其他一切仍然是Go，這就是開源部分。”

對雲的開放

InfluxData在MIT許可下開放了原始碼，允許任何人獲得程式碼並使用它。這家舊金山公司還在AWS上開發了一個雲產品，為客戶提供了一個完全可管理的時間序列資料的體驗。它還開發了一個有高可用性和擴充套件叢集的閉源版本。

InfluxData TICK平臺

與此同時，InfluxData的平臺願景也在增長。2018年推出的TICK由四個部分組成：一個名為Telegraf的資料收集器;InfuxDB資料庫本身;視覺化工具Chronograf;以及處理引擎Kapacitor。

“我們想找出一種方法，以一種更有意義的方式將這四個不同的元件聯絡在一起，它們有一個統一的語言，”Dix說，他們用一種名為Flux的新語言來解決這個問題。“我們想做的另一件事是轉向雲優先的交付模式。”

雖然當時InfluxData的大部分客戶都是在本地部署，但Dix告訴開發團隊，他希望能夠在一年中的任何一天對平臺的任何部分進行更新。這一轉變在2019年完成，如今雲成為InfluxData業務中增長最快的部分。

上週，InfluxData釋出了幾個旨在幫助客戶處理物聯網(IoT)資料的新功能，包括更好地從邊緣複製到InfluxDB Cloud的集中例項;Telegraf對MQTT的支援;以及透過Flux更好地管理資料負載。

在不久的將來，InfluxDB的核心底層技術也會有一次重寫。

“我個人關注的感到興奮的大事是，我們基本上正在建立一個新的儲存技術核心，這將在今年取代雲環境中的一切。”"Dix說，“它是用Rust編寫的，而我們幾乎所有的其他東西都是用Go編寫的。現在廣泛使用Apache Arrow。”

Dix說介紹，使用Arrow將大大提高InfluxDB查詢的速度，以及查詢更大資料集的能力，公司還將增加使用老式SQL查詢資料庫的能力。他說它還將透過新增Python和JavaScript來增強Flux語言(用於定義後臺處理任務)。

雖然InfluxDB在時間序列資料庫領域有很大的領先優勢，但根據DB-Engines.com，該類別作為一個整體是相當年輕的，仍然處於成長階段。對於Dix來說，這意味著更廣闊的機會。

“對我來說，關於建立InfluxDB的關鍵見解是，時間序列是一種有用的抽象，可以解決許多不同領域的問題，”他說。“比如，伺服器監控是一個，使用者分析是另一個。金融市場資料、感測器資料、商業智慧等等不勝列舉。”

當你加入物聯網和機器學習這些時，時間序列分析的潛在機會變得更大。它最終會有多大?只有時間會告訴我們答案。