摘要:對于上面表來說,假設現在它有兩行數據,分別是和,在里面,每一行數據會有不同的對應。對于來說,也是具有唯一性的,所以我們用來表示,而則是對應的。如果兩個相同,就會破壞唯一性約束。因為一定是唯一的,所以兩行數據即使一樣,也不會沖突。
上篇文章中,我們介紹了與 TiKV 處理讀寫請求相關的基礎知識,下面將開始詳細的介紹 TiKV 的讀寫流程。Enjoy~
作者:唐劉 @siddontang
RawKVTiKV 提供兩套 API,一套叫做 RawKV,另一套叫做 TxnKV。TxnKV 對應的就是上面提到的 Percolator,而 RawKV 則不會對事務做任何保證,而且比 TxnKV 簡單很多,這里我們先討論 RawKV。
Write當進行寫入,譬如 Write a = 1,會進行如下步驟:
Client 找 PD 問 a 所在的 Region
PD 告訴 Region 相關信息,主要是 Leader 所在的 TiKV
Client 將命令發送給 Leader 所在的 TiKV
Leader 接受請求之后執行 Raft 流程
Leader 將 a = 1 Apply 到 KV RocksDB 然后給 Client 返回寫入成功
Read對于 Read 來說,也是一樣的操作,唯一不同在于 Leader 可以直接提供 Read,不需要走 Raft。
TxnKV Write對于 TxnKV 來說,情況就要復雜的多,不過大部分流程已經在 Percolator 章節進行說明了。這里需要注意的是,因為我們要快速的 seek 到最新的 commit,所以在 RocksDB 里面,我們會先將 TS 使用 bigendian 生成 8 字節的 bytes,然后將這個 bytes 逐位取反,在跟原始的 key 組合存儲到 RocksDB 里面,這樣就能保證最新的提交存放到前面,seek 的時候就能直接定位了,當然 seek 的時候,也同樣會將對應的 TS 按照相同的方式編碼處理。
譬如,假設一個 key 現在有兩次提交,commitTS 分別為 10 和 12,startTS 則是 9 和 11,那么在 RocksDB 里面,key 的存放順序則是:
Write CF: a_12 -> 11 a_10 -> 9 Data CF: a_11 -> data_11 a_9 -> data_9
另外,還需要注意的是,對于 value 比較小的情況,TiKV 會直接將 value 存放到 Write CF 里面,這樣 Read 的時候只要走 Write CF 就行了。在寫入的時候,流程如下:
PreWrite: Lock CF: W a -> Lock + Data Commit: Lock CF: R a -> Lock + 10 + Data Lock CF: D a Write CF: W a_11 -> 10 + Data
對于 TiKV 來說,在 Commit 階段無論怎樣都會讀取 Lock 來判斷事務沖突,所以我們可以從 Lock 拿到數據,然后再寫入到 Write CF 里面。
ReadRead 的流程之前的 Percolator 已經有說明了,這里就不詳細解釋了。
SQL Key Mapping我們在 TiKV 上面構建了一個分布式數據庫 TiDB,它是一個關系型數據庫,所以大家需要關注的是一個關系型的 table 是如何映射到 key-value 上面的。假設我們有如下的表結構:
CREATE TABLE t1 { id BIGINT PRIMARY KEY, name VARCHAR(1024), age BIGINT, content BLOB, UNIQUE(name), INDEX(age), }
上面我們創建了一張表 t1,里面有四個字段,id 是主鍵,name 是唯一索引,age 是一個索引。那么這個表里面的數據是如何對應到 TiKV 的呢?
在 TiDB 里面,任何一張表都有一個唯一的 ID,譬如這里是 11,任何的索引也有唯一的 ID,上面 name 就是 12,age 就是 13。我們使用前綴 t 和 i 來區分表里面的 data 和 index。對于上面表 t1 來說,假設現在它有兩行數據,分別是 (1, “a”, 10, “hello”) 和 (2, “b”, 12, “world”),在 TiKV 里面,每一行數據會有不同的 key-value 對應。如下:
PK t_11_1 -> (1, “a”, 10, “hello”) t_11_2 -> (2, “b”, 12, “world”) Unique Name i_12_a -> 1 i_12_b -> 2 Index Age i_13_10_1 -> nil i_13_12_2 -> nil
因為 PK 具有唯一性,所以我們可以用 t + Table ID + PK 來唯一表示一行數據,value 就是這行數據。對于 Unique 來說,也是具有唯一性的,所以我們用 i + Index ID + name 來表示,而 value 則是對應的 PK。如果兩個 name 相同,就會破壞唯一性約束。當我們使用 Unique 來查詢的時候,會先找到對應的 PK,然后再通過 PK 找到對應的數據。
對于普通的 Index 來說,不需要唯一性約束,所以我們使用 i + Index ID + age + PK,而 value 為空。因為 PK 一定是唯一的,所以兩行數據即使 age 一樣,也不會沖突。當我們使用 Index 來查詢的時候,會先 seek 到第一個大于等于 i + Index ID + age 這個 key 的數據,然后看前綴是否匹配,如果匹配,則解碼出對應的 PK,再從 PK 拿到實際的數據。
TiDB 在操作 TiKV 的時候需要保證操作 keys 的一致性,所以需要使用 TxnKV 模式。
結語上面簡單的介紹了下 TiKV 讀寫數據的流程,還有很多東西并沒有覆蓋到,譬如錯誤處理,Percolator 的性能優化這些,如果你對這些感興趣,可以參與到 TiKV 的開發,歡迎聯系我 tl@pingcap.com。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/17793.html
摘要:作者唐劉本文會詳細的介紹是如何處理讀寫請求的,通過該文檔,同學們會知道是如何將一個寫請求包含的數據更改存儲到系統,并且能讀出對應的數據的。每個包含兩個實例,一個用于存儲,我們后面稱為,而另一個則是存放用戶實際的數據,我們稱為。 作者:唐劉 siddontang 本文會詳細的介紹 TiKV 是如何處理讀寫請求的,通過該文檔,同學們會知道 TiKV 是如何將一個寫請求包含的數據更改存儲到系...
閱讀 1106·2021-11-23 10:05
閱讀 1785·2021-11-12 10:36
閱讀 1853·2019-08-30 15:56
閱讀 1684·2019-08-29 12:32
閱讀 3043·2019-08-28 18:04
閱讀 3428·2019-08-26 12:17
閱讀 2502·2019-08-26 11:35
閱讀 1240·2019-08-23 15:11