[an error occurred while processing the directive]
一、背景
隨著移動網際網路、物聯網、大數據等行業的高速發展，數據在持續的以指數級的速度增長，比如我們使用手機訪問互網絡時的行為數據，各種可穿戴設備上報的狀態數據，工廠中設備傳感器採集的指標數據，傳統網際網路公司的監控數據等。實際上，這些按照時間順序記錄系統、設備狀態變化的數據都是時序數據（Time Series），它普遍存在於網際網路、物聯網、IT基礎設施中。
得益於軟硬體技術的快速發展，處理如此龐大的時序數據集的成本在持續降低，更多公司開始持續收集、分析數據，用於異常處理、趨勢預測、精準營銷、風險控制等場景，希望利用數據的潛在價值，提高公司盈利能力和競爭力。這裡舉兩個例子：
1.下圖為某共享單車在舊金山某熱門區域的車輛借還情況。通過分析該區域車輛的歷史借還數據，單車公司可優化熱點時間段的車輛補給。
2. 下圖為某網際網路服務的出入流量歷史記錄。從圖中可以明顯看到入流量（藍色線）在某時間段有毛刺，服務提供商可基於此段時間排查服務有無異常。可以進一步基於流量監控做告警，使運維人員能夠及時處理線上問題。
二、傳統時序數據解決方案存在大量問題
傳統的時序數據解決方案及問題如下：
1. MySQL等關係型資料庫：
寫入吞吐低：單機寫入吞吐低，很難滿足時序數據千萬級的寫入壓力；存儲成本大：對於時序數據壓縮不佳，需佔用大量機器資源；維護成本高：單機系統，需要在上層人工的分庫分表，維護成本高；查詢性能差：適用於交易處理，海量數據的聚合分析性能差。
2. Hadoop、Spark等批處理系統
數據延遲高：離線批處理系統，數據從產生到可分析，耗時數小時、甚至天級；查詢性能差：不能很好的利用索引，依賴批處理任務，查詢耗時一般在分鐘級以上。
3. HBase
多維分析能力差：HBase可以較好的滿足寫入壓力，但對於非RowKey前綴的查詢性能較差；維護成本：使用HBase需要同時維護HBase和Hadoop等系統，且HBase的穩定性會進一步加大維護成本。
三、寫入、存儲、查詢 多環節優化，時序資料庫 優勢明顯
1. 時序數據模型及特點 在引入時序資料庫之前，先要了解【時序數據】的模型及特點。 1.1 時序數據的數學模型
前面介紹了時序數據的場景，也說明了分析時序數據的意義及傳統方案。那麼時序數據該怎樣存儲呢？數據的存儲要考慮其數學模型和特點，時序數據當然也不例外。這裡以一段時序數據為例，介紹下時序數據的數學模型。
下列數據記錄了一段時間內某集群裡各機器上各埠的出入流量，每半小時記錄一個觀測值：
metric： 相關聯的數據集合，類似於關係型資料庫中的 table；point： 一個時序數據點，類似於關係型資料庫中的 row；timestamp： 時間戳，表徵時序數據產生的時間點；tag： 維度列，用於描述設備/系統的屬性，表明是哪個設備/模塊產生的，一般不隨著時間變化；field： 指標列，用於描述設備/系統狀態的變化，隨時間平滑波動。 1.2 時序數據特點 數據模式： 時序數據隨時間增長，相同設備/系統的維度信息不變，指標平滑變化，這點從上面的Network表的數據變化可以看出。寫入： 持續高並發寫入，無更新操作：時序資料庫面對的往往是百萬甚至千萬數量級終端設備的實時數據寫入（如摩拜單車2017年全國車輛數為千萬級），但數據大多表徵設備狀態，寫入後不會更新。查詢： 按不同維度對指標進行統計分析，且存在明顯的冷熱數據，一般只會頻繁查詢近期數據。 2. 時序資料庫 2.1 時序資料庫
時序資料庫是管理時序數據的專業化資料庫，並針對時序數據的特點對寫入、存儲、查詢等流程進行了優化，從而解決時序數據處理難題：
存儲成本： 利用維度重複、時間遞增、指標平滑變化等特性，合理選擇編碼壓縮算法，提高數據壓縮比； 通過預降精度，對歷史數據做聚合，節省存儲空間。高並發寫入： 數據批量寫入，降低網絡開銷； 數據先寫入內存，再周期性的dump為不可變的文件存儲，提高寫入速度。低查詢延時，高查詢並發： 優化常見的查詢模式，通過索引等技術降低查詢延時； 通過緩存、routing等技術提高查詢並發。 2.2 開源時序資料庫對比
目前行業內比較流行的開源時序資料庫產品有 InfluxDB、OpenTSDB、Prometheus、Graphite等，其產品特性對比如下圖所示：
從上表可以看出，開源的時序資料庫存在如下問題：
沒有free、易用的分布式版本（OpenTSDB支持分布式部署，但依賴系統過多，維護成本高）；聚合能力普遍較弱，而時序數據大多需要來做統計分析；沒有free的權限管理；沒有針對時間序列的多維度對比分析工具。
四、歷經每日萬億寫入吞吐，騰訊雲CTSDB技術架構
騰訊CTSDB（Cloud Time Series Database）是一種分布式、高性能的時序資料庫，針對時序數據的高並發寫入、存在明顯的冷熱數據、IoT用戶場景等做了大量優化，同時也支持各行業的日誌解析和存儲。在騰訊內部支撐騰訊雲等每日萬億寫入吞吐的場景，經過嚴苛的壓力打磨。其架構如下圖所示：
1. CTSDB主要特點 高性能：（具體性能數據參考後文測試部分） 支持批量寫入、高並發查詢，以及強大的分析聚合能力； 通過橫向擴展，線性提升系統性能； 支持sharding、routing，加速查詢。高可靠： 分布式系統，支持多副本； 機架感知，自動錯開機架分配主從副本。易使用： 豐富的數據類型，REST接口，數據寫入查詢均使用json格式； 原生分布式，彈性可伸縮，數據自動均衡； 權限系統：支持用戶名密碼、機器白名單的權限系統。低成本： 支持列存儲，高壓縮比（0.1左右），降低存儲成本； 支持數據預降精度：降低存儲成本的同時，提高查詢性能。 副本數可按需調整。兼容開源生態： 兼容Kibana/Logstash/Beat等組件，方便數據採集及可視化分析； 支持從MySQL、Kafka等開源生態同步數據，方便遷移。 2. 競品性能對比測試
這裡選用業界較為流行的InfluxDB來與CTSDB做性能對比測試。
2.1 寫入性能測試
(1) CTSDB單節點集群與InfluxDB單機版寫入性能對比
橫坐標：並發數（寫入線程數） ，縱坐標：QPS（單位：萬次/s）
結論: CTSDB單節點寫入性能最高在19w，InfluxDB在15w。
(2) CTSDB單節點集群與CTSDB雙節點集群寫入性能對比
橫坐標：並發數（寫入線程數） ，縱坐標：QPS（單位：萬次/s）
結論：CTSDB單節點集群寫入最高可達20w，雙節點集群寫入性能34w。
2.2 查詢性能測試
(1) CTSDB單節點集群與InfluxDB單機版查詢性能對比
橫坐標：並發數（查詢線程數） ，縱坐標：QPS（單位：次/s）
結論：
CTSDB查詢性能整體比InfluxDB好很多，當並發數較高時（40），CTSDB查詢性能比InfluxDB高出近4倍，在2w左右。在並發線程數達到50時，InfluxDB出現連結錯誤，拒絕查詢請求；此時，CTSDB可正常查詢。
(2) CTSDB單節點集群與雙節點集群查詢性能對比
橫坐標：並發數（查詢線程數） ，縱坐標：QPS（單位：次/s）
結論：在並發數較高的情況下，雙節點集群查詢性能較單節點集群有了大幅度提升，呈現了查詢性能線性擴展的趨勢。
關於我們 1. 我們的現狀
作為騰訊唯一的時序資料庫，CTSDB支撐了騰訊內部20多個核心業務（微信彩票、財付通、雲監控、雲資料庫、雲負載等）。其中，雲監控系統記錄了騰訊內部各種軟硬體系統的實時狀態，CTSDB承載了它所有的數據存儲，在每秒千萬級數據點的寫入壓力、每天20TB+數據量的寫入場景下穩定運行，足以證明CTSDB可以穩定支撐物聯網的海量數據場景。
2. 我們的未來
CTSDB已經在騰訊雲正式開始公測，為時序數據處理提供技術服務，我們將在降低存儲成本、提升易用性和豐富功能性等方面進一步優化CTSDB！
歡迎對時序資料庫和分布式存儲感興趣的同學加入我們！