導讀：本文帶你了解一個開源的、高性能的時序型數(shù)據(jù)庫——InfluxDB。

作者：韓健

來源：華章科技

00 為什么QQ要選擇InfluxDB？

從2016年起，筆者在騰訊公司負責QQ后臺的海量服務(wù)分布式組件的架構(gòu)設(shè)計和研發(fā)工作，如微服務(wù)開發(fā)框架、名字路由、名字服務(wù)、配置中心等，做了大量分布式架構(gòu)、高性能架構(gòu)、海量服務(wù)、過載保護、柔性可用、負載均衡、容災(zāi)、水平擴展等方面的工作，以公共組件的形式支撐來自QQ后臺和其他BG海量服務(wù)的海量流量。

2018年年底，筆者負責監(jiān)控大數(shù)據(jù)平臺的研發(fā)工作，致力于減少現(xiàn)有監(jiān)控后臺成本，以及支撐內(nèi)部和外部海量監(jiān)控數(shù)據(jù)的需求，打造千億級監(jiān)控大數(shù)據(jù)平臺。

筆者發(fā)現(xiàn)，當前監(jiān)控技術(shù)領(lǐng)域缺乏優(yōu)秀的監(jiān)控系統(tǒng)，尤其是在海量監(jiān)控數(shù)據(jù)場景中，很多團隊常用的做法是堆服務(wù)器和堆開源軟件，比如大量采用高配置的服務(wù)器，單機近百CPU核數(shù)、TB內(nèi)存、數(shù)十TB的SSD存儲，安裝了大量開源軟件，如Elasticsearch、Druid、Storm、Kafka、Hbase、Flink、OpenTSDB、Atlas、MongoDB等，但實際效果并不理想。

眾多開源軟件的組合是在增加了系統(tǒng)的運營成本和數(shù)據(jù)的處理延遲的情況下解決接入計算，在海量標簽和時間序列線情況下，常出現(xiàn)查詢超時、數(shù)據(jù)拉不出來等問題，且成本高昂。

筆者認為，海量或千億級是整體的量，是個籠統(tǒng)的概念，可以分而治之，通過分集群的方法來解決，海量監(jiān)控數(shù)據(jù)的真正挑戰(zhàn)在于以下幾點：

• 能否做到實時。實時是種質(zhì)變的能力，可將一個離線監(jiān)控平臺提升為一個實時決策系統(tǒng)。難點在于能否設(shè)計實現(xiàn)高性能的架構(gòu)，以及能否實現(xiàn)水平擴展等。
• 分集群后，單個業(yè)務(wù)的流量大小、標簽集多少是關(guān)鍵。流量大，相對容易解決，主要涉及系統(tǒng)性能和水平擴展等。標簽集多，海量標簽，海量時間序列線，如何做查詢優(yōu)化是挑戰(zhàn)，如筆者遇到的一些業(yè)務(wù)上報的監(jiān)控數(shù)據(jù)，有幾十個維度的標簽，并將QQ號和URL作為標簽值，有非常海量的時間序列線。
• 針對監(jiān)控數(shù)據(jù)多寫少讀、成本敏感的特點，如何設(shè)計高效的存儲引擎？既能充分發(fā)揮硬件性能，又能在高效壓縮存儲的同時保障查詢效率。

為了更好地打造有競爭力的監(jiān)控系統(tǒng)，我們將技術(shù)理念定位為“技術(shù)降成本，堅決反對開源軟件堆砌”。

• 首先，我們認為云計算是基建，決定它能否成功的關(guān)鍵在于能否在基礎(chǔ)技術(shù)上突破，打造出相比開源軟件更有成本優(yōu)勢的云原生軟件；
• 其次，雖然現(xiàn)在開源軟件非常繁榮，基于開源軟件，我們很容易搭建一個基礎(chǔ)系統(tǒng)，將功能跑起來，但絕大部分開源軟件側(cè)重的是功能，而不是針對海量監(jiān)控數(shù)據(jù)的場景進行設(shè)計，或多或少都有其局限性，且成本也非常高昂。

因此我們要做的是借助強大的技術(shù)和工程能力，直面問題，在架構(gòu)和源碼層面解決它，而不是引入和堆砌更多的開源軟件。

出于工程效率的考慮，我們選擇基于開源軟件進行二次開發(fā)，使用開源軟件的部分代碼，按照我們的想法進行架構(gòu)設(shè)計和功能開發(fā)。在對眾多的開源軟件進行調(diào)研分析后，我們最終選擇了以InfluxDB源碼為基礎(chǔ)進行二次開發(fā)。

