時間序列數(shù)據(jù)庫 (TSDB)

背景

2017年時序數(shù)據(jù)庫忽然火了起來挽鞠。開年2月Facebook開源了beringei時序數(shù)據(jù)庫对途；到了4月基于PostgreSQL打造的時序數(shù)據(jù)庫TimeScaleDB也開源了浪蹂，而早在2016年7月，百度云在其天工物聯(lián)網(wǎng)平臺上發(fā)布了國內(nèi)首個多租戶的分布式時序數(shù)據(jù)庫產(chǎn)品TSDB访锻，成為支持其發(fā)展制造忌傻，交通，能源疆虚，智慧城市等產(chǎn)業(yè)領(lǐng)域的核心產(chǎn)品苛败，同時也成為百度戰(zhàn)略發(fā)展產(chǎn)業(yè)物聯(lián)網(wǎng)的標志性事件。
例如：

時間序列數(shù)據(jù)庫 Time Series Database (TSDB)

隨著分布式系統(tǒng)監(jiān)控径簿、物聯(lián)網(wǎng)的發(fā)展罢屈，TSDB開始受到更多的關(guān)注。
維基百科上對于時間序列的定義是‘一系列數(shù)據(jù)點按照時間順序排列’

時間序列數(shù)據(jù)就是歷史烙印篇亭，具有不變性,缠捌、唯一性、時間排序性

時間序列數(shù)據(jù)跟關(guān)系型數(shù)據(jù)庫有太多不同译蒂，但是很多公司并不想放棄關(guān)系型數(shù)據(jù)庫曼月。 于是就產(chǎn)生了一些特殊的用法，比如用 MySQL 的 VividCortex, 用 Postgres 的 Timescale柔昼。 很多人覺得特殊的問題需要特殊的解決方法哑芹，于是很多時間序列數(shù)據(jù)庫從頭寫起，不依賴任何現(xiàn)有的數(shù)據(jù)庫, 比如 Graphite捕透，InfluxDB聪姿。

mysql 的引擎，除了常見的 innodb 和 myisam 乙嘀，還有一個引擎叫 archive 末购，它的作用和 rrd 差不多，支持插入和查詢操作虎谢。

  • 時序數(shù)據(jù)是基于時間的一系列的數(shù)據(jù)盟榴。在有時間的坐標中將這些數(shù)據(jù)點連成線，往過去看可以做成多緯度報表婴噩，揭示其趨勢性擎场、規(guī)律性、異常性讳推；往未來看可以做大數(shù)據(jù)分析顶籽，機器學習，實現(xiàn)預(yù)測和預(yù)警银觅。

  • 時序數(shù)據(jù)庫就是存放時序數(shù)據(jù)的數(shù)據(jù)庫礼饱，并且需要支持時序數(shù)據(jù)的快速寫入、持久化、多緯度的聚合查詢等基本功能镊绪。

數(shù)據(jù)寫入的特點

  • 寫入平穩(wěn)匀伏、持續(xù)、高并發(fā)高吞吐：時序數(shù)據(jù)的寫入是比較平穩(wěn)的蝴韭，這點與應(yīng)用數(shù)據(jù)不同够颠，應(yīng)用數(shù)據(jù)通常與應(yīng)用的訪問量成正比，而應(yīng)用的訪問量通常存在波峰波谷榄鉴。時序數(shù)據(jù)的產(chǎn)生通常是以一個固定的時間頻率產(chǎn)生履磨，不會受其他因素的制約，其數(shù)據(jù)生成的速度是相對比較平穩(wěn)的庆尘。
  • 寫多讀少：時序數(shù)據(jù)上95%-99%的操作都是寫操作剃诅，是典型的寫多讀少的數(shù)據(jù)。這與其數(shù)據(jù)特性相關(guān)驶忌，例如監(jiān)控數(shù)據(jù)矛辕，你的監(jiān)控項可能很多捕虽，但是你真正去讀的可能比較少台诗，通常只會關(guān)心幾個特定的關(guān)鍵指標或者在特定的場景下才會去讀數(shù)據(jù)。
  • 實時寫入最近生成的數(shù)據(jù)乡括，無更新：時序數(shù)據(jù)的寫入是實時的几苍，且每次寫入都是最近生成的數(shù)據(jù)翻屈，這與其數(shù)據(jù)生成的特點相關(guān)，因為其數(shù)據(jù)生成是隨著時間推進的擦剑，而新生成的數(shù)據(jù)會實時的進行寫入妖胀。數(shù)據(jù)寫入無更新，在時間這個維度上惠勒，隨著時間的推進，每次數(shù)據(jù)都是新數(shù)據(jù)爬坑，不會存在舊數(shù)據(jù)的更新纠屋，不過不排除人為的對數(shù)據(jù)做訂正。

