【編者按】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 是 bob@Email.com，這都屬于元信息。即便你的 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，算是開了一個好頭，非常感謝大家，希望大家都能參與進來。

本文系國內 ITOM 行業領軍企業 OneAPM 工程師整理。OneAPM 致力于幫助企業用戶提供全棧式的性能管理以及 IT 運維管理服務，通過一個探針就能夠完成日志分析、安全防護、APM 基礎組件監控、集成報警以及大數據分析等功能。想技術文章，請訪問 OneAPM 官方技術博客
本文轉自 OneAPM 官方博客

總結

以上是生活随笔為你收集整理的TiDB：支持 MySQL 协议的分布式数据库解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。