之所以選擇InfluxDB源碼，主要是因為我們對InfluxDB源碼背后的技術(shù)和工程實力比較認可。InfluxDB研發(fā)團隊能真正解決海量監(jiān)控數(shù)據(jù)場景的問題，也是在認真地打造一款優(yōu)秀的監(jiān)控產(chǎn)品(出于讀寫性能和可用性的考慮，InfluxDB研發(fā)團隊曾2次重構(gòu)存儲引擎)。

在筆者著手以InfluxDB源碼為基礎(chǔ)開發(fā)集群等功能時，業(yè)界還沒有團隊實現(xiàn)了真正可用的InfluxDB集群能力。一些團隊只是通過Proxy實現(xiàn)了負載均衡，卻無法突破單機接入計算和存儲的限制，缺乏一致性能力。

有些團隊在對InfluxDB進行了多年的學習和研究后，最終考慮到基于時序分片的復雜度而放棄了基于InfluxDB開發(fā)集群能力，轉(zhuǎn)而選擇基于RocksDB、Zookeeper等開源軟件進行自建。

筆者在3個月內(nèi)快速開發(fā)出了CP和AP架構(gòu)分離、時序分片、水平擴展等基本集群能力，另外，根據(jù)業(yè)務(wù)的特點，在索引引擎、冷熱分離、查詢實現(xiàn)、第三方協(xié)議、高可用性、可運營性等方面也做了大量的工作。

最終的效果也是符合預期的，如從替換現(xiàn)有監(jiān)控系統(tǒng)后臺的實施對比來看，我們用了不到10%的機器成本就支撐起原監(jiān)控后臺所支撐的海量監(jiān)控數(shù)據(jù)，成本優(yōu)勢突出。

InfluxDB是一款非常優(yōu)秀的軟件，直接推動監(jiān)控技術(shù)進入了實時、納秒級的新時代，除了類SQL查詢語言、RESTful API等現(xiàn)代特性外，還具有讀寫性能高、存儲壓縮率高、生態(tài)豐富、功能強大等特性。

01 什么是InfluxDB

InfluxDB是一個開源的、高性能的時序型數(shù)據(jù)庫，在時序型數(shù)據(jù)庫DB-Engines Ranking上排名第一。

在介紹InfluxDB之前，先來介紹下時序數(shù)據(jù)。按照時間順序記錄系統(tǒng)、設(shè)備狀態(tài)變化的數(shù)據(jù)被稱為時序數(shù)據(jù)(Time Series Data)，如CPU利用率、某一時間的環(huán)境溫度等。

時序數(shù)據(jù)以時間作為主要的查詢緯度，通常會將連續(xù)的多個時序數(shù)據(jù)繪制成線，制作基于時間的多緯度報表，用于揭示數(shù)據(jù)背后的趨勢、規(guī)律、異常，進行實時在線預測和預警，時序數(shù)據(jù)普遍存在于IT基礎(chǔ)設(shè)施、運維監(jiān)控系統(tǒng)和物聯(lián)網(wǎng)中。

時序數(shù)據(jù)主要有如下3個特點：

• 抵達的數(shù)據(jù)幾乎總是作為新條目被記錄，無更新操作。
• 數(shù)據(jù)通常按照時間順序抵達。
• 時間是一個主坐標軸。

時序型數(shù)據(jù)庫是存放時序數(shù)據(jù)的專用型數(shù)據(jù)庫，并且支持時序數(shù)據(jù)的快速寫入、持久化、多緯度的實時聚合運算等功能。

傳統(tǒng)數(shù)據(jù)庫通常記錄數(shù)據(jù)的當前值，時序型數(shù)據(jù)庫則記錄所有的歷史數(shù)據(jù)，在處理當前時序數(shù)據(jù)時又要不斷接收新的時序數(shù)據(jù)，同時時序數(shù)據(jù)的查詢也總是以時間為基礎(chǔ)查詢條件，并專注于解決以下海量數(shù)據(jù)場景的問題：

• 時序數(shù)據(jù)的寫入：如何支持千萬級/秒數(shù)據(jù)的寫入。
• 時序數(shù)據(jù)的讀取：如何支持千萬級/秒數(shù)據(jù)的聚合和查詢。
• 成本敏感：海量數(shù)據(jù)存儲帶來的是成本問題，如何更低成本地存儲這些數(shù)據(jù)，是時序型數(shù)據(jù)庫需要解決的關(guān)鍵問題。

