【編者按】TiDB 是國內 PingCAP 團隊開發的一個分散式 SQL 資料庫。其靈感來自於 Google 的 F1，TiDB 支援包括傳統 RDBMS 和 NoSQL 的特性。在國內ITOM 管理平臺OneAPM 舉辦的技術公開課中，TiDB的高階工程師劉奇從HBase特性、TiDB的優勢和系統架構等方面進行了詳細闡述。以下為演講整理：

HBase簡介

眾所周知，在SQL方面處於頂級的有兩個公司，一個是Oracle，他們已經積累了大量的經驗，另一個是谷歌，谷歌 F1在2012年釋出了一篇論文，個人認為它是全球最優秀的SQL OLTP資料庫。

1978年左右，資料庫剛剛發展時出現了SQL RDBMS。2000年左右，國內開始流行網際網路，網際網路對Oracle資料庫也產生較大的衝擊。現在，傳統的資料庫大部分是集中在傳統領域，網際網路方面用得比較多的是MySQL，其次HBase等 NoSQL 也吸引了大量的使用者。

為什麼會出現NoSQL？最開始所有人都用SQL Database，那時比較高階有Oracle，開源的還有MySQL、PostgreSQL。可是隨著業務的迅速發展，資料庫成為了瓶頸，於是促使了NoSQL的誕生，NoSQL將Scale放在第一位。如果業務快速發展，擴容會成為亟待解決的首要問題。這時，大多數人會選擇放棄事務一致性。什麼是一致性？比如使用微信時，如果我加你為好友，這是一個雙向關係，對應到資料庫中至少是兩個操作，第一是在好友列表裡把你加進來，第二個是你的好友列表裡把我加進去。如果這兩個列表的資料庫放在不同的機器上，就需要保證一致性。否則可能會出現我是你的好友，但你的好友中卻找不到我的這種情況。但這中間可能會出現多種情況，比如我把你加為好友，然後修改資料的時候Crush掉了，這個時候傳統方案是會引入一個訊息佇列，有的還需要做一些補償，這些問題在NoSQL裡處理起來相對麻煩。

國內最大的HBase使用者是小米公司，有幾個HBase的Committer，所以經過一些修改後可以支援分散式事務，於是能夠解決之前的問題。為什麼在面臨諸多選擇時，小米會選擇HBase呢？就目前情況來說，主要還是技術選型和人才儲備上的考慮。MongoDB大家應該不陌生，但用到一定程度後，總會出現各種問題，甚至有文章呼籲大家放棄MongoDB。但所有資料庫都不是“十全十美”的，沒有最好，選擇最適合的尤為重要。

很多時候產品都有其特性，在滿足其特性或者規格的情況下，使用起來可能非常順手，否則十之八九都遇到各種麻煩。比如小米使用HBase就非常順手，但其他的公司則不一定。道理很簡單，如果不熟悉其使用場景，也不知道在相應場景下配什麼引數，所以會出現各種各樣的問題。

事實上，HBase有非常好的特性，目前在小米公司可以每秒跑一百萬OPS，最近Pinterest公佈他們的HBase每秒可以跑三百萬個OPS，這個數量級可以遠超很多網際網路公司。HBase在讀寫一致性方面非常出色，有很好的自動Scale的能力，通過Block Cache和Bloom Filters可以很好的解決查詢問題，是否在磁碟上也可以通過Bloom Filters來判定。

另一方面，Oracle把一部分邏輯會放在CPU/硬體裡，對應的HBase也會把一部分邏輯下推到對應的RegionServer 上。對於一個分佈系統來說，如果需要查詢一個條件，可以直接把這個簡單調節推到對應的RegionServer上執行。再比如求和運算，現在有一百億資料，甚至一千億條資料，分佈在10個節點上，最快的求和方法是讓所有節點同時運算，將這個條件下推得到所有對應資料的和，最後收集到10個數據的和即可。其實還可以繼續往下推，這是比較複雜的資料庫優化技術，實際情況還會更復雜。這在 HBase 裡面依賴 Coprocessor 來實現。