數(shù)據(jù)查詢和分析的特點

  • 按時間范圍讀榷芗啤：通常來說售担，你不會去關(guān)心某個特定點的數(shù)據(jù)，而是一段時間的數(shù)據(jù)署辉。
  • 最近的數(shù)據(jù)被讀取的概率高
  • 歷史數(shù)據(jù)粗粒度查詢的概率搞
  • 多種精度查詢
  • 多維度分析

數(shù)據(jù)存儲的特點

  • 數(shù)據(jù)量大：拿監(jiān)控數(shù)據(jù)來舉例族铆，如果我們采集的監(jiān)控數(shù)據(jù)的時間間隔是1s，那一個監(jiān)控項每天會產(chǎn)生86400個數(shù)據(jù)點哭尝，若有10000個監(jiān)控項哥攘，則一天就會產(chǎn)生864000000個數(shù)據(jù)點。在物聯(lián)網(wǎng)場景下，這個數(shù)字會更大逝淹。整個數(shù)據(jù)的規(guī)模耕姊，是TB甚至是PB級的。
  • 冷熱分明：時序數(shù)據(jù)有非常典型的冷熱特征栅葡，越是歷史的數(shù)據(jù)茉兰，被查詢和分析的概率越低。
  • 具有時效性：時序數(shù)據(jù)具有時效性欣簇，數(shù)據(jù)通常會有一個保存周期规脸，超過這個保存周期的數(shù)據(jù)可以認為是失效的，可以被回收熊咽。一方面是因為越是歷史的數(shù)據(jù)莫鸭，可利用的價值越低；另一方面是為了節(jié)省存儲成本网棍，低價值的數(shù)據(jù)可以被清理黔龟。
  • 多精度數(shù)據(jù)存儲：在查詢的特點里提到時序數(shù)據(jù)出于存儲成本和查詢效率的考慮，會需要一個多精度的查詢滥玷，同樣也需要一個多精度數(shù)據(jù)的存儲氏身。

開源時間序列數(shù)據(jù)庫

RRDTool 是最早的時間序列數(shù)據(jù)庫，它自帶畫圖功能惑畴，現(xiàn)在大部分時間序列數(shù)據(jù)庫都使用Grafana來畫圖蛋欣。

Graphite 是用 Python 寫的 RRD 數(shù)據(jù)庫，它的存儲引擎 Whisper 也是 Python 寫的如贷， 它畫圖和聚合能力都強了很多陷虎，但是很難水平擴展。
OpenTSDB 使用 HBase 解決了水平擴展的問題
KairosDB 最初是基于OpenTSDB修改的杠袱，但是作者認為兼容HBase導致他們不能使用很多 Cassandra 獨有的特性尚猿， 于是就拋棄了HBase僅支持Cassandra。
新發(fā)布的 OpenTSDB 中也加入了對 Cassandra 的支持楣富。 故事還沒完凿掂，Spotify 的人本來想使用 KairosDB，但是覺得項目發(fā)展方向不對以及性能太差纹蝴，就自己擼了一個 Heroic庄萎。

