7月28日，以“科技，洞見未來”為主題的 QingCloud Insight 2016大會將在北京召開，連接云計算產業鏈上下游，展示 IT 領域最新研發成果。作為 NewSQL 技術的代表，PingCAP 聯合創始人&CEO 劉奇將在本次大會上講述開源數據庫 TiDB 的設計與研發技術細節。在云和大數據時代，數據庫領域發生了什么？新應用需要什么樣的數據庫？開發者需要哪些新技術？劉奇日前接受 CSDN 記者的專訪，從 TiDB 的研發開始，就傳統數據庫面臨的挑戰，新型數據庫的特性，開源模式的優勢，TiDB 的研發進展，以及數據庫與云計算資源更好配合的方式等問題進行深入解析。
　　
　　PingCAP聯合創始人兼CEO劉奇
　　劉奇，PingCAP 聯合創始人兼 CEO，先后創建了 TiDB、Codis 等知名開源項目。曾任豌豆莢、京東資深系統架構師。同時也是知名的 Go 語言專家和 Redis 專家。現從事開源的分布式 NewSQL 數據庫 TiDB（受 Google F1 啟發）的開發。擅長高并發、大規模、分布式數據庫系統架構設計。
　　數據庫領域的變化
　　CSDN：首先談談您在 QingCloud Insight 2016 上的分享話題。
　　劉奇：我會講怎么去構建一個分布式數據庫，主要是介紹我們是怎么實現 TiDB 的。經過大約一年半的研發，TiDB 現在已經發布了 Beta 1版本，進入一個快速迭代的周期，預期在三個月內能迭代到一個 GA 的版本。作為一個數據庫產品，我們對 TiDB 進行嚴格的測試，以保證數據不會出問題。
　　CSDN：哪些人應該了解這個內容？
　　劉奇：DBA、系統架構師、CTO 甚至 CIO，因為他們需要了解Database 對于企業真正的價值。不同數據的重要性是不一樣的，核心價值的數據永遠不能丟失。比如說銀行，最核心的可能就是賬號、存款這些金融相關的這些數據，其次就是和業務相關的，再次就是一些日志。
　　CSDN：金融等行業核心有傳統關系型數據庫，也在針對不同數據嘗試 NoSQL，為什么還需要 TiDB 這樣的 NewSQL 技術？
　　劉奇：銀行其實也面臨互聯網轉型的壓力，傳統數據庫經過這么多年，已經不能適應現在轉型期用戶數據增長的速度，也不能很好地支持跨數據中心多活——熱備都是比較過時的技術。當然銀行在很大程度上還要考慮風險，即使有一個新的數據庫，他們也很難在短時間內將其部署到最核心的業務，但是可以先從外圍開始測試，體驗分布式帶來的好處，支持業務快速地往前發展。
　　CSDN：不僅 TiDB，很多分布式的數據庫都采用開源的模式，為什么這個領域這么喜歡開源？
　　劉奇：首先，數據庫可以分為 OLAP 和 OLTP 兩大類，OLAP 對于數據的安全性重視程度沒有 OLTP 那么高，丟失幾條數據對于用戶行為分析而言關系不大。目前開源領域以 OLAP 居多，因為實現難度和風險更小，但是真正往 OLTP 上走是非常困難的。實際上，在 Google Spanner 論文出來之前，就沒有真正的大規模 OLTP 分布式數據庫，OLAP 的系統可以輕松擴展到兩百臺機器，但 OLTP 數據庫能上到兩百臺機器是非常罕見的，以前也沒有什么特別好的技術。被 Apple 收購用于提供 Apple 內部服務的 FoundationDB，也就能 Scale 到一百臺左右的規模。很多同行都走了很多的彎路，Spanner 一出，架構就得跟著重新去改。
　　而使用開源數據庫，無論是從被綁架的風險，還是說靈活程度，可擴展性，甚至是和其他工具的整合，都有明顯的優勢。
　　首先是不會被某個數據庫綁架。其次，開源是大家協作的一個系統，通常你遇到問題很有可能被別人 Fix 掉了，而且你也有很多地方可以交流經驗。同時，很多人會參與貢獻，哪怕是一點小需求，只要用的人足夠多，官方一般都會接納——就算官方不接納，你也可以 Fork 一些分支完成自己的需求，這是商業數據庫不可能做得到。另外是和其他開源工具的整合，開源對開源一般都會很友好，比如整個阿帕奇社區幾乎所有的東西都可以很好地整合，Hadoop、Spark、Flink 最終會形成一個相互依存、良性競爭的超級大的生態。
　　TiDB 的研發思路
　　CSDN：談到 Google Spanner 的論文，TiDB 在哪些方面借鑒了它的設計，哪些方面是有獨到的一些創意？
　　劉奇：TiDB 大量地借鑒了 Google 的論文，也做了很多自己的改進。比如說：
　　Google 使用的是 tech source，盡管有其他的實現，但沒有一個真正受過大規模生產環境的考驗。我們在協議上選擇的 Raft，也是經過了非常嚴峻的生產環境的考驗，比如 etcd 、Hashicorp 都在用 Raft，大家還有很多基于 Raft 專門造的各種輪子，同時 Raft 性能和 Paxos 差不多，但簡潔性是后者所不具備的。
　　關于協議，還有 Google 內部使用了自己的 ORM，而我們兼容的是 MySQL 協議，在易用性上比 Spanner 或者說比 F1 要好很多，用戶不需要重新學一套新的東西就可以直接用；我們接下來還會支持 MySQL 的 Documents store，用起來就更爽了。
　　另外在整個架構上，Google 依賴自己的 Colossus 分布式文件系統，而我們是不依賴的。如果依賴一個分布式文件系統，用戶需要多部署一個新的組件，同時也會造成一定的 latency 上升，這是我們不希望看到的。
　　再一個比較重要的改進就是原子鐘，這是 Spanner 最強的地方—— Google 內部有一個原子鐘加 GPS 時鐘，組成一套精確的時鐘系統，這在外面是沒有的。我們在事務模型上面使用了 Percolator，是 Google 之前發表的另一篇論文里提到的一個增量處理的事務模型，這也是外面沒有原子鐘的變通方案。
　　CSDN：能否解釋具體是怎么實現的？
　　劉奇：按照原來的 Percolator，會有一個 Server 提供直接時鐘服務，也就是單調遞增的時間戳的分配，它本身是高可用的，通常會部署三到五個副本，大概每秒可以分配四百萬到八百萬個時間戳。從目前的需求來看，每秒四百萬個時間戳是綽綽有余的，這是在沒有原子鐘的時候的一個替代方案。另外一個方案就是 HLC，但 HLC 如果要保證線性隔離級別，需要設置一個時鐘適中的精度，但是沒有云廠商明確說時鐘精度一定保持在什么范圍。這是一個比較大的問題，如果時鐘精度超出這個范圍，結果就是錯的。我們不想因為時鐘精度造成用戶數據出錯的可能，所以就選擇一個更加穩定的一個方案。HLC 也是Kudu 和 CockroachDB 采用的幾乎同時發表的技術極為相似的兩篇論文。
　　CSDN：兼容 MySQL 的方式是業界通用的做法嗎？
　　劉奇：不是，主流做法是我搞一套我自己的，讓用戶切進來，這對于新東西的推廣的壓力非常大。兼容它很重要一點是數據庫的測試，我們現在測試用例都是用幾百萬級的，600 多萬個 Tests，可以把 MySQL 的兼容，大量 Test 拿過來用來測試，如果靠人去構建這個 Test 基本上是不現實的事情。MySQL 已經是一個很好的平臺，融入平臺，可以讓大量已有的生產力得到發揮。如果不能很好地兼容這個平臺上所有的東西，反而自己去建立一個平臺，周期是很嚇人的。
　　CSDN：會追的最新版本的 MySQL 嗎？
　　劉奇：我們現在追的是 5.6，因為 5.7 的官方也還在快速的更新，比如說5.7推出的 Documents store，現在還沒有用戶，我們這時候去支持它是沒有太大的意義。我們做一個東西一定是滿足用戶需求，然后兼容協議，對用戶來說遷移特別簡單，就比如說現在直接測試。
　　CSDN：是否需要開發一些專用的工具來支持 MySQL 到 TiDB 的遷移？
　　劉奇：不需要其他所謂的第三方工具，直接使用任何已有的 MySQL備份、恢復工具就可以了。我們現在的測試都是直接把 MySQL 數據導出來，導入到 TiDB，再拿 TiDB 的數據導回 MySQL，完全不需要任何新的工具。絕大多數時候一行代碼都不改，立刻可以獲得所有的新特性和分布式的優勢。
　　CSDN：傳統的 DB2、Oracle 的遷移也是一樣簡單的嗎？
　　劉奇：這個事情就比較麻煩了，因為我們并不兼容這個 Oracle，也不兼容 DB2，而且它們互相也不兼容。這時候用戶如果要遷移，用戶需要改它的 SQL，需要改掉存儲過程，因為我們不支持存儲過程、觸發器這些前兩代單機數據庫的技術，對一個分布式系統來說，如果在這個地方寫個存儲過程，這個存儲過程訪問的數據，又跑在其他的機器上面，這個時候存儲過程的理解，和用戶對于前面兩代的傳統數據庫技術的理解是不一樣的，那按照它前面這個思路去寫現在這個程序有可能會出現一個比較大的問題。所以傳統像 DB2，Oracle 遷過來是稍微有點麻煩的，就是他們需要自己去改 SQL。
　　CSDN：對 NoSQL 端的兼容有什么樣的計劃？
　　劉奇：我們不考慮兼容 NoSQL（當然用戶可以自己去修改兼容MongoDB 或者 HBase 的 API）。NoSQL 已經是上一代的技術，我們沒有必要在上面再做太多的別的一些東西，直接跳到 NewSQL 這一代就可以了。國外有人在 PostgresSQL 上做一套 MongoDB 的兼容，我們認為沒什么意義。而我們兼容 MySQL 協議，是給 MySQL 提供了很多原本不能夠實現的東西，比如說異地多活，跨數據中心復制和容災，水平伸縮。
　　CSDN：水平伸縮能夠支持多大的規模？
　　劉奇：我們的設計，單個數據庫支持千級別的機器，如果超過這個數量可以重新再布一個新的實例，又可以支持這種千級別的機器。但目前還沒有找到這么大的業務。
　　CSDN：目前有如何商業化的考慮嗎？
　　劉奇：TiDB 的核心技術是完全開源的，但我們將來會提供企業版。我們有一個 On-Premise 的版本 ，提供的一些監控和管理工具，這些工具就不需要開源了。這其實也是目前開源數據庫的主流做法。比如 MongoDB，它的核心東西都是開源的，一般用戶從來不用考慮付費問題，但是它會給企業用戶提供一套收費的非常漂亮的管理界面，這是一個主流的收費模式。另外還可以給用戶提供技術支持和維護的服務，以及咨詢服務。開源不影響賣 License，我們仍然為企業提供 License 授權。
　　云計算環境的整合
　　CSDN：開源分布式數據庫想要在云上做為一個服務提供給用戶和開發者，最重要的工作是什么呢？
　　劉奇：對用戶體驗最好的，肯定是和云做深度整合，用戶不需要關心新啟一個機器這種細節，只要設定一個配額，容量不夠的時候自動給我擴容就好了（同時發郵件通知），這樣 易用性是最友好的，這在國外也比較常見，可以保證業務完全不停，國內很多上第三方市場的方式，就沒有和云做深度整合，易用性相對還是弱一點。
　　CSDN：要滿足異地多活等特性，TiDB 對云資源的使用上遇到過一些問題呢？
　　劉奇：異地多活，起碼異地之間的 latency 不能太大，否則用戶一個正常請求，盡管 TiDB 是采用 Raft 這樣的多數派復制的方案，復制到多個數據中心延遲就比較大了，像 Spanner 可能在百毫秒級別的，它最夸張業務會復制五到七個副本，分布在五個不同的地區。現在國內的普遍做法是同城異地，同城機房可以保持很好的同步，因為 latency 特別小，異地的機房之間仍然保證不中斷業務，但 latency 會上來。
　　CSDN：異地同步可以交給云來自動做嗎？
　　劉奇：這個顯然要由數據庫層來做，因為只有數據庫層才知道這事該怎么做，否則底下的存儲層很難做出最優雅的決定，比如說沒有這個數據庫之前，MySQL 在云上是沒有辦法 scale 的。但是云可以提供很好的支撐，比如說拉專線讓 latency 變小，相當于從硬件層解決問題。簡單來講，數據庫可能是造車的，機房的專線就相當于一條高速公路，因為它的 latency 很小，很適合數據庫做異地多活。
　　CSDN：硬件層的故障對 CAP 的影響，要通過什么方式來解決呢？
　　劉奇：我們使用 Raft 的協議，容災的能力就是二分之 N（N 為奇數），最多不超過二分之 N 的機器掛掉時候可以正常使用，所以在云上面，如果說一個機器掛掉，對于整個系統是沒有影響的，或者一個機器網絡出了問題，它被隔離掉也沒有影響。機制上它并不依賴與云給它提供的穩定性和安全性，這個協議本身就負責保證它的穩定性和安全性。
　　CSDN：TiDB 要部署到云上，對于下層 IaaS 的需求就是一個高速公路嗎？
　　劉奇：主要就是高速公路，另外對機器或者容器的彈性支持，因為數據庫擴容的前提，是新加一個機器，必須要給我提供一個 API，或者提供API 讓我馬上加個 Container，無所謂是 Docker 還是 Rocket。
　　CSDN：開源分布式數據庫未來一定要和 Container 結合嗎？
　　劉奇：結合是肯定的事情。未來分布式數據庫會往多租戶的方向走，但是目前對多租戶還沒有很好的技術支持，這時候怎么去做隔離，容器化是個很好的思路。但是分布式數據庫也不是簡單的容器化的問題，因為它被隔離在很多機器上面，它的配額，或者說它的請求，時時刻刻都在變，你對它的約束必須是在整個系統級別的約束，而不是單機上的約束。未來的程序一定是跑在容器里面的，但是存儲可能掛在容器外面。目前我們已經初步完成了跟 Kubernetes 的整合，還在做進一步的測試。目前我們希望很好地跟 Kubernetes 或者跟 OpenStack 整合。我們有 Dockerfile，可以直接通過 Container 部署，很多熱愛開源的開發者希望自己去編譯，也支持直接 apt-get、RPM 來安裝。
　　開發工具與難點
　　CSDN：使用 Golang 開發的是因為您擅長Go嗎？
　　劉奇：我擅長 Go，也擅長 Rust，但我之前寫了六七年的 C++，再之前大概寫了兩年的 C、一年的匯編，中間還寫過大概半年的 C#，C++ 是用得最久的。但 TiDB 其實是兩層，包括 SQL 層的 TiDB 和 KV 層的 TiKV，分別對應著 Google 的 F1 和 Spanner。TiDB 之所以用 Go 開發是因為開發速度快——實現 MySQL 兼容需要非常大的工作量（目前為止還沒有完全實現兼容），需要選好開發語言讓我們很快地適應 MySQL 的變化。另外，TiKV 是用 Rust 寫的，Rust 的性能非常好，可以滿足 KV 操作的需求；同時它沒有 GC，可以避免了 Go 語言里面本身存在的一些問題；此外 Rust 對錯誤檢查又嚴格無比，這對一個非常重視質量的項目來說非常重要，可以很好地解決了這個多線程數據競爭等問題。
　　CSDN：Go的 GC 問題如何解決呢？
　　劉奇：在壓力大時候，GC 就是個問題，這需要去不斷地優化。我們整個系統的實現，減少內存的分配、重用對象等常規的優化 GC 的算法都用的上。
　　CSDN：到目前為止，開發過程中最耗費精力的是哪一項工作呢？
　　劉奇：應該是測試。分布式系統的測試本身就非常困難，對數據庫的測試要求就更高了，必須要非常嚴謹地做所有的可能性的測試，我們需要有工具不斷地去模擬機器掛掉、網絡斷開、磁盤損壞/變慢、程序被kill等所有的故障，我們現在有 Test 不間斷地殺程序，殺完之后馬上檢查數據有沒有丟，以保證無論出現什么極端的情況，數據都是正確的、完整的，這種測試是非常重要。然后我們還同時跑著幾百萬個 Test，目前也是分布式在跑。我們有很多關于分布式系統的論文，但是關于分布式系統的測試的論文其實很少，高質量的就更少，Google 也沒有告訴大家說 Spanner、F1 到底怎么做的 Test，外面的經驗跟 Google 還是有差距的。
　　TiDB 的適用場景
　　CSDN：測試如此重要，那不同行業的數據庫應用場景千差萬別，我們是要把所有的方向都測試，還是說目前有些側重的場景？
　　劉奇：首先我們能夠支持傳統的 sysbench 之類的常規測試。至于各種行業的不同應用類型，我們不可能完全測試到。我們這邊模擬的方案，和用戶那邊實際報過來的 case，以及用戶提供的數據，我們都會進行統一的測試。但是開源帶來的好處，是用戶可以下載幫我們做測試。
　　CSDN：你認為哪些場景、哪些應用應該使用 TiDB ？
　　劉奇：在數據庫上遇到瓶頸的地方都可以。數據庫不應該是卡住業務的瓶頸，當業務在快速發展的時候，如果這數據庫遇到了性能問題、擴展性、數據保護等問題，需要多數據中心的容災能力，這個時候可以上 TiDB。不一定是場景驅動，只要數據庫真的遇到問題，就可以上一個更好的數據庫。
　　CSDN：采用 TiDB 之前，應該做哪些準備工作？
　　劉奇：如果是 MySQL，那比較簡單，可以拿真實數據直接去測試，可以像互聯網應用常規做法，先導一部分流量進來，可以很好做一個雙寫，去驗證這個系統，并保持這種狀態持續一定的時間。然后如果不是MySQL，可能就需要先轉化到 MySQL 這種語句，最好是拿自己實際業務去測試，這樣發現問題也比較聚焦，不建議只是簡單地 bench 一下。
?

普通下載普通下載

相關電子資料下載

• 多方位優化！憶聯分布式數據庫存儲解決方案，助力MySQL實現高性能、低時延 357
• **分布式數據庫|數據庫數據類型** 157
• 數字化轉型下我國分布式數據庫應用挑戰及發展建議 213
• 華為云新一代分布式數據庫GaussDB正式發布 521
• 華為新一代分布式數據庫GaussDB向全球客戶提供服務 223
• 華為云新一代分布式數據庫GaussDB，給世界一個更優選擇 386
• 如何對全國分布式數據庫機房動環進行監控和報警 59
• 美國數倉巨頭退出中國 國產新一代分布式數據庫開啟達夢新紀元 209
• 低延遲的分布式數據庫架構對于新興的霧應用程序至關重要 250
• 榮膺桂冠！中興GoldenDB蟬聯中國金融級分布式數據庫第一 640