大家應該對MVCC比較熟悉，也就是多版本，它的優點在於可以多次讀取而不會block。然後還有一個很好的特性，假設你用的Database，MVCC在你沒有做compaction之前可以回到任何時間的資料。現在雲服務上也可以每隔半小時做一次快照，實際上如果使用MVCC回到任意一秒的話，可以完全不需要快照。

TiDB的優勢

下面再介紹一下我們的產品 TiDB，Ti是元素週期表裡的元素。大家如果瞭解我們團隊的程式設計師，就知道他們都比較 Geek，取名字要麼在希臘神話裡選一個神的名字，或者在數學裡找一個希臘字母， 但是看了一圈，好坑都已經被占上了。於是，我們在化學元素週期表裡找了一個金屬作為專案名稱，對於Database而言，它必須是高速穩定的，剛好鈦金屬有很強的防腐蝕性，所以選擇了鈦（Ti）。

因為TiDB的目標是谷歌F1，所以自然會滿足以上特性。首先是可以滿足分散式一致，也就是說對於應用來說，不用關心後面分成多少個機器，事務的一致性是必須保證的，比如我們之前提到的A關注B，兩個互相加好友或者轉帳，可以直接利用一條SQL搞定，而無需擔心中間過程。另外一個特性是相容MySQL協議，國內大概有70% 的網際網路公司都在使用MySQL，為了考慮大家的遷移成本，我們會相容MySQL協議。同時，由於已經很多APP在MySQL上執行，為我們提供了充足的測試樣本。TiDB的測試有五百多萬個，每次提交一行程式碼時，後面大概有6個機器並行地跑Test，五百多萬Test所需時間大約是十分鐘。為了照顧各種引擎愛好者，我們還支援了LevelDB 、RocksDB、LMDB、BoltDB等。TiDB主要是採用 Go 語言開發的，其程式碼簡單、易於理解，而且效能非常高。

系統架構

任何用MySQL協議寫的程式都可以直接使用TiDB，其中間是MySQL協議相關的內容，再往下是SQL Layer。其次是事務KV層，這正是F1和Spanner構造得最為精密的地方。最底層的構造是從KV開始，在KV基礎上架一個分散式的KV層用於支援事務，然後再讓SQL語句直接對映到KV層上。

接下來，向大家介紹 現階段 TiDB 使用的分散式事務是如何在HBase上實現的，早期版本中，我們參考的是 Google 的 Percolator 的模型。首先假設有一個Client，先為其分配一個 Timestamp，在Google論文中叫做Time Oracle，用來分配時間戳。分配之後可以做讀寫操作，根據時間戳進行快照讀。最後提交之前要先Prepare，Prepare的時候會檢測是否衝突，最後提交時會得到Commit，如果整個過程沒有任何衝突就可以提交。

上圖代表了一個例項，最初帳戶情況是Bob有10美金，而Joe有5美金。前面的數字代表其版本，當前是第6個版本，指向的是第5個版本，為10美金，Joe是2美金。

假設Bob要轉4美金給Joe。第一步，要先轉出去4美金，10美金變成6美金，由於被扣掉4美金，然後會標註一下自己是主鎖。

Joe當前是第7個版本，因為他得到了4美金，所以餘額變成了6美金，同時標記自己指向另外一個主鎖Bob。

到第八個版本時，主鎖會指向現在的7，這時可以把主鎖刪掉。如果訪問的時候發現主鎖被刪除，那麼主鎖衝突已不存在，可以進行提交。同時，它會把自己的鎖刪掉，中間還有一些其它的清理過程。

整個事務模型中會有單點，從Time Oracle分配一個時間戳，單點決定了整個系統的效能。Google論文裡有一個對應描述，可以跑到兩百萬每秒。因為事務開始和結束的時候都需要取一個Timestamp，所以他們最快讀寫事務的速度是一百萬每秒，他們已經在論文中實現。實際上，現在有更好的方式可以提高速度，如HLC和一些Time Oracle的改進演算法。