InfluxDB 早期是完全開源的，后來為了維持公司運營塘安，閉源了集群版本糠涛。 在 Percona Live 上他們做了一個開源數(shù)據(jù)庫商業(yè)模型正面臨危機的演講，里面調(diào)侃紅帽的段子很不錯兼犯。 并且今年的 Percona Live 還有專門的時間序列數(shù)據(jù)庫單元忍捡。

數(shù)據(jù)模型

時間序列數(shù)據(jù)可以分成兩部分

  • 序列 ：就是標識符（維度）集漾，主要的目的是方便進行搜索和篩選
  • 數(shù)據(jù)點：時間戳和數(shù)值構(gòu)成的數(shù)組
    • 行存：一個數(shù)組包含多個點，如 [{t: 2017-09-03-21:24:44, v: 0.1002}, {t: 2017-09-03-21:24:45, v: 0.1012}]
    • 列存：兩個數(shù)組锉罐，一個存時間戳帆竹，一個存數(shù)值，如[ 2017-09-03-21:24:44, 2017-09-03-21:24:45], [0.1002, 0.1012]
      一般情況下：列存能有更好的壓縮率和查詢性能

基本概念

  • metric: 度量脓规，相當于關(guān)系型數(shù)據(jù)庫中的table栽连。
  • data point: 數(shù)據(jù)點，相當于關(guān)系型數(shù)據(jù)庫中的row侨舆。
  • timestamp：時間戳秒紧，代表數(shù)據(jù)點產(chǎn)生的時間。
  • field: 度量下的不同字段挨下。比如位置這個度量具有經(jīng)度和緯度兩個field熔恢。一般情況下存放的是會隨著時間戳的變化而變化的數(shù)據(jù)。
  • tag: 標簽臭笆，或者附加信息叙淌。一般存放的是并不隨著時間戳變化的屬性信息。timestamp加上所有的tags可以認為是table的primary key愁铺。

如下圖鹰霍，度量為Wind，每一個數(shù)據(jù)點都具有一個timestamp茵乱，兩個field：direction和speed茂洒，兩個tag：sensor、city瓶竭。它的第一行和第三行督勺，存放的都是sensor號碼為95D8-7913的設(shè)備，屬性城市是上海斤贰。隨著時間的變化智哀，風向和風速都發(fā)生了改變，風向從23.4變成23.2荧恍；而風速從3.4變成了3.3盏触。


應(yīng)用場景

所有有時序數(shù)據(jù)產(chǎn)生，并且需要展現(xiàn)其歷史趨勢块饺、周期規(guī)律、異常性的雌芽，進一步對未來做出預(yù)測分析的授艰，都是時序數(shù)據(jù)庫適合的場景。

例：
在工業(yè)物聯(lián)網(wǎng)環(huán)境監(jiān)控方向世落，百度天工的客戶就遇到了這么一個難題淮腾，由于工業(yè)上面的要求，需要將工況數(shù)據(jù)存儲起來」瘸客戶每個廠區(qū)具有20000個監(jiān)測點洲押，500毫秒一個采集周期，一共20個廠區(qū)圆凰。這樣算起來一年將產(chǎn)生驚人的26萬億個數(shù)據(jù)點杈帐。假設(shè)每個點50Byte，數(shù)據(jù)總量將達1P（如果每臺服務(wù)器10T的硬盤专钉，那么總共需要100多臺服務(wù)器）挑童。這些數(shù)據(jù)不只是要實時生成，寫入存儲跃须；還要支持快速查詢站叼，做可視化的展示，幫助管理者分析決策菇民；并且也能夠用來做大數(shù)據(jù)分析尽楔，發(fā)現(xiàn)深層次的問題，幫助企業(yè)節(jié)能減排第练，增加效益阔馋。最終客戶采用了百度天工的時序數(shù)據(jù)庫方案，幫助他解決了難題复旬。
（這個高逼格）

時序數(shù)據(jù)庫遇到的挑戰(zhàn)