InfluxDB是一個由InfluxData公司開發(fā)的開源時序型數(shù)據(jù)庫，專注于海量時序數(shù)據(jù)的高性能讀、高性能寫、高效存儲與實時分析，在DB-Engines Ranking時序型數(shù)據(jù)庫排行榜上位列榜首，廣泛應(yīng)用于DevOps監(jiān)控、IoT監(jiān)控、實時分析等場景。

具體的DB-Engines Ranking時序型數(shù)據(jù)庫的排行榜(源自2019年5月的DB-Engines Ranking數(shù)據(jù))如圖1-1所示。

• InfluxDB部署簡單、使用方便，在技術(shù)實現(xiàn)上充分利用了Go語言的特性，無須任何外部依賴即可獨立部署；
• 提供類似于SQL的查詢語言，接口友好，使用方便；擁有豐富的聚合運算和采樣能力；
• 提供靈活的數(shù)據(jù)保留策略(Retention Policy)來設(shè)置數(shù)據(jù)的保留時間和副本數(shù)；
• 在保障數(shù)據(jù)可靠性的同時，及時刪除過期數(shù)據(jù)，釋放存儲空間；
• 提供靈活的連續(xù)查詢(Continuous Query)來實現(xiàn)對海量數(shù)據(jù)的采樣。
• 支持多種通信協(xié)議，除了HTTP、UDP等原生協(xié)議，還兼容CollectD、Graphite、OpenTSDB、Prometheus等組件的通信協(xié)議。

▲圖1-1 時序型數(shù)據(jù)庫DB-Engines Ranking排名

講到InfluxDB，就不能不提InfluxData的開源高性能時序中臺TICK(Telegraf + InfluxDB + Chronograf + Kapacitor)，InfluxDB是作為TICK的存儲系統(tǒng)進行設(shè)計和開發(fā)的。

TICK專注于DevOps監(jiān)控、IoT監(jiān)控、實時分析等應(yīng)用場景，是一個集成了采集、存儲、分析、可視化等能力的開源時序中臺，由Telegraf、 InfluxDB、Chronograf、Kapacitor 4個組件以一種靈活松散但緊密配合、互為補充的方式構(gòu)成，各個模塊相互配合、互為補充，整體系統(tǒng)架構(gòu)如圖1-2所示。

▲圖1-2 TICK系統(tǒng)架構(gòu)

Telegraf是用于采集和上報指標的數(shù)據(jù)采集程序，采用靈活的、可配置的插件實現(xiàn)。

Telegraf可以通過配置文件的配置，采集當前運行主機的指定指標，如CPU負載、內(nèi)存使用等，也可以從第三方消費者服務(wù)(如StatsD、Kafka等)拉取數(shù)據(jù)，上報到已支持的多種存儲系統(tǒng)、服務(wù)或消息隊列，如InfluxDB、Graphite、OpenTSDB、Datadog、Librato、Kafka、MQTT、NSQ等。

InfluxDB是專注于時序數(shù)據(jù)場景(如DevOps監(jiān)控、IoT監(jiān)控、實時分析等)的高性能時序型數(shù)據(jù)庫，支持靈活的自定義保留策略和類SQL的操作接口。

Chronograf是可視化的、BS架構(gòu)的管理系統(tǒng)，可用于配置和管理接收到的監(jiān)控數(shù)據(jù)、告警，并支持通過靈活強大的模塊和庫，快速配置數(shù)據(jù)可視化儀表盤、告警規(guī)則、可視化規(guī)則。

Kapacitor是從零構(gòu)建的原生數(shù)據(jù)處理引擎，支持流式處理和批量處理，支持靈活強大的自定義功能，如定義新的告警閾值、告警指標特征、告警統(tǒng)計異常特征等，以及后續(xù)的告警處理行為。

除了靈活，Kapacitor也很開放，能靈活地集成對接第三系統(tǒng)，如HipChat、OpsGenie、Alerta、Sensu、PagerDuty、Slack等。

02 InfluxDB的優(yōu)勢

存儲和分析時序數(shù)據(jù)的時序型系統(tǒng)并不鮮見，自計算機問世以來，我們一直在數(shù)據(jù)庫中存儲時序數(shù)據(jù)。

