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