很多人可能認為在傳統(tǒng)關(guān)系型數(shù)據(jù)庫上加上時間戳一列就能作為時序數(shù)據(jù)庫垦缅。數(shù)據(jù)量少的時候確實也沒問題，但少量數(shù)據(jù)是展現(xiàn)的緯度有限驹碍，細節(jié)少壁涎，可置信低，更加不能用來做大數(shù)據(jù)分析志秃。很明顯時序數(shù)據(jù)庫是為了解決海量數(shù)據(jù)場景而設(shè)計的怔球。

可以看到時序數(shù)據(jù)庫需要解決以下幾個問題

  • 時序數(shù)據(jù)的寫入：如何支持每秒鐘上千萬上億數(shù)據(jù)點的寫入。

  • 時序數(shù)據(jù)的讀雀』埂：又如何支持在秒級對上億數(shù)據(jù)的分組聚合運算竟坛。

  • 成本敏感：由海量數(shù)據(jù)存儲帶來的是成本問題。如何更低成本的存儲這些數(shù)據(jù)钧舌，將成為時序數(shù)據(jù)庫需要解決的重中之重担汤。

這些問題不是用一篇文章就能含蓋的，同時每個問題都可以從多個角度去優(yōu)化解決洼冻。在這里只從數(shù)據(jù)存儲這個角度來嘗試回答如何解決大數(shù)據(jù)量的寫入和讀取崭歧。

RRD

RRD （Round Robin Database）數(shù)據(jù)庫是一個環(huán)形的數(shù)據(jù)庫，數(shù)據(jù)庫由一個固定大小的數(shù)據(jù)文件來存放數(shù)據(jù)撞牢，此數(shù)據(jù)庫不會像傳統(tǒng)數(shù)據(jù)庫一樣為隨著數(shù)據(jù)的增多而文件的大小也在增加率碾，RRD在創(chuàng)建好后其文件大小就固定叔营，可以把它想像成一個圓，圓的眾多直徑把圓劃分成一個個扇形所宰，每個扇形就是可以存數(shù)據(jù)的槽位绒尊，每個槽位上被打上了一個時間戳，在圓心上有一個指針仔粥，隨著時間的流逝婴谱，取回數(shù)據(jù)后，指針會負責把數(shù)據(jù)填充在相應(yīng)的槽位上件炉，當指針轉(zhuǎn)了360度后勘究，最開始的數(shù)據(jù)就會被覆蓋，就這樣RRD循環(huán)填充著數(shù)據(jù)斟冕。