關於Spanner，我們重點參考物件是谷歌Spanner和F1。由於Spanner高度依賴於時鐘，所以谷歌有一套原子鐘和GPS時鐘，GPS訊號可以給出地理位置和時間。為什麼需要原子鐘呢？由於GPS時鐘特別容易受到干擾，比如天氣惡劣時GPS時鐘就不能執行，而原子鐘仍然適用。

上圖是谷歌F1的一些資訊，其中單獨標記了谷歌F1的這篇論文，大家有興趣的話不妨細讀一番，目前整個TiDB所做的都是在實現這篇論文。假設有一千億資料，你現在要給某一列加索引時，在傳統資料庫上應該如何操作？比如說在分散式環境下，你用MySQL給一列新增一個索引，這幾乎很難實現，而且還必須保證index的一致性。更多細節請參考論文。

TiDB是如何從SQL遷移到KV上的呢？由基礎知識可知，傳統的 RDBMS資料庫底下一般是一個B-Tree。對於分散式關係型資料庫，站在更上層一點看，比如谷歌的F1，資料庫底層都是KV層，都在KV層邏輯下操作。如果有一個User Table，在TiDB裡假設你的Table的結構是由uid、name和email構成。在TiDB裡有一個隱藏列叫做RowID，所有的操作包括行鎖都是鎖的RowID。假設RowID是1，uid是XX，Name是Bob，Email是[email protected]，這都屬於元資訊。即便你的Column name很長，但最後在資料庫裡儲存的是原資訊。在TiDB中， 每一列都有唯一的UID。

假設Table的ID是1，uid的 ID 是2，name的ID是3，email的ID是4。在資料庫中儲存為一個KV結構，然後對TableID、RowID 、ColumnID進行重新編碼，直接將這個表的一行切成4個KV。這時候如果進行select，Email等於某一個值的話，於是可以直接取出來相應的值，速度非常快。

相容MySQL

TiDB對MySQL協議有很好的相容性。有一些比較知名的MySQL應用和管理工具，比如WordPress、PhpMyAdmin， MySQL Workbench，都可以直接基於TiDB執行。而且資料可以無限擴充套件，不再是單機資料庫。其次，TiDB還相容各種ORM，比如XORM、Beego ORM等，能夠支援很多MySQL的應用。每一次程式碼更新，這些ORM Test會自動執行一次，從而保證與MySQL的相容性，雖然還有一些比較細微的特性暫時沒有支援。現在已經支援非同步的 Schema 變更，對於 DDL 操作，不會阻塞線上的業務。

關於社群

目前 TiDB 完全開源在Github上面。開源和開放的概念是兩回事，很多大公司，所謂的開源只是把程式碼上傳一下，國內比較知名的案例也挺多的，大家知道很多專案都已經放棄了維護。但是我們是打算完全以一個開放的心態來做整個事情，全部的程式碼，全部的討論， Code Review，Bug Tracking，Roadmap 都是開源的，畢竟通用的分散式 OLTP 關係型資料庫是一個非常前沿而且極端重要的領域，未來是雲上的 DBaaS 的重要組成部分，但是在這塊目前整個技術社群，即使全球來看都沒有一個太成熟開源解決方案，TiDB也目前也處於早期，從架構上來看，我們將 SQL 層和 KV 層做了很徹底的分離，這也是我們希望更多開發者能根據自己的需要更方便的進行定製，我們也想得很清楚，依靠某一家公司，或者某幾個人的力量是不夠的，我們 PingCAP 只是將這一把火點起來，將框架搭好，制定好透明和公平的規則，吸引更多的合作公司和獨立開發者，一起將 TiDB 做成中國第一個世界頂級的開源專案，實現共贏。

好的專案可以由社群進行推動，就比如HBase，HBase不屬於任何一個公司，但是社群一直推動它進步。目前我們在GitHub狀態是有3200+的Star，有32個Contributors，算是開了一個好頭，非常感謝大家，希望大家都能參與進來。