最初，使用通用存儲系統(tǒng)存儲時序數(shù)據(jù)，如MySQL。第一代時序平臺，如KDB +、RRDtool、Graphite等，在20年前就推出了，主要用于存儲和分析數(shù)據(jù)中心的時序數(shù)據(jù)，以及高頻金融數(shù)據(jù)、股票波動率等。

根據(jù)DB-Engines等數(shù)據(jù)庫趨勢跟蹤和行業(yè)分析網(wǎng)站發(fā)布的信息，時序型數(shù)據(jù)庫是數(shù)據(jù)庫市場中份額增長最快的部分。原因很明顯，計算機虛擬世界，如數(shù)據(jù)庫、網(wǎng)絡(luò)、容器、系統(tǒng)、應(yīng)用程序等，和物理世界，如家用設(shè)備、城市基礎(chǔ)設(shè)施、工廠機器、電力設(shè)施等，正在創(chuàng)建海量的時序數(shù)據(jù)。

現(xiàn)在更多的企業(yè)會通過時序存儲和數(shù)據(jù)分析來獲得預測能力和實時決策能力，從而為客戶提供更好的使用體驗。這意味著底層數(shù)據(jù)平臺需要發(fā)展以應(yīng)對新的工作負載的挑戰(zhàn)，以及更多的數(shù)據(jù)點、數(shù)據(jù)源、監(jiān)控維度、控制策略和精度更高的實時響應(yīng)，對下一代時序中臺提出了更高的要求，具體如下所示。

• 專為時序存儲和高性能讀寫而設(shè)計：計算機虛擬世界的各種系統(tǒng)和應(yīng)用，以及物理世界的IoT設(shè)備等都在創(chuàng)建海量的時序數(shù)據(jù)，每秒千萬級的數(shù)據(jù)吞吐量是很常見的，而且這些數(shù)據(jù)還需要可以以非阻塞方式接收并且可壓縮以節(jié)省有限的存儲資源。
• 專為實時操作而設(shè)計：預測能力和實時決策能力，需要收到數(shù)據(jù)后，就能實時輸出最新的數(shù)據(jù)分析結(jié)果，執(zhí)行預定義的操作。
• 專為高可用性而設(shè)計：現(xiàn)代軟件系統(tǒng)需要全天候可用，除了基本的集群能力，還需要根據(jù)需求自動擴容和縮容，支持柔性可用等。

InfluxData選擇從頭開始構(gòu)建InfluxDB以支持下一代時序中臺的需求，InfluxDB通過實現(xiàn)高度可擴展的數(shù)據(jù)接收和存儲引擎，可以高效地實時收集、存儲、查詢、可視化顯示和執(zhí)行預定義操作。它通過連續(xù)查詢提升查詢效率和縮短延遲，通過數(shù)據(jù)保留策略，及時高效地刪除過期冷數(shù)據(jù)，提升存儲效率。

為什么通用數(shù)據(jù)庫在時序場景上不是最優(yōu)的選擇呢？許多通用數(shù)據(jù)庫正在為時序數(shù)據(jù)添加一些支持，雖然可能很容易使用，但它們基本上都不是針對海量時序數(shù)據(jù)的吞吐量和實時操作而設(shè)計的。

與InfluxDB相比，通用數(shù)據(jù)庫，如Cassandra、MongoDB、HBase等，需要開發(fā)人員投入大量的時間進行代碼編寫，以開發(fā)與InfluxDB類似的功能。具體來說，開發(fā)人員需要做如下工作：

• 編寫代碼實現(xiàn)跨集群數(shù)據(jù)分片功能、聚合運算和采樣功能、數(shù)據(jù)生命周期管理功能等。
• 實現(xiàn)豐富的API接口。
• 編寫用于數(shù)據(jù)采集的工具。
• 實現(xiàn)實時處理模塊并編寫用于監(jiān)控和警報的代碼。
• 編寫可視化引擎以向用戶顯示時序數(shù)據(jù)。

為了讓讀者對InfluxDB的優(yōu)勢有個直觀的認識，接下來，會把InfluxDB和其他被用作時序存儲的系統(tǒng)(如ElasticSearch、MongoDB、OpenTSDB)做簡要的對比：

1. InfluxDB vs ElasticSearch

ElasticSearch是專為搜索而設(shè)計的系統(tǒng)，是實現(xiàn)搜索功能的絕佳選擇。