image.png
  • 源數(shù)據(jù)搜集：采用一些數(shù)據(jù)搜集工具口糕，如腳本、shell命令磕蛇、SNMP等工具在一定時間間隔里把數(shù)據(jù)搜集填充到rrd數(shù)據(jù)庫中景描，這些需要數(shù)據(jù)搜集的對象叫DS，一個DS里在一個時間里可以搜集的數(shù)據(jù)可以有多個秀撇，比如一個時間點上對網(wǎng)卡來說有進來的流量超棺，也有流出的流量，所以這是2個數(shù)據(jù)成為一組數(shù)據(jù)呵燕。
  • 臨時存儲：源數(shù)據(jù)獲取到后是存放在一個數(shù)據(jù)庫的一個臨時區(qū)域棠绘，這些源數(shù)據(jù)叫做PDP
  • 分組-聚合：RRDTool把這些PDP數(shù)據(jù)作為數(shù)據(jù)源通過分組、再利用聚合函數(shù)計算后把計算后的結(jié)果放在RRD數(shù)據(jù)庫的時間槽(time slot)上再扭，這些數(shù)據(jù)叫做CDP氧苍，CDP才是RRDTool繪圖時真正打交道的數(shù)據(jù)，
  • 在從源數(shù)據(jù)中取數(shù)據(jù)做聚合計算時會有一個挑選數(shù)據(jù)的基準泛范，也就是說是以幾個源數(shù)據(jù)為一組做聚合让虐，根據(jù)現(xiàn)實需求的不同，對源數(shù)據(jù)可以很靈活的選擇不同的時間段提取源數(shù)據(jù)罢荡，再聚合提取不同的聚合值赡突，這樣就產(chǎn)生不同組別的CDP數(shù)據(jù)，這些有以相同時間段挑選源數(shù)據(jù)及相同聚合函數(shù)計算的結(jié)果組成的數(shù)據(jù)就叫RRA区赵，所以根據(jù)挑選源數(shù)據(jù)的標準及采用的聚合函數(shù)的不同惭缰，RRA可以有多組。
  • DS：Data Source 數(shù)據(jù)源笼才，用于定義搜集數(shù)據(jù)的工具所搜集數(shù)據(jù)的一些特性
  • Time Solt：時間槽从媚，用于存放通過聚合后的數(shù)據(jù)區(qū)域
  • PDP：Primary Data Point 主數(shù)據(jù)節(jié)點，每個時間點產(chǎn)生的數(shù)據(jù)患整，即是搜集的源數(shù)據(jù)拜效，沒有做聚合的數(shù)據(jù)
  • CDP（Consolidation Data Point 聚合數(shù)據(jù)節(jié)點）：通過對獲取的源數(shù)據(jù)分組、聚合計算后得到的數(shù)據(jù)叫CDP各谚，
  • RRA（Round Robin Archive 輪轉(zhuǎn)歸檔）：以相同的分組紧憾、聚合函數(shù)計算后的CDP數(shù)據(jù)組就組成了RRA
  • Resolution（解析度）：這是一個時間跨度，表示在做聚合計算時是以幾個連續(xù)的time slot里的數(shù)據(jù)做聚合昌渤，在默認時rrd是以300秒的間隔產(chǎn)生一個time slot赴穗。
  • CF：Consolidation Function，合并函數(shù)或聚合函數(shù)膀息，以RRDTool中有AVERAGE般眉、MAX、MIN潜支、LAST4種

以一個圖來說明PDP甸赃、CDP、RRA之間的關(guān)系：



PDP是以規(guī)定的時間間隔（默認為300秒）搜集的源數(shù)據(jù)冗酿，第一個RRA以4個PDP（即4*300秒）為一組做CF后組成的數(shù)據(jù)埠对，第二個RRA則是以10個PDP為一組做CF后組成的數(shù)據(jù)。

InfluxDB

InfluxDB 在存儲引擎上糾結(jié)了很久裁替， leveldb, rocksdb, boltdb 都玩了個遍项玛，最后決定自己造個輪子叫 Time Structured Merge Tree。

Time Structured Merge Tree (TSM) 和 Log Structured Merge Tree (LSM) 的名字都有點誤導性弱判，關(guān)鍵并不是樹襟沮，也不是日志或者時間，而是 Merge昌腰。

  • 寫入的時候开伏，數(shù)據(jù)先寫入到內(nèi)存里，之后批量寫入到硬盤剥哑。
  • 讀的時候硅则，同時讀內(nèi)存和硬盤然后合并結(jié)果。
  • 刪除的時候株婴，寫入一個刪除標記怎虫，被標記的數(shù)據(jù)在讀取時不會被返回。
  • 后臺會把小的塊合并成大的塊困介，此時被標記刪除的數(shù)據(jù)才真正被刪除
  • 相對于普通數(shù)據(jù)大审，有規(guī)律的時間序列數(shù)據(jù)在合并的過程中可以極大的提高壓縮比。

熱點話題

存儲

單機存儲

