這個系列共三篇譯文： TiDB 官方設(shè)計文檔翻譯（一） TiDB 官方設(shè)計文檔翻譯（二） TiDB 官方設(shè)計文檔翻譯（三）
原文： https://pingcap.github.io/blog/2016/10/17/how-we-build-tidb/
讓我們繼續(xù)討論TiDB。TiDB有一個與MySQL兼容的協(xié)議層，有以下功能：
將表數(shù)據(jù)映射到鍵值存儲，從而連接到鍵值存儲引擎。謂詞下推（譯者注：將外層查詢塊的 WHERE 子句中的謂詞移入所包含的較低層查詢塊，不理解的可以搜索一下這個名詞)，以加速查詢在線DDL讓我們使用一個例子來展示SQL表如何映射到鍵值對。
如果我們在數(shù)據(jù)庫中有一個簡單的用戶表。 它有2行3列：用戶ID，名稱和電子郵件，其中用戶id是主鍵。
INSERT INTO user VALUES (1, "bob", "huang@pingcap.com");INSERT INTO user VALUES (2, "tom", "tom@pingcap.com");如果我們將此表映射到鍵值對，則應(yīng)按以下方式進(jìn)行。
當(dāng)然，TiDB支持二級索引。 它是一個全局索引。 TiDB將數(shù)據(jù)和索引更新放在同一個事務(wù)中，因此TiDB中的所有索引都是事務(wù)性的和完全一致的。 整個過程對用戶是透明的。
索引只是值指向行鍵的鍵值對。 在為用戶名創(chuàng)建索引之后，鍵值存儲如下所示：
索引的鍵由兩部分組成：人名加后綴用戶ID。比如這里“bob”是人名，1是用戶id，值指向行鍵。
對于一些操作，如計算表中的一些列，TiDB將這些操作下推到相應(yīng)的TiKV節(jié)點(diǎn)，由TiKV節(jié)點(diǎn)進(jìn)行計算，然后TiDB合并最終結(jié)果。 下圖展示了謂詞下推的過程。
這部分關(guān)于Schema更改（譯者注：Schema是數(shù)據(jù)庫對象的集合，一個用戶一般對應(yīng)一個schema）。 為什么在線Schema更改是必備功能？ 這是因為我們需要一直有完整的數(shù)據(jù)可用性，以及最小的性能影響，使運(yùn)維人員睡得安穩(wěn)。 與Google F1相同的部分 影響Schema更改的TiDB的主要功能有：
分布式——TiDB的實(shí)例由許多單獨(dú)的TiDB服務(wù)器組成關(guān)系Schema——每個TiDB服務(wù)器都有一個描述表，列，索引和約束的關(guān)系Schema的副本。對Schema的任何修改都應(yīng)該是分布式的，以更新所有服務(wù)器。共享數(shù)據(jù)存儲——所有數(shù)據(jù)中心中的所有TiDB服務(wù)器都可以訪問存儲在TiKV中的所有數(shù)據(jù)。在TiDB服務(wù)器之間沒有數(shù)據(jù)分區(qū)。沒有全局會員——因為TiDB服務(wù)器是無狀態(tài)的，所以不需要TiDB實(shí)現(xiàn)全局成員協(xié)議。這意味著沒有可靠的機(jī)制來確定當(dāng)前運(yùn)行的TiDB服務(wù)器，并且顯式全局同步是不可能的。 與Google F1不同的部分TiDB使用MySQL協(xié)議單個事務(wù)中的語句不能跨越不同的TiDB服務(wù)器 關(guān)于Schema更改的補(bǔ)充說明 Schema更改之前，讓我們看看下圖展示的TiDB中的SQL
下面是Schema更改期間TiDB實(shí)例的概述：
Schema更改: 增加索引 接下來，讓我們看看在添加索引時Schema是如何變化的。如果我們不小心，使用不同Schema版本的服務(wù)器可能會損壞數(shù)據(jù)庫。
考慮從Schema S1到Schema S2的變更，其將索引 I 添加到表T上。假設(shè)兩個不同的服務(wù)器M1和M2執(zhí)行下列操作：
服務(wù)器M2使用Schema S2向表T插入新行r。由于S2包含索引 I ，所以服務(wù)器M2還向鍵值存儲添加對應(yīng) r 的新索引條目。服務(wù)器M1使用Schema S1刪除r。 因為S1不包含 I，M1從鍵值存儲中刪除r，但無法刪除 I 中的相應(yīng)索引條目。第二次刪除會破壞數(shù)據(jù)庫。 例如，僅針對索引的掃描將返回不正確的結(jié)果，包括已刪除行r的列值。 Schema 狀態(tài) 通常情況下，Schema 更改是一個多狀態(tài)多階段協(xié)議。 有兩種狀態(tài)，我們認(rèn)為是非中間的：absent和public。有兩個內(nèi)部、中間狀態(tài)：delete-only和write-only
delete-only：一個僅刪除的表、列或索引不能由用戶事務(wù)讀取其鍵值對，并且
如果E是表或列，則只能通過刪除操作進(jìn)行修改。如果E是一個索引，它只被刪除和更新操作修改。 此外，更新操作可以刪除與更新的索引鍵相對應(yīng)的鍵值對，但是它們不能創(chuàng)建任何新的鍵值對。對于write-only狀態(tài)，它這樣定義列和索引： write-only列或索引可以通過插入，刪除和更新操作修改其鍵/值對，但不能通過用戶事務(wù)讀取它們的鍵值對。 Schema 更改流程：添加索引 添加索引需要4個步驟。
步驟1，我們將狀態(tài)標(biāo)記為delete-only，等待一個Schema 租用，在所有TiDB服務(wù)器達(dá)到相同狀態(tài)后，到第二步
步驟2，將狀態(tài)標(biāo)記為write-only，等待一個Schema 租用，
步驟3，將狀態(tài)標(biāo)記為填充索引，并開始maPReduce作業(yè)。 在完成索引填充作業(yè)后，我們等待一個Schema 租用，
步驟4，切換到最終狀態(tài)，所有新查詢可以使用新添加的索引。 TiDB：添加索引的狀態(tài)（delete-only） 以下是添加索引的屏幕截圖之一。
我們可以使用任何MySQL客戶端查詢在線DDL作業(yè)的狀態(tài)。 只是簡單地運(yùn)行“show status”語句，我們可以看到高亮部分，當(dāng)前狀態(tài)是“delete-only”，并且操作是“添加索引”。 還有一些其他信息，如誰在做DDL作業(yè)，當(dāng)前作業(yè)的狀態(tài)和當(dāng)前schema 版本。 TiDB：添加索引的狀態(tài)（添加索引） 如紅筆所示，此屏幕截圖顯示當(dāng)前狀態(tài)是“write reorganization”。
在本節(jié)中，我將介紹如何測試系統(tǒng)。
測試用例來自社區(qū)。 在MySQL驅(qū)動程序/連接器，ORM和應(yīng)用程序中有很多測試用例。在硬件和軟件上執(zhí)行故障注入以增加測試覆蓋。關(guān)于網(wǎng)絡(luò)，我們模擬延遲，故障，分區(qū)，以檢測當(dāng)網(wǎng)絡(luò)不可靠時我們的數(shù)據(jù)庫中是否有bug。我們使用Jepsen和Namazu進(jìn)行分布式測試。這是我們的未來計劃： - 我們計劃在未來使用GPS和原子鐘。 - 我們正在改進(jìn)我們的查詢優(yōu)化器以獲得更好更快的查詢結(jié)果。 - 我們將進(jìn)一步提高與MySQL的兼容性。 - JSON和文檔存儲類型的支持也在我們的規(guī)劃中。 - 我們計劃支持推動更多的聚合和內(nèi)置功能。 - 在將來，我們將使用gRPC替換自定義的RPC實(shí)現(xiàn)。
說明 如有轉(zhuǎn)載，請務(wù)必注明出處： http://blog.csdn.net/antony9118/article/details/60479063
新聞熱點(diǎn)
疑難解答
圖片精選
