傳統(tǒng)的時序數(shù)據(jù)解決方案及問題如下：

1. MySQL等關(guān)系型數(shù)據(jù)庫：

· 寫入吞吐低：單機(jī)寫入吞吐低，很難滿足時序數(shù)據(jù)千萬級的寫入壓力;

· 存儲成本大：對于時序數(shù)據(jù)壓縮不佳，需占用大量機(jī)器資源;

· 維護(hù)成本高：單機(jī)系統(tǒng)，需要在上層人工的分庫分表，維護(hù)成本高;

· 查詢性能差：適用于交易處理，海量數(shù)據(jù)的聚合分析性能差。

2. Hadoop、Spark等批處理系統(tǒng)

· 數(shù)據(jù)延遲高：離線批處理系統(tǒng)，數(shù)據(jù)從產(chǎn)生到可分析，耗時數(shù)小時、甚至天級;

· 查詢性能差：不能很好的利用索引，依賴批處理任務(wù)，查詢耗時一般在分鐘級以上。

3. HBase

· 多維分析能力差：HBase可以較好的滿足寫入壓力，但對于非RowKey前綴的查詢性能較差;

· 維護(hù)成本：使用HBase需要同時維護(hù)HBase和Hadoop等系統(tǒng)，且HBase的穩(wěn)定性會進(jìn)一步加大維護(hù)成本。

寫入、存儲、查詢多環(huán)節(jié)優(yōu)化，時序數(shù)據(jù)庫優(yōu)勢明顯

1. 時序數(shù)據(jù)模型及特點(diǎn)

在引入時序數(shù)據(jù)庫之前，先要了解【時序數(shù)據(jù)】的模型及特點(diǎn)。

1.1 時序數(shù)據(jù)的數(shù)學(xué)模型

前面介紹了時序數(shù)據(jù)的場景，也說明了分析時序數(shù)據(jù)的意義及傳統(tǒng)方案。那么時序數(shù)據(jù)該怎樣存儲呢?數(shù)據(jù)的存儲要考慮其數(shù)學(xué)模型和特點(diǎn)，時序數(shù)據(jù)當(dāng)然也不例外。這里以一段時序數(shù)據(jù)為例，介紹下時序數(shù)據(jù)的數(shù)學(xué)模型。

下列數(shù)據(jù)記錄了一段時間內(nèi)某集群里各機(jī)器上各端口的出入流量，每半小時記錄一個觀測值：

· point： 一個時序數(shù)據(jù)點(diǎn)，類似于關(guān)系型數(shù)據(jù)庫中的 row;

· timestamp： 時間戳，表征時序數(shù)據(jù)產(chǎn)生的時間點(diǎn);

· tag： 維度列，用于描述設(shè)備/系統(tǒng)的屬性，表明是哪個設(shè)備/模塊產(chǎn)生的，一般不隨著時間變化;

· field： 指標(biāo)列，用于描述設(shè)備/系統(tǒng)狀態(tài)的變化，隨時間平滑波動。

1.2 時序數(shù)據(jù)特點(diǎn)

· 數(shù)據(jù)模式： 時序數(shù)據(jù)隨時間增長，相同設(shè)備/系統(tǒng)的維度信息不變，指標(biāo)平滑變化，這點(diǎn)從上面的Network表的數(shù)據(jù)變化可以看出。

· 寫入： 持續(xù)高并發(fā)寫入，無更新操作：時序數(shù)據(jù)庫面對的往往是百萬甚至千萬數(shù)量級終端設(shè)備的實(shí)時數(shù)據(jù)寫入(如摩拜單車2017年全國車輛數(shù)為千萬級)，但數(shù)據(jù)大多表征設(shè)備狀態(tài)，寫入后不會更新。

· 查詢： 按不同維度對指標(biāo)進(jìn)行統(tǒng)計分析，且存在明顯的冷熱數(shù)據(jù)，一般只會頻繁查詢近期數(shù)據(jù)。

2. 時序數(shù)據(jù)庫

2.1 時序數(shù)據(jù)庫

時序數(shù)據(jù)庫是管理時序數(shù)據(jù)的專業(yè)化數(shù)據(jù)庫，并針對時序數(shù)據(jù)的特點(diǎn)對寫入、存儲、查詢等流程進(jìn)行了優(yōu)化，從而解決時序數(shù)據(jù)處理難題：

· 存儲成本：

o 利用維度重復(fù)、時間遞增、指標(biāo)平滑變化等特性，合理選擇編碼壓縮算法，提高數(shù)據(jù)壓縮比;

o 通過預(yù)降精度，對歷史數(shù)據(jù)做聚合，節(jié)省存儲空間。

· 高并發(fā)寫入：

o 數(shù)據(jù)批量寫入，降低網(wǎng)絡(luò)開銷;

o 數(shù)據(jù)先寫入內(nèi)存，再周期性的dump為不可變的文件存儲，提高寫入速度。

· 低查詢延時，高查詢并發(fā)：

o 優(yōu)化常見的查詢模式，通過索引等技術(shù)降低查詢延時;

o 通過緩存、routing等技術(shù)提高查詢并發(fā)。