如果只是存儲起來座哩，直接寫成日志就行徒扶。但因為后續(xù)還要快速的查詢，所以需要考慮存儲的結(jié)構(gòu)根穷。
傳統(tǒng)數(shù)據(jù)庫存儲采用的都是B tree姜骡，這是由于其在查詢和順序插入時有利于減少尋道次數(shù)的組織形式导坟。我們知道磁盤尋道時間是非常慢的，一般在10ms左右圈澈。磁盤的隨機讀寫慢就慢在尋道上面惫周。對于隨機寫入B tree會消耗大量的時間在磁盤尋道上，導致速度很慢康栈。我們知道SSD具有更快的尋道時間递递，但并沒有從根本上解決這個問題。
對于90%以上場景都是寫入的時序數(shù)據(jù)庫啥么，B tree很明顯是不合適的登舞。
業(yè)界主流都是采用LSM tree替換B tree，比如Hbase, Cassandra等nosql中悬荣。這里我們詳細介紹一下菠秒。

LSM tree

LSM tree 包括內(nèi)存里的數(shù)據(jù)結(jié)構(gòu)和磁盤上的文件兩部分，分別對應(yīng)Hbase里的MemStore和HLog隅熙；對應(yīng)Cassandra里的MemTable和sstable
LSM tree操作流程如下：

  1. 數(shù)據(jù)寫入和更新時首先寫入位于內(nèi)存里的數(shù)據(jù)結(jié)構(gòu)稽煤。為了避免數(shù)據(jù)丟失也會先寫到WAL文件中。

  2. 內(nèi)存里的數(shù)據(jù)結(jié)構(gòu)會定時或者達到固定大小會刷到磁盤囚戚。這些磁盤上的文件不會被修改酵熙。

  3. 隨著磁盤上積累的文件越來越多，會定時的進行合并操作驰坊，消除冗余數(shù)據(jù)匾二，減少文件數(shù)量。

分布式存儲

分布式存儲首先要考慮的是如何將數(shù)據(jù)分布到多臺機器上面拳芙，也就是 分片（sharding）問題

時序數(shù)據(jù)庫的分片方法和其他分布式系統(tǒng)是相通的察藐。

  • 哈希分片：這種方法實現(xiàn)簡單，均衡性較好舟扎，但是集群不易擴展分飞。

  • 一致性哈希：這種方案均衡性好，集群擴展容易睹限，只是實現(xiàn)復(fù)雜譬猫。代表有Amazon的DynamoDB和開源的Cassandra。

  • 范圍劃分：通常配合全局有序羡疗，復(fù)雜度在于合并和分裂染服。代表有Hbase。

  • 結(jié)合時序數(shù)據(jù)庫的特點叨恨，根據(jù)metric+tags分片是比較好的一種方式柳刮，因為往往會按照一個時間范圍查詢，這樣相同metric和tags的數(shù)據(jù)會分配到一臺機器上連續(xù)存放，順序的磁盤讀取是很快的秉颗。

  • 考慮時序數(shù)據(jù)時間范圍很長的情況痢毒，需要根據(jù)時間范圍再分成幾段，分別存儲到不同的機器上站宗，這樣對于大范圍時序數(shù)據(jù)就可以支持并發(fā)查詢闸准，優(yōu)化查詢速度。

如下圖梢灭，第一行和第三行都是同樣的tag（sensor=95D8-7913;city=上海），所以分配到同樣的分片蒸其，而第五行雖然也是同樣的tag敏释，但是根據(jù)時間范圍再分段，被分到了不同的分片摸袁。


InfluxDB的單機存儲

在單機上InfluxDB采取類似于LSM tree的存儲結(jié)構(gòu)TSM钥顽；而分片的方案InfluxDB先通過<database>+<timestamp>（事實上還要加上retentionPolicy）確定ShardGroup，再通過<metric>+<tags>的hash code確定到具體的Shard靠汁。

低延遲

時間序列數(shù)據(jù)庫主要是用來分析的蜂大，所以提高響應(yīng)速度對于診斷生產(chǎn)環(huán)境的問題是十分重要的。

把所有數(shù)據(jù)都放在內(nèi)存

Facebook 寫了叫 Gorilla 的純內(nèi)存時間序列數(shù)據(jù)庫發(fā)表在 VLDB 上蝶怔，現(xiàn)在已經(jīng)開源奶浦，改名為 Beringei（都是猩猩…）

