做一個(gè) Prototype 或者 Demo 很簡(jiǎn)單，但做出一個(gè)真正好的時(shí)序數(shù)據(jù)庫(kù)（Time Series Database，TSDB）產(chǎn)品卻很難。

之所以說(shuō)做 Prototype 簡(jiǎn)單，是因?yàn)?TSDB 天生就不擅長(zhǎng)處理一些數(shù)據(jù)，比如帶事務(wù)的交易數(shù)據(jù)?；诖耍覀兛梢源蟮堕煾乜车粢恍┰谕ㄓ眯蛿?shù)據(jù)庫(kù)中很重要的特性，例如事務(wù)、MVCC、ACID（在 Facebook 的 Gorilla 中甚至提出不需要保證 Duration）。某些 TSDB 的存儲(chǔ)引擎，甚至不能處理亂序數(shù)據(jù)，在無(wú)亂序的前提下，存儲(chǔ)引擎幾乎可以退化為帶 Index 的 Log。所以，從這個(gè)角度來(lái)看，Time Series Databse 可以做得很簡(jiǎn)單。

但是，從另一方面來(lái)說(shuō)，做一個(gè)好的 TSDB 產(chǎn)品又很難。試想一下，在時(shí)序數(shù)據(jù)庫(kù)的設(shè)計(jì)上，我們大刀闊斧地砍掉了比如事務(wù)、ACID 等特性之后，如果依然不能使其在時(shí)序場(chǎng)景下的表現(xiàn)遠(yuǎn)超通用型數(shù)據(jù)庫(kù)，那做一個(gè)專門的 TSDB 就毫無(wú)意義了。這樣的話，還不如不做，就直接用通用型數(shù)據(jù)庫(kù)好了。

所謂“在時(shí)序場(chǎng)景下的遠(yuǎn)超”，應(yīng)該是全方位的，比如寫入的延遲與吞吐量、查詢性能、處理的實(shí)時(shí)性、甚至包括集群方案的運(yùn)維成本等，都應(yīng)該有一個(gè)跨越式的提升。另一方面，從時(shí)間序列數(shù)據(jù)量大、價(jià)值偏低等特點(diǎn)出發(fā)，壓縮率就顯得比較重要了，而通用型數(shù)據(jù)庫(kù)卻很少?gòu)?qiáng)調(diào)壓縮率，由此可見(jiàn)，壓縮率是在時(shí)序場(chǎng)景下真實(shí)生長(zhǎng)出來(lái)的需求。

高壓縮率的實(shí)現(xiàn)沒(méi)有什么黑科技，也不需要自己重新發(fā)明壓縮算法——無(wú)非就是列存并對(duì)各個(gè)類型使用其最好的壓縮算法；更多是工程實(shí)現(xiàn)的問(wèn)題——好好寫代碼，認(rèn)真做優(yōu)化，平衡好寫入性能與壓縮比之間的關(guān)系。

此外，在時(shí)間序列數(shù)據(jù)場(chǎng)景下的“遠(yuǎn)超”是建立在時(shí)序數(shù)據(jù)的寫入與查詢分布特點(diǎn)極其明顯的基礎(chǔ)上，當(dāng)數(shù)據(jù)本身 key的特征分布十分明顯時(shí)，自然可以充分利用其特征來(lái)打造截然不同的存儲(chǔ)引擎與索引結(jié)構(gòu)。

先說(shuō)寫入。Time Series Database 的吞吐量遠(yuǎn)超一般的通用型數(shù)據(jù)庫(kù)，尤其是 IoT 設(shè)備，其設(shè)備規(guī)模可能達(dá)到千萬(wàn)甚至上億，數(shù)據(jù)均為自動(dòng)生成，假設(shè) 1s 采樣一次，那每秒就能產(chǎn)生千萬(wàn)、億級(jí)別的數(shù)據(jù)寫入，這并不是普通數(shù)據(jù)庫(kù)能承受的，在這樣大的吞吐量的情況下，數(shù)據(jù)如何分區(qū)分片、如何實(shí)時(shí)地構(gòu)建索引，都是具有挑戰(zhàn)性的問(wèn)題。在寫入鏈路上，TSDB 在時(shí)序場(chǎng)景下替代的是 OLTP 數(shù)據(jù)庫(kù)的位置，而后者在事務(wù)與強(qiáng)一致的模型下產(chǎn)生的讀寫延遲很難支撐時(shí)序數(shù)據(jù)庫(kù)的高吞吐量寫入。

再說(shuō)查詢。在大寫入吞吐量的情況下，數(shù)據(jù)對(duì)實(shí)時(shí)性的要求也很高。例如，我們將時(shí)序數(shù)據(jù)的統(tǒng)計(jì)量關(guān)聯(lián)做監(jiān)控、報(bào)警，能容忍的延遲可能在秒級(jí)。查詢的模式通常是聚合查詢，例如某時(shí)間段內(nèi)的統(tǒng)計(jì)值，而不是精確的單條記錄。總的來(lái)說(shuō)，TSDB 的查詢模式通常是交互式分析，這不同于 T+1 的離線數(shù)倉(cāng)，也區(qū)別于經(jīng)常運(yùn)行數(shù)小時(shí)的 OLAP 查詢，交互式分析查詢的響應(yīng)時(shí)間通常是秒級(jí)、亞秒級(jí)。

可見(jiàn)，實(shí)現(xiàn)時(shí)序數(shù)據(jù)庫(kù)（Time Series Database）在特定場(chǎng)景下“遠(yuǎn)超”通用數(shù)據(jù)庫(kù)，還是存在非常多的難點(diǎn)，在明確了寫入與查詢需求的同時(shí)，接下來(lái)的文章我們會(huì)以 TDengine 為例，來(lái)看一看一個(gè)Time Series Database 的某一個(gè)部分應(yīng)該如何設(shè)計(jì)。