TiDB是目前當(dāng)紅的NewSQL數(shù)據(jù)庫，在提供高性能讀寫的同時(shí)又兼容傳統(tǒng)的RDBMS，其底層的存儲(chǔ)是TiKV。這里我們看一下如果用TiKV存儲(chǔ)時(shí)序數(shù)據(jù)，其底層數(shù)據(jù)組織形式是怎么樣的，與InfluxDB的數(shù)據(jù)存儲(chǔ)模式相比有何優(yōu)缺點(diǎn)。

創(chuàng)新互聯(lián)是專業(yè)的羅田網(wǎng)站建設(shè)公司，羅田接單;提供成都網(wǎng)站制作、做網(wǎng)站,網(wǎng)頁設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行羅田網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來合作!

時(shí)序數(shù)據(jù)庫與傳統(tǒng)數(shù)據(jù)庫對(duì)比 首先從上層應(yīng)用的角度對(duì)比一下時(shí)序數(shù)據(jù)庫與通用型數(shù)據(jù)庫所面對(duì)的需求。關(guān)于時(shí)序數(shù)據(jù)的細(xì)節(jié)，數(shù)據(jù)模型，以及InfluxDB的實(shí)現(xiàn)，可以參考本人前面有一篇文章：

1. 寫入/讀取操作比例：對(duì)于通用的場(chǎng)景，這個(gè)比例是比較低的，就算是在高并發(fā)的互聯(lián)網(wǎng)應(yīng)用中，平均比例可能不會(huì)超過3:7。但是對(duì)于時(shí)序數(shù)據(jù)來說，這個(gè)比例很可能會(huì)超過5:5。而且時(shí)序數(shù)據(jù)一旦丟失，就找不回來了，因?yàn)闀r(shí)序數(shù)據(jù)都是一次性生成的。所以時(shí)序數(shù)據(jù)庫對(duì)寫入性能的要求更高。

2. 數(shù)據(jù)刪除：時(shí)序數(shù)據(jù)會(huì)面臨著大量時(shí)間久遠(yuǎn)、價(jià)值低的數(shù)據(jù)需要清除，需要?jiǎng)h除的數(shù)據(jù)量大致等于新生成的數(shù)據(jù)量。傳統(tǒng)數(shù)據(jù)庫是不會(huì)大規(guī)模刪除數(shù)據(jù)的。

3. 數(shù)據(jù)更新：TiDB中存在大量的數(shù)據(jù)更新，比如商品的庫存數(shù)據(jù)、賬戶余額數(shù)據(jù)等。但是時(shí)序數(shù)據(jù)都是一次性生成的，不需要更新。而且時(shí)序中單點(diǎn)數(shù)據(jù)是沒有意義的，就算錯(cuò)誤也沒必要修正。對(duì)于這個(gè)特征，如果將數(shù)據(jù)根據(jù)時(shí)間進(jìn)行range sharding，就會(huì)導(dǎo)致冷熱數(shù)據(jù)相對(duì)分離，方便于數(shù)據(jù)管理。但是也造成在數(shù)據(jù)寫入時(shí)會(huì)形成熱點(diǎn)，容易造成單點(diǎn)壓力。

4. 數(shù)據(jù)模型：就目前面對(duì)的場(chǎng)景來說，時(shí)序數(shù)據(jù)的模型是相對(duì)固定的，主要包含timestamp，tags和fields三個(gè)部分，而且序列值可以通過timestamp進(jìn)行組織。相對(duì)于RDBMS，這帶來一個(gè)優(yōu)勢(shì)就是對(duì)事務(wù)的支持需求更小。這里需要事務(wù)支持只有一點(diǎn)：數(shù)據(jù)寫入和刪除時(shí)同一timestamp對(duì)應(yīng)的各個(gè)field要一致。