2.2 開源時序數(shù)據(jù)庫對比

目前行業(yè)內(nèi)比較流行的開源時序數(shù)據(jù)庫產(chǎn)品有 InfluxDB、OpenTSDB、Prometheus、Graphite等，其產(chǎn)品特性對比如下圖所示：

· 沒有free、易用的分布式版本(OpenTSDB支持分布式部署，但依賴系統(tǒng)過多，維護(hù)成本高);

· 聚合能力普遍較弱，而時序數(shù)據(jù)大多需要來做統(tǒng)計分析;

· 沒有free的權(quán)限管理;

· 沒有針對時間序列的多維度對比分析工具。

歷經(jīng)每日萬億寫入吞吐，騰訊云CTSDB技術(shù)架構(gòu)

騰訊CTSDB(Cloud Time Series Database)是一種分布式、高性能的時序數(shù)據(jù)庫，針對時序數(shù)據(jù)的高并發(fā)寫入、存在明顯的冷熱數(shù)據(jù)、IoT用戶場景等做了大量優(yōu)化，同時也支持各行業(yè)的日志解析和存儲。在騰訊內(nèi)部支撐騰訊云等每日萬億寫入吞吐的場景，經(jīng)過嚴(yán)苛的壓力打磨。其架構(gòu)如下圖所示：

· 高性能：(具體性能數(shù)據(jù)參考后文測試部分)

o 支持批量寫入、高并發(fā)查詢，以及強(qiáng)大的分析聚合能力;

o 通過橫向擴(kuò)展，線性提升系統(tǒng)性能;

o 支持sharding、routing，加速查詢。

· 高可靠：

o 分布式系統(tǒng)，支持多副本;

o 機(jī)架感知，自動錯開機(jī)架分配主從副本。

· 易使用：

o 豐富的數(shù)據(jù)類型，REST接口，數(shù)據(jù)寫入查詢均使用json格式;

o 原生分布式，彈性可伸縮，數(shù)據(jù)自動均衡;

o 權(quán)限系統(tǒng)：支持用戶名密碼、機(jī)器白名單的權(quán)限系統(tǒng)。

· 低成本：

o 支持列存儲，高壓縮比(0.1左右)，降低存儲成本;

o 支持?jǐn)?shù)據(jù)預(yù)降精度：降低存儲成本的同時，提高查詢性能。

o 副本數(shù)可按需調(diào)整。

· 兼容開源生態(tài)：

o 兼容Kibana/Logstash/Beat等組件，方便數(shù)據(jù)采集及可視化分析;

o 支持從MySQL、Kafka等開源生態(tài)同步數(shù)據(jù)，方便遷移。

2. 競品性能對比測試

這里選用業(yè)界較為流行的InfluxDB來與CTSDB做性能對比測試。

2.1 寫入性能測試

(1) CTSDB單節(jié)點(diǎn)集群與InfluxDB單機(jī)版寫入性能對比

結(jié)論: CTSDB單節(jié)點(diǎn)寫入性能最高在19w，InfluxDB在15w。

(2) CTSDB單節(jié)點(diǎn)集群與CTSDB雙節(jié)點(diǎn)集群寫入性能對比

結(jié)論：CTSDB單節(jié)點(diǎn)集群寫入最高可達(dá)20w，雙節(jié)點(diǎn)集群寫入性能34w。

2.2 查詢性能測試

(1) CTSDB單節(jié)點(diǎn)集群與InfluxDB單機(jī)版查詢性能對比

結(jié)論：

· CTSDB查詢性能整體比InfluxDB好很多，當(dāng)并發(fā)數(shù)較高時(40)，CTSDB查詢性能比InfluxDB高出近4倍，在2w左右。

· 在并發(fā)線程數(shù)達(dá)到50時，InfluxDB出現(xiàn)鏈接錯誤，拒絕查詢請求;此時，CTSDB可正常查詢。

(2) CTSDB單節(jié)點(diǎn)集群與雙節(jié)點(diǎn)集群查詢性能對比

結(jié)論

　　在并發(fā)數(shù)較高的情況下，雙節(jié)點(diǎn)集群查詢性能較單節(jié)點(diǎn)集群有了大幅度提升，呈現(xiàn)了查詢性能線性擴(kuò)展的趨勢。

關(guān)于我們

1. 我們的現(xiàn)狀

作為騰訊唯一的時序數(shù)據(jù)庫，CTSDB支撐了騰訊內(nèi)部20多個核心業(yè)務(wù)(微信彩票、財付通、云監(jiān)控、云數(shù)據(jù)庫、云負(fù)載等)。其中，云監(jiān)控系統(tǒng)記錄了騰訊內(nèi)部各種軟硬件系統(tǒng)的實(shí)時狀態(tài)，CTSDB承載了它所有的數(shù)據(jù)存儲，在每秒千萬級數(shù)據(jù)點(diǎn)的寫入壓力、每天20TB+數(shù)據(jù)量的寫入場景下穩(wěn)定運(yùn)行，足以證明CTSDB可以穩(wěn)定支撐物聯(lián)網(wǎng)的海量數(shù)據(jù)場景。

2. 我們的未來

songjy