然而，對于時序數(shù)據(jù)，卻并非如此。在處理時序數(shù)據(jù)時，InfluxDB的性能遠遠超過ElasticSearch系統(tǒng)，對于寫入吞吐量，InfluxDB通常優(yōu)于ElasticSearch 5～10倍，具體差值取決于架構(gòu)。對于特定時序的查詢速度，使用ElasticSearch比使用InfluxDB要慢5～100倍，具體差值取決于查詢的時間范圍。

最后，如果需要存儲原始數(shù)據(jù)以便稍后查詢，則ElasticSearch上的硬盤占用比InfluxDB大10～15倍。如果先匯總數(shù)據(jù)再存儲，ElasticSearch的硬盤占用比InfluxDB大3～4倍。綜合來看，ElasticSearch非常適合進行搜索，但不適用于時序存儲和實時分析。

2. InfluxDB vs MongoDB

MongoDB是一個開源的、面向文檔的數(shù)據(jù)庫，俗稱NoSQL數(shù)據(jù)庫，用C和C ++語言編寫。雖然它通常不被認為是真正的時序型數(shù)據(jù)庫(TSDB)，但它經(jīng)常被用作時序存儲系統(tǒng)。它以時間戳和分組的形式提供建模原語，使用戶能夠存儲和查詢時序數(shù)據(jù)。

MongoDB旨在存儲“無模式”數(shù)據(jù)，其中每個對象可能具有不同的結(jié)構(gòu)。實際上，MongoDB通常用于存儲內(nèi)容大小可變的JSON或BSON對象。由于其采用通用性和無模式數(shù)據(jù)存儲區(qū)設(shè)計，MongoDB無法利用時序數(shù)據(jù)的高度結(jié)構(gòu)化特性。

需要特別指出的是，時序數(shù)據(jù)由標簽(鍵/值串對)和時間戳組成，這時必須對MongoDB做專門配置以支持時序數(shù)據(jù)，但這樣做效率很低。

相比MongoDB，InfluxDB的性能和成本優(yōu)勢明顯，InfluxDB的寫性能大約是MongoDB的2.4倍，存儲效率大約是MongoDB的20倍，查詢效率大約是MongoDB的5.7倍。綜合來看，MongoDB非常適合文檔和自定義對象，但不適用于大規(guī)模的時序數(shù)據(jù)和實時分析。

3. InfluxDB vs OpenTSDB

OpenTSDB是一個可擴展的分布式時序型數(shù)據(jù)庫，用Java語言編寫，構(gòu)建在HBase之上。它最初是由Beno?t Sigoure于2010年開始編寫的，并在LGPL下開源。

OpenTSDB不是一個獨立的時序型數(shù)據(jù)庫，相反，它依賴HBase作為其數(shù)據(jù)存儲層，因此OpenTSDB時序守護進程(OpenTSDB中的TSD用語)在實例之間沒有共享狀態(tài)可以高效地提供查詢引擎的功能。

OpenTSDB允許通過其API進行簡單的聚合和數(shù)學運算，但沒有完整的查詢語言。OpenTSDB支持毫秒的分辨率，但隨著亞毫秒級操作的普及，OpenTSDB有時會出現(xiàn)精度不足的問題。

相比OpenTSDB，InfluxDB的性能和成本優(yōu)勢明顯，InfluxDB的寫性能大約是OpenTSDB的5倍，存儲效率大約是OpenTSDB的16.5倍，查詢效率大約是OpenTSDB的3.65倍。

另外，OpenTSDB的設(shè)計初衷主要是用于生成儀表板圖，不是為了滿足任意查詢，也不是為了存儲數(shù)據(jù)。這些限制會影響它的使用方式。

03 InfluxDB的特性

作為一個開源系統(tǒng)，InfluxDB究竟有什么魅力吸引了如此多的用戶，從而在時序型數(shù)據(jù)庫DB-Engines Ranking上排名第一呢？

1. InfluxDB的特點

InfluxDB是支持時序數(shù)據(jù)高效讀寫、壓縮存儲、實時計算能力的數(shù)據(jù)庫服務(wù)，除了具有成本優(yōu)勢的高性能讀、高性能寫、高存儲率，InfluxDB還具有如下特點：