5. 數(shù)據(jù)運(yùn)算：時(shí)序數(shù)據(jù)的應(yīng)用更偏向于在時(shí)間軸上進(jìn)行聚合，或者統(tǒng)計(jì)，很少對(duì)原始數(shù)據(jù)直接取出來使用。從這一個(gè)角度來說，時(shí)序數(shù)據(jù)庫的需求有點(diǎn)偏向OLAP。關(guān)于TSDB和OLAP的對(duì)比，也有博文進(jìn)行了詳述[Time series databases vs OLAP](https://medium.com/@itz100ji/time-series-databases-vs-olap-57e8d70309c8)。 所以，時(shí)序數(shù)據(jù)庫需要提供高吞吐量、高可用性，但是對(duì)事務(wù)支持的需求較小。所以是不是可以說時(shí)序數(shù)據(jù)庫是OLTP和OLAP各自的部分結(jié)合，也算是HTAP？

用TiKV存儲(chǔ)時(shí)序數(shù)據(jù) 如果直接用TiKV存儲(chǔ)時(shí)序數(shù)據(jù)，底層存儲(chǔ)結(jié)構(gòu)是什么樣呢？這里我們只討論數(shù)據(jù)在單個(gè)TiKV節(jié)點(diǎn)的組織形式，暫時(shí)先不管分布式架構(gòu)。 TiKV底層使用的是RocksDB來存儲(chǔ)數(shù)據(jù)，RocksDB是基于LSM Tree，是一個(gè)Key-Value存儲(chǔ)引擎。TiKV的數(shù)據(jù)存儲(chǔ)原理細(xì)節(jié)建議參考以下博文，里面做了很詳細(xì)的描述，包括底層的組件，以及如何從傳統(tǒng)的RDBMS的數(shù)據(jù)存儲(chǔ)映射到TiKV：

1. [TiKV 是如何存取數(shù)據(jù)的（上）]

2. [TiKV 是如何存儲(chǔ)數(shù)據(jù)的（下）] 所以，這里需要確定的就是怎么設(shè)計(jì)RocksDB中數(shù)據(jù)條目的key和value。如前文所說，對(duì)于時(shí)序數(shù)據(jù)，需要存儲(chǔ)的內(nèi)容包括timestamp，tags和fields，還需要在tags上做索引，提高通過tags的檢索的效率。首先是存儲(chǔ)每一個(gè)point的數(shù)據(jù)，每一個(gè)point可以通過measurement，所涉及的所有tags，和timestamp來定位，這三個(gè)信息的組合等價(jià)于MySQL中的primary key，可以唯一確定一個(gè)point。存儲(chǔ)的value就是point的fields。如果我們寫入的數(shù)據(jù)是： ``` Labs,location=SH,host=server1 CUP=73,Mem=16.067 1574179200s Labs,location=SH,host=server2 CUP=31,Mem=32.087 1574179200s Labs,location=SZ,host=server1 CUP=11,Mem=8.021 1574179200s Labs,location=SZ,host=server2 CUP=43,Mem=16.779 1574179200s ``` 在RocksDB里存儲(chǔ)的數(shù)據(jù)條目就是： ``` # Primary Key, 前綴t表示table, 數(shù)據(jù)條目 t_Labs_location=SH,host=server1_1574179200s ==> (73, 16.067) t_Labs_location=SH,host=server2_1574179200s ==> (31, 32.087) t_Labs_location=SZ,host=server1_1574179200s ==> (11, 8.021) t_Labs_location=SZ,host=server2_1574179200s ==> (43, 16.779) ``` 通過primary key定位數(shù)據(jù)非常簡(jiǎn)單，直接在RocksDB做查詢。 接著，還需要存儲(chǔ)基于tags的索引。TiKV中索引的組織結(jié)構(gòu)跟InfluxDB的原理是一樣的，也是反向索引。也就是說，給定一組`tag name`和`tag value`對(duì)，記錄哪些point與它相關(guān)。所以，索引的key既要包含涉及到的tag，還要包含對(duì)應(yīng)的point的primary key。而索引條目的value是無關(guān)緊要的，只需要判斷key是否存在。 ``` # Tags Index, 前綴i表示index, 索引條目 i_location=SH___t_Labs_location=SH,host=server1_1574179200s ==> nil i_host=server1___t_Labs_location=SH,host=server1_1574179200s ==> nil i_location=SH___t_Labs_location=SH,host=server2_1574179200s ==> nil i_host=server2___t_Labs_location=SH,host=server2_1574179200s ==> nil i_location=SZ___t_Labs_location=SZ,host=server1_1574179200s ==> nil i_host=server1___t_Labs_location=SZ,host=server1_1574179200s ==> nil i_location=SZ___t_Labs_location=SZ,host=server2_1574179200s ==> nil i_host=server2___t_Labs_location=SZ,host=server2_1574179200s ==> nil ``` 當(dāng)我們需要通過索引查找時(shí)，比如`location=SH`，首先構(gòu)建key前綴`i_location_SH___`，找到以這個(gè)前綴開頭的數(shù)據(jù)，這個(gè)過程在TiKV里面是很高效的，因?yàn)樗褂昧嘶趉ey的range sharding。這些查找出來的索引條目的key的后半部分，就是跟給定tag相關(guān)的所有數(shù)據(jù)條目primary key，然后通過這些primary key來檢索對(duì)應(yīng)的數(shù)據(jù)條目。