提前聚合

因為查詢中經(jīng)常需要對一個很長的時間區(qū)間取一些粗粒度的值，比如6月到8月每天的平均CPU使用率踢星。 這些聚合值（均值澳叉，最大，最小) 都可以在存儲數(shù)據(jù)的時候計算出來沐悦。BtrDB 和 Akumuli 都在內(nèi)部節(jié)點中存儲聚合值成洗，這樣在很多查詢中底層的節(jié)點不需要被訪問就可以得到結(jié)果。

處理舊數(shù)據(jù)

  • 很多時間序列數(shù)據(jù)都沒有多大用處藏否，特別是當系統(tǒng)長時間正常運行時瓶殃，完整的歷史數(shù)據(jù)意義并不大。
  • 所以有些數(shù)據(jù)庫比如 RDDTool 和 Graphite 會自動刪除高精度的數(shù)據(jù)副签，只保留低精度的遥椿。
  • 但是對于很多新的時間序列數(shù)據(jù)庫，在聚合和刪除大量舊數(shù)據(jù)的同時保證系統(tǒng)正常運行并不像刪除一個本地文件那樣簡單继薛。
  • 如果監(jiān)控系統(tǒng)比被監(jiān)控系統(tǒng)還不穩(wěn)定就比較尷尬了修壕。

元數(shù)據(jù)索引

  • 時間序列的標識符是時間序列數(shù)據(jù)庫里主要的元數(shù)據(jù)。
  • Heroic 使用 Elasticsearch 來存儲元數(shù)據(jù)遏考， 查詢首先通過 Elasticsearch 來取得符合要求的序列標識符慈鸠，之后從 Cassandra 根據(jù)標識符來讀取對應(yīng)的數(shù)據(jù)。
  • 但是維護一個完整的搜索引擎帶來的運維壓力和增加的通信時間都是不能忽視的。
  • 因此 InfluxDB 和 Prometheus 就自己寫了倒排索引來索引元數(shù)據(jù)青团。

Tracing

  • InfluxDB 的人寫了一篇博客 Metrics are dead譬巫， 起因是在一個關(guān)于監(jiān)控的會議 Monitorama 上有人說單純的監(jiān)控數(shù)據(jù)已經(jīng)不能滿足他們復(fù)雜的微服務(wù)架構(gòu)了。
  • 于是 InfluxDB 的人反駁說并不是所有人都在使用大規(guī)模的分布式系統(tǒng)督笆，對于很多簡單的應(yīng)用單純的監(jiān)控數(shù)據(jù)已經(jīng)完全夠用了芦昔。
  • 我的看法是時間序列數(shù)據(jù)庫是可以用來存 Trace 的。
  • Trace 是更加復(fù)雜的時間序列數(shù)據(jù)娃肿，把單純的數(shù)值變成一個包含更多信息的對象咕缎，它就是一個 Trace。
  • 并且很多流行的 Tracer 的存儲也是使用 Cassandra, 比如 Zipkin料扰， Uber 的 Jaeger凭豪。
  • InfluxDB 現(xiàn)在已經(jīng)支持存儲 Trace 了

