做一個 Prototype 或者 Demo 很簡單，但做出一個真正好的時序數據庫（Time Series Database，TSDB）產品卻很難。

之(zhi)所以(yi)說做(zuo) Prototype 簡(jian)(jian)單，是(shi)因(yin)為 TSDB 天生就不(bu)(bu)擅長處理(li)一(yi)些(xie)數(shu)據(ju)(ju)(ju)，比如帶(dai)事務(wu)的(de)(de)(de)交易數(shu)據(ju)(ju)(ju)。基于此，我們(men)可以(yi)大刀(dao)闊(kuo)斧(fu)地砍掉一(yi)些(xie)在(zai)通用型數(shu)據(ju)(ju)(ju)庫中(zhong)很(hen)重要(yao)的(de)(de)(de)特(te)性，例如事務(wu)、MVCC、ACID（在(zai) Facebook 的(de)(de)(de) Gorilla 中(zhong)甚至提出不(bu)(bu)需要(yao)保證 Duration）。某(mou)些(xie) TSDB 的(de)(de)(de)存(cun)儲(chu)引(yin)擎(qing)，甚至不(bu)(bu)能處理(li)亂序(xu)(xu)數(shu)據(ju)(ju)(ju)，在(zai)無亂序(xu)(xu)的(de)(de)(de)前提下，存(cun)儲(chu)引(yin)擎(qing)幾乎可以(yi)退化為帶(dai) Index 的(de)(de)(de) Log。所以(yi)，從這個角度來看，Time Series Databse 可以(yi)做(zuo)得很(hen)簡(jian)(jian)單。

但是，從另一方面來說，做一個(ge)好的(de) TSDB 產品又很(hen)難。試想一下(xia)，在(zai)時序數(shu)據(ju)庫(ku)的(de)設計上，我們(men)大(da)刀闊(kuo)斧地砍掉了比如事務、ACID 等特性之(zhi)后(hou)，如果依然不能使(shi)其(qi)在(zai)時序場(chang)景(jing)下(xia)的(de)表(biao)現遠超通用型數(shu)據(ju)庫(ku)，那(nei)做一個(ge)專門的(de) TSDB 就毫(hao)無意義了。這樣的(de)話，還(huan)不如不做，就直接用通用型數(shu)據(ju)庫(ku)好了。

所謂“在時序場景下的遠超”，應該是全方位的，比如寫入的延遲與吞吐量、查詢性能、處理的實時性、甚至包括集群方案的運維成本等，都應該有一個跨越式的提升。另(ling)一方面，從時間序列數(shu)(shu)據量(liang)大、價值偏低等特點出發，壓縮(suo)率就顯得比較重要(yao)了(le)，而通用型(xing)數(shu)(shu)據庫卻很(hen)少強調壓縮(suo)率，由此可見，壓縮(suo)率是在時序場景下真實生長出來的(de)需(xu)求。

高壓(ya)縮率的(de)(de)實(shi)現沒(mei)有什么黑科技，也不需要自己重新發明(ming)壓(ya)縮算(suan)法——無(wu)非(fei)就是列存并對各(ge)個類型使用其最好的(de)(de)壓(ya)縮算(suan)法；更(geng)多是工程實(shi)現的(de)(de)問題——好好寫代(dai)碼，認(ren)真做優(you)化，平衡好寫入性能(neng)與壓(ya)縮比之間的(de)(de)關系。

此外，在時間序列數據場景下的“遠超”是建立在時序數據的寫入與查詢分布特點極其明顯的基礎上，當數據本身 key的特征分布十分明顯時，自然可以充分利用其特征來打造截然不同的存儲引擎與索引結構。

先說寫入。Time Series Database 的(de)(de)吞吐(tu)量(liang)(liang)遠超一(yi)般(ban)的(de)(de)通用型數(shu)(shu)據(ju)(ju)庫，尤其是 IoT 設(she)(she)備，其設(she)(she)備規模(mo)可能達到千萬(wan)甚至(zhi)上億，數(shu)(shu)據(ju)(ju)均為自動生成，假設(she)(she) 1s 采樣(yang)一(yi)次，那每秒就能產(chan)生千萬(wan)、億級別(bie)的(de)(de)數(shu)(shu)據(ju)(ju)寫入，這并不是普(pu)通數(shu)(shu)據(ju)(ju)庫能承受的(de)(de)，在這樣(yang)大的(de)(de)吞吐(tu)量(liang)(liang)的(de)(de)情(qing)況(kuang)下，數(shu)(shu)據(ju)(ju)如何(he)分(fen)區分(fen)片、如何(he)實時地構(gou)建索引，都是具(ju)有挑戰性的(de)(de)問題。在寫入鏈路上，TSDB 在時序場景下替代(dai)的(de)(de)是 OLTP 數(shu)(shu)據(ju)(ju)庫的(de)(de)位(wei)置(zhi)，而(er)后者在事務(wu)與強一(yi)致的(de)(de)模(mo)型下產(chan)生的(de)(de)讀寫延遲很難支撐(cheng)時序數(shu)(shu)據(ju)(ju)庫的(de)(de)高(gao)吞吐(tu)量(liang)(liang)寫入。

再(zai)說查(cha)(cha)詢(xun)。在(zai)大寫入吞吐量(liang)的(de)(de)情況下，數(shu)(shu)據對實(shi)時性的(de)(de)要求(qiu)也很高。例(li)如，我們將時序數(shu)(shu)據的(de)(de)統計量(liang)關(guan)聯做監控、報警，能(neng)容忍的(de)(de)延(yan)遲可能(neng)在(zai)秒級。查(cha)(cha)詢(xun)的(de)(de)模(mo)式通常(chang)是(shi)(shi)聚(ju)合查(cha)(cha)詢(xun)，例(li)如某時間段內(nei)的(de)(de)統計值(zhi)，而(er)不是(shi)(shi)精確的(de)(de)單條記錄。總的(de)(de)來說，TSDB 的(de)(de)查(cha)(cha)詢(xun)模(mo)式通常(chang)是(shi)(shi)交(jiao)互式分析，這不同于(yu) T+1 的(de)(de)離線(xian)數(shu)(shu)倉，也區(qu)別(bie)于(yu)經常(chang)運行數(shu)(shu)小時的(de)(de) OLAP 查(cha)(cha)詢(xun)，交(jiao)互式分析查(cha)(cha)詢(xun)的(de)(de)響應時間通常(chang)是(shi)(shi)秒級、亞秒級。

可(ke)見，實(shi)現時(shi)序數(shu)據庫（Time Series Database）在(zai)(zai)特定(ding)場景下(xia)“遠超”通用數(shu)據庫，還是存在(zai)(zai)非常多的(de)難點，在(zai)(zai)明確(que)了寫(xie)入(ru)與查詢需求(qiu)的(de)同時(shi)，接下(xia)來(lai)的(de)文章我們會以 TDengine 為例，來(lai)看一看一個Time Series Database 的(de)某一個部分應(ying)該如何設計。