可以看到TiKV的索引和數(shù)據(jù)混合在一起進(jìn)行存儲(chǔ)，但它們的key-value條目是分開的，所以當(dāng)把MySQL的innodb表轉(zhuǎn)到TiKV后面應(yīng)該會(huì)占用更大的空間。

與InfluxDB存儲(chǔ)的對(duì)比

1. 索引的構(gòu)建，InfluxDB是使用一個(gè)超大的map實(shí)現(xiàn)的，這一點(diǎn)我覺得TiKV的構(gòu)建方式更加直觀簡(jiǎn)單，也充分利用了kay-value存儲(chǔ)引擎的優(yōu)勢(shì)，特別是適合巨量的tags。

2. 時(shí)序數(shù)據(jù)常規(guī)操作的性能： - 寫入：二者差不多。首先會(huì)寫入數(shù)據(jù)條目，然后會(huì)對(duì)每一個(gè)涉及的tag創(chuàng)建一個(gè)索引條目。 - 讀?。簳r(shí)序數(shù)據(jù)最多的是基于tag和timestamp區(qū)間進(jìn)行檢索。在TiDB里面，第一步需要返回所有的primary key，第二步取出每一個(gè)primary key的數(shù)據(jù)條目。InfluxDB的組織方式是基于entry進(jìn)行存儲(chǔ)，第一步是找到相關(guān)的series，這一步返回?cái)?shù)據(jù)量更少，第二步根據(jù)series找出給定timestamp范圍內(nèi)的數(shù)據(jù)條目，只需要基于少量series輪詢?cè)跀?shù)據(jù)庫中檢索。 - 清除：使用TiKV，數(shù)據(jù)的過期刪除策略效率很差，需要遍歷所有數(shù)據(jù)和索引條目，判斷所對(duì)應(yīng)的timestamp是否到期。頻繁刪除會(huì)影響到數(shù)據(jù)寫入性能。InfluxDB基于timestamp進(jìn)行sharding，舊的數(shù)據(jù)會(huì)存儲(chǔ)在相近的shard里面，很簡(jiǎn)單就可以刪除。

3. 存儲(chǔ)空間壓縮效率，InfluxDB的同field的內(nèi)容會(huì)按列存儲(chǔ)，同一數(shù)據(jù)類型，有利于壓縮。

4. 分布式解決方案。因?yàn)镮nfluxDB Cluster是閉源的，而TiDB又開源支持，所以TiDB勝。 根據(jù)上面的對(duì)比，對(duì)于時(shí)序數(shù)據(jù)的存儲(chǔ)，InfluxDB更專業(yè)。但是如果需要其分布式解決方案，要么得買，要么得自己實(shí)現(xiàn)解決。

本文標(biāo)題：用TiKV存儲(chǔ)時(shí)序數(shù)據(jù)與InfluxDB對(duì)比
分享網(wǎng)址：http://www.rwnh.cn/article22/sojdcc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站制作、網(wǎng)站導(dǎo)航、網(wǎng)站制作、域名注冊(cè)、定制開發(fā)、Google

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)