Ref：
https://zhuanlan.zhihu.com/p/29367404
https://github.com/xephonhq/awesome-time-series-database
https://blog.csdn.net/qq_33326449/article/details/79568014
https://zhuanlan.zhihu.com/p/32709932

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末，一起剝皮案震驚了整個濱河市晒杈，隨后出現(xiàn)的幾起案子嫂伞，更是在濱河造成了極大的恐慌，老刑警劉巖拯钻，帶你破解...
    沈念sama閱讀 207,248評論 6贊 481
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件帖努，死亡現(xiàn)場離奇詭異，居然都是意外死亡粪般，警方通過查閱死者的電腦和手機拼余，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,681評論 2贊 381
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來刊驴，“玉大人姿搜，你說我怎么就攤上這事±υ鳎” “怎么了舅柜？”我有些...
    開封第一講書人閱讀 153,443評論 0贊 344
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵，是天一觀的道長躲惰。 經(jīng)常有香客問我致份，道長，這世上最難降的妖魔是什么础拨？ 我笑而不...
    開封第一講書人閱讀 55,475評論 1贊 279
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任氮块，我火速辦了婚禮，結(jié)果婚禮上诡宗，老公的妹妹穿的比我還像新娘滔蝉。我一直安慰自己，他們只是感情好塔沃，可當我...
    茶點故事閱讀 64,458評論 5贊 374
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布蝠引。 她就那樣靜靜地躺著，像睡著了一般。 火紅的嫁衣襯著肌膚如雪螃概。 梳的紋絲不亂的頭發(fā)上矫夯，一...
    開封第一講書人閱讀 49,185評論 1贊 284
  • 城市分裂傳說
    那天，我揣著相機與錄音吊洼，去河邊找鬼训貌。 笑死，一個胖子當著我的面吹牛冒窍，可吹牛的內(nèi)容都是我干的递沪。 我是一名探鬼主播，決...
    沈念sama閱讀 38,451評論 3贊 401
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼礁凡！你這毒婦竟也來了？” 一聲冷哼從身側(cè)響起，我...
    開封第一講書人閱讀 37,112評論 0贊 261
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤票渠，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后妥凳，有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體贝攒，經(jīng)...
    沈念sama閱讀 43,609評論 1贊 300
  • ?護林員之死
    正文 獨居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,083評論 2贊 325
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年圣猎，在試婚紗的時候發(fā)現(xiàn)自己被綠了士葫。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 38,163評論 1贊 334
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡送悔，死狀恐怖慢显，靈堂內(nèi)的尸體忽然破棺而出，到底是詐尸還是另有隱情欠啤，我是刑警寧澤荚藻，帶...
    沈念sama閱讀 33,803評論 4贊 323
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布，位于F島的核電站洁段，受9級特大地震影響应狱，放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜祠丝，卻給世界環(huán)境...
    茶點故事閱讀 39,357評論 3贊 307
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一疾呻、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧写半，春花似錦岸蜗、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,357評論 0贊 19
  • 一樁弒父案璃岳，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至，卻和暖如春矾睦，著一層夾襖步出監(jiān)牢的瞬間晦款，已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 31,590評論 1贊 261
  • 情欲美人皮
    我被黑心中介騙來泰國打工枚冗， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留缓溅，地道東北人。 一個月前我還...
    沈念sama閱讀 45,636評論 2贊 355
  • 代替公主和親
    正文 我出身青樓赁温，卻偏偏與公主長得像坛怪，于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子股囊，可洞房花燭夜當晚...
    茶點故事閱讀 42,925評論 2贊 344

推薦閱讀更多精彩內(nèi)容

  • 什么是時間序列數(shù)據(jù) 什么是時間序列（Time Series袜匿，以下簡稱時序）數(shù)據(jù)？從定義上來說稚疹，就是一串按時間維度索...
    菜鳥小玄閱讀 1,564評論 0贊 3
  • 【編者按】劉斌居灯，OneAPM后端研發(fā)工程師，擁有10多年編程經(jīng)驗内狗，參與過大型金融怪嫌、通信以及Android手機操作系...
    OneAPM閱讀 903評論 0贊 5
  • 關(guān)于Mongodb的全面總結(jié) MongoDB的內(nèi)部構(gòu)造《MongoDB The Definitive Guide》...
    中v中閱讀 31,898評論 2贊 89
  • 想松活趕緊丟手， 要苦干下倒腰身柳沙。 高級能量葡萄糖岩灭， 低碳工具電動車。
    坦人閱讀 844評論 14贊 38
  • 上冬了赂鲤，又到一年“窩”酸菜的時候噪径。查了詞典，只有淹菜数初，沒有“窩”菜之說找爱。不知什么原因，我們的先輩們妙真，把它叫“...
    郭澄閱讀 839評論 2贊 2