HBase 簡介
在2012年釋出了一篇論文，個人認為它是全球最優秀的 SQL OLTP 資料庫。
1978年左右，資料庫剛剛發展時出現了SQL RDBMS。2000年左右，國内開始流行網際網路，網際網路對 Oracle 資料庫也産生較大的沖擊。現在，傳統的資料庫大部分是集中在傳統領域，網際網路方面用得比較多的是 MySQL ，其次 HBase 等 NoSQL 也吸引了大量的使用者。
NoSQL 的誕生，NoSQL 将 Scale 放在第一位。如果業務快速發展，擴容會成為亟待解決的首要問題。這時，大多數人會選擇放棄事務一緻性。什麼是一緻性？比如使用微信時，如果我加你為好友，這是一個雙向關系，對應到資料庫中至少是兩個操作，第一是在好友清單裡把你加進來，第二個是你的好友清單裡把我加進去。如果這兩個清單的資料庫放在不同的機器上，就需要保證一緻性。否則可能會出現我是你的好友，但你的好友中卻找不到我的這種情況。但這中間可能會出現多種情況，比如我把你加為好友，然後修改資料的時候 Crush 掉了，這個時候傳統方案是會引入一個消息隊列，有的還需要做一些補償，這些問題在
NoSQL 裡處理起來相對麻煩。
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的優勢
但是看了一圈，好坑都已經被占上了。于是，我們在化學元素周期表裡找了一個金屬作為項目名稱，對于 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
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，算是開了一個好頭，非常感謝大家，希望大家都能參與進來。