• 無系統(tǒng)環(huán)境依賴，部署方便。
• 無模式(schema-less)的數(shù)據(jù)模型，靈活強大。
• 原生HTTP管理接口，免插件配置和免第三方依賴。
• 強大的類SQL查詢語句，學習成本低，上手快。
• 豐富的權(quán)限管理功能：精細到“表”級別。
• 豐富的時效管理功能：自動刪除過期數(shù)據(jù)，自定義刪除指標數(shù)據(jù)。
• 低成本存儲，采樣時序數(shù)據(jù)，壓縮存儲。
• 豐富的聚合函數(shù)，支持AVG、SUM、MAX、MIN等聚合函數(shù)。

2. 核心概念

InfluxDB實現(xiàn)了類SQL的接口，盡管與傳統(tǒng)關(guān)系型數(shù)據(jù)庫(如MySQL)語法相似，但InfluxDB在語義體系上有些差別，接下來將以一條CPU利用率的時序數(shù)據(jù)為例介紹相關(guān)的核心概念，如代碼清單1-3所示。

• 代碼清單1-3 一條CPU利率的時序數(shù)據(jù)

>?insert?cpu_usage,host=server01,location=cn-sz?user=23.0,system=57.0>?select?*?from?cpu_usagename:?cpu_usagetime?????????????host?????location?system?user----?????????????----?????--------?------?----1557834774258860710?server01?cn-sz????55?????25>

• 時間(Time)：如代碼清單1-3中的“1557834774258860710”，表示數(shù)據(jù)生成時的時間戳，與MySQL不同的是，在InfluxDB中，時間幾乎可以看作主鍵的代名詞。
• 表(Measurement)：如代碼清單1-3中的“cpu_usage”，表示一組有關(guān)聯(lián)的時序數(shù)據(jù)，類似于MySQL中表(Table)的概念。
• 標簽(Tag)：如代碼清單1-3中的“host=server01”和“l(fā)ocation=cn-sz”，用于創(chuàng)建索引，提升查詢性能，一般存放的是標示數(shù)據(jù)點來源的屬性信息，在代碼清單1-3中，host和location分別是表中的兩個標簽鍵，對應(yīng)的標簽值分別為server01和cn-sz。
• 指標(Field)：如代碼清單1-3中的“user=23.0”和“system=57.0”，一般存放的是具體的時序數(shù)據(jù)，即隨著時間戳的變化而變化的數(shù)據(jù)，與標簽不同的是，未對指標數(shù)據(jù)創(chuàng)建索引，在代碼清單1-3中，user和system分別是表中的兩個指標鍵，對應(yīng)的指標值分別為23.0和57.0。
• 時序數(shù)據(jù)記錄(Point)：如代碼清單1-3中的“1557834774258860710 server01 cn-sz 55 25”，表示一條具體的時序數(shù)據(jù)記錄，由時序(Series)和時間戳(Timestamp)唯一標識，類似于MySQL中的一行記錄。
• 保留策略(Retention Policy)：定義InfluxDB的數(shù)據(jù)保留時長和數(shù)據(jù)存儲的副本數(shù)，通過設(shè)置合理的保存時間(Duration) 和副本數(shù)(Replication)，在提升數(shù)據(jù)存儲可用性的同時，避免數(shù)據(jù)爆炸。
• 時間序列線(Series)：表示表名、保留策略、標簽集都相同的一組數(shù)據(jù)。

關(guān)于作者：韓健，資深架構(gòu)師，現(xiàn)就職于騰訊，擔任監(jiān)控大數(shù)據(jù)平臺技術(shù)負責人，曾先后擔任創(chuàng)業(yè)公司CTO、Intel資深工程師。既對分布式系統(tǒng)、InfluxDB的架構(gòu)設(shè)計和開發(fā)有深刻的理解，又在海量服務(wù)分布式組件架構(gòu)設(shè)計、高性能架構(gòu)設(shè)計、高質(zhì)量代碼編寫等方面有深厚的積累，經(jīng)驗豐富。

本文摘編自《InfluxDB原理與實戰(zhàn)》，經(jīng)出版方授權(quán)發(fā)布。

延伸閱讀《InfluxDB原理與實戰(zhàn)》

推薦語：InfluxDB技術(shù)專家基于DB-Engines排名TOP的時序數(shù)據(jù)庫，打造千億級大數(shù)據(jù)監(jiān)控平臺經(jīng)驗總結(jié)。包含9個企業(yè)級案例，100余示例，300余條命令和語法。

總結(jié)

以上是生活随笔為你收集整理的influxdb数据过期_为什么腾讯QQ的大数据平台选择了InfluxDB数据库？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。