【BDTC 2018】PingCAP申礫：做一個真正通用的資料庫產品
戳藍字“CSDN雲端計算”關注我們哦！
2018年12月6-8日，由中國計算機學會（CCF）主辦，CCF大資料專家委員會承辦，中國科學院計算技術研究所、中科天璣資料科技股份有限公司與CSDN共同協辦，聚焦於大資料技術如何更好的服務於實體經濟，關注熱門技術在行業中的實踐和應用的2018中國大資料技術大會（BDTC 2018）在北京新雲南皇冠假日酒店隆重召開。
在此次大會的資料庫論壇上，PingCAP工程副總裁、TiDB Tech Lead申礫發表了“TiDB架構解析與實踐”的演講，介紹了分散式關係型資料庫的發展及現狀，並詳細解析了TiDB的架構及其在實際業務中的應用，在會議間隙，CSDN記者有幸對申礫進行了專訪，並就分散式關係型資料庫進行了深入的交流和探討。
CSDN：作為分散式關係型資料庫的TiDB與其他分散式關係型資料庫有哪些不同？
申礫：首先，在分散式關係型資料庫方面有兩類思路，一種思路稱之為Share Nothing，另一種思路稱之為Share Everything，Share Everything的特點是採用共享儲存的架構，例如AWS的Aurora以及阿里巴巴的PolarDB就屬於Share Everything，它們的設計思路就是通過共享儲存方案在不同節點之間共享資料，來解決資料庫的擴充套件問題，並一般採用一個節點寫入，多個節點讀取的方式。這種架構的優點在於，第一，可以利用現有的資料庫核心，例如MySQL和PG，直接提供非常好的相容性，不需要自己去實現協議層和計算層。另一方面，它們的底層儲存確實可以實現一定程度的擴充套件，比如Aurora能夠擴充套件到64TB這樣一個規模，PolarDB也能擴充套件到百TB，這是它們非常大的優勢。但這種架構其實也有一些劣勢，比如說Aurora，現在的寫入是單點，也在嘗試做Multi-Master的寫，但還沒釋出，這裡會有很多一致性的問題需要去處理。另一方面，當資料規模在幾十G或者幾百G的時候，Aurora快取的命中率很高，但是當資料規模達到幾十T，甚至上百T的時候，下層的儲存，包括快取、記憶體等其他資源將會跟不上，吞吐可能達不到那麼高，因為它的寫入還是單點，雖然計算可以擴充套件，但是由於寫入不能擴充套件。同時又很難突破MySQL和PG自身的限制，比如說MySQL對分析型別的查詢就處理的不是很好，很多複雜查詢跑的很慢或者是無法執行。因此，在享用它們的優點的同時，也要承受它的缺陷，或者是自己去投人力做改進，比如現在Aurora也在做並行運算元，包括並行掃表，並行讀索引等，就是因為原有的MySQL 核心無法滿足這樣的需求。
另一類思路Share Nothing的代表產品就是谷歌的Spanner，TiKV其實就是Spanner的一個開源實現。實際上，Spanner現在也在慢慢的演變成一個SQL資料庫，這一點可以在Google Sigmod 17 中的論文《Spanner: Becoming a SQL System》看到。這種架構的好處在於，可以非常容易的擴充套件，甚至可以認為是無限的擴充套件。因為這種架構可以自己解決資料排程問題。TiDB與Spanner的架構或者說解決問題的目的很相似，但是會有些不同。比如說我們是開源且面向通用的場景、通用的硬體、通用的機房情況的，而Spanner需要有專用的機房、硬體時鐘和較好的頻寬保證。但我們想處理的是一個普遍場景的問題，需要能夠讓所有的公司都有機會使用類似Spanner架構的水平擴充套件的資料庫方案，而不需有專門的基礎設施。其次我們首先希望能夠做好一個數據中心之內的解決方案，因為對於大多數使用者來說，一個單資料中心內的分散式資料庫已經能夠解決很多的問題，當然我們也提供了一些方案，能夠去做跨機房的部署，這時候需要和業務去做比較深入的溝通，看如何能夠讓資料庫的跨機房更好用，一起來配合業務解決跨機房高可用的需求。
至於技術細節方面和Spanner的不同，一個比較顯著地是 TiDB更加通用，比如Spanner直到最近才支援DML寫入，它的讀可以通過SQL，它的寫只能通過交換介面。對於我們來說就不可能這樣去做，因為使用者是用SQL寫入資料，特別是在國內MySQL使用者非常多，我們相容MySQL協議這樣的功能，就是希望讓大多數使用者能夠更好的使用TiDB，降低業務遷移的成本，而不是通過一個專用的協議去寫入資料。第二，我們是開源，對所有使用者都是透明的，所有使用者都能看到產品的樣子，因此，能夠非常放心的使用，甚至有問題他們也可以自己來解決。這種開源路線，同時也能夠幫助我們極大的推進產品的成熟。
CSDN：您認為TiDB的最大優點是什麼？為什麼會受到那麼多IT技術人員的青睞？比如相比同樣開源的MongoDB？
申礫：一個事實是，關係型資料庫的需求要遠大於文件型資料庫的需求，不管從技術角度，還是商業角度來講，兩者都不是一個體量，大家可以看到MongoDB和Oracle，完全不是一個市值。一方面，關係型資料庫或者分散式關係型資料庫的需求，一定遠大於分散式文件資料庫的需求，特別是在一些核心的應用上，比如說在銀行交易系統、保險證券這種核心系統中，肯定是關係型資料庫。另一方面，TiDB的優勢在於，第一，我們在設計之初就很好的抓住了使用者、市場和技術需求的痛點，比如TiDB的四個特點，水平擴充套件、高可用、事務、SQL都抓住了使用者的需求和痛點，現在MongoDB的最新版本也提供了事務支援，因為它意識到想進入更嚴肅的應用場景、更核心的業務系統一定要有事務支援，沒有事務的支援，就只能應用在小規模的應用場景中。第二，是TiDB對SQL的支援，現在很多資料庫都開始支援SQL，包括大家都做了很多SQL On Database這樣的方案，甚至Kafka都開始支援SQL，通過SQL這樣一個標準介面來提供服務是更優雅、更通用，也是更容易被使用者所接受的。比如，MySQL的使用者，就可以在不換程式碼，不換Driver，不換關鍵工具，不換使用習慣的情況下，直接遷移到TiDB上來。而如果想遷移到MongoDB或者其他系統上，就需要去寫很多程式碼去做變更。當然MongoDB也有很多優點，比如文件的操作非常方便，而現在我們已經開始支援JSON，下一步會完善這方面的支援，包括在JSON中去建索引，讓使用者能夠在一個數據庫中，除了關係型模型以外，也可以用一些文件的使用方式來操作資料庫。
CSDN：TiDB非常適合於OLTP和OLAP這兩種應用場景，為什麼當初TiDB要聚焦在這兩種應用場景之上？
申礫：其實在最開始的時候，我們最想解決的就是一個OLTP的問題，因為OLTP是上游，它是最關鍵、最核心、最高價值的一個地方，我們想到的就是如何讓使用者可以更方便的擴充套件，解決交易型別資料業務的水平擴充套件問題。一開始我們希望用MySQL叢集，MySQL單機，甚至是其他資料庫以解決單機不能擴充套件的問題。但後來隨著我們不斷去演進技術以及使用者的需求，我們漸漸發現，使用者其實除了交易型別的需求之外，還有一部分分析型場景的需求。在我們最開始的幾個商業客戶中，就有一家是用TiDB做分析，而不是做交易，它是一個廣告點選分析系統，通過TiDB去彙總資料做報表，觀察點選效果。這家客戶以前使用的是MySQL面臨的困難是，第一，資料存不下來，第二，MySQL做分析很吃力。而使用TiDB，一方面資料能夠擴充套件，另一方面，分析能力也獲得了增強。我們發現了這樣一個場景，因此就不斷去加強TiDB的分析能力。為此，去年我們把優化器進行了重構，使得TiDB的分析能力得到了極大的增強。同時，從TiDB的1.0到2.0版，我們在TP的穩定性和正確性上，做了非常多的測試，包括驗證、Chaos、混淆測試等去提升穩定性。另一方面，在TPC-H這個比較標準的Benchmark上，我們的1.0到2.0版本有了質的飛躍，包括所有的查詢都有了數量級的提升，還有一些查詢以前跑不出結果，現在已經可以跑出結果。而從2.0到最新發布的2.1，我們在TPC-H上又發了Benchmark，以前執行很慢的幾個SQL現在能夠執行的很快，我們後面還會再持續優化它，包括引入更多的Benchmark，比如說TPC-DS這樣的Benchmark。其實，我們的資料庫是希望解決TP和AP混合場景的需求。剛才提到，我們的產品需求有些是使用者挖掘出的，比如在一個銀行的核心交易系統裡面，使用者既用TiDB來處理線上交易，又用它來算報表，這就是一個混合場景，這些問題如果使用Oracle，可能需要把資料同步出來去其他地方彙總報表。這樣的話，實時性，方便性就會差很多。而在這些方面，我們也在持續加強，希望能夠真正做出一個HTAP實時資料處理平臺。
CSDN：請您簡單的介紹一下TiDB的架構，總結一下它的亮點。
申礫：從大體上說，可以認為TiDB有兩個比較重要的特點，第一，TiDB是完全由我們自主研發的產品，因此，我們可以很容易的去修改和改進，但如果是使用基於其他開源專案的產品，如果使用者沒有很強的技術實力，將很難做這樣的事。第二，得益於開源的運作方式，使用者會在很多的應用場景中使用我們的產品，也能夠給我們反饋很多非常好的問題，這時候，我們就可以收集很多應用場景，有的放矢的去做針對性的優化和調優，從而更好的支撐大多數使用者的使用。在具體技術方面，TP方面我們會加強，比如會提供Plan Cache這樣一個比較好的特性、優化器的改進以及能夠在儘可能短的時間內，找到最好的一個開源計劃，保持其穩定及動態的更新，包括怎麼維持它的穩定，怎麼使用一些啟發式的規則，保證其能夠在Cost-based Optimizer這個框架內，不受過期的統一性影響，依然能夠找到最好的產品計劃，還包括整個從TiDB SQL層到儲存層優化的打通，從上到下的聯動和優化，這是TP方面優化的一些思路。另一方面，在AP方面，我們做了優化器的改進，把優化器整個推倒重寫，做了一個純基於代價的產品模型，能夠處理很多複雜的查詢，我們有HashJoin，IndexJoin以及Sort Merge Join三種Join運算元，而MySQL只有一種Join運算元，我們還能夠根據代價去自動選擇Join演算法，包括對關聯字產品的優化，對OuterJoin的消除等非常多的優化手段，可以看到我們的優化器現在是一個演進非常快也非常強大的優化器。
另一方面，是執行引擎的優化，我們在傳統的行處理模型基礎上，做了一次Batch加向量化的優化，這樣優化器就可以感知到使用者可能是要處理大量資料，這時，就可以並行的一次處理一批資料，而不是一行行處理。我們還可以從一個運算元將一批資料交給上一個運算元，這就減少了函式的開銷。另外，在P4之間，我們是用一種列存的方式在記憶體中進行資料表示，一方面能夠加速並減少記憶體的開銷。另一方面，可以在此基礎之上做向量化，就是可以一次處理一列資料。這樣也就能夠加速整個資料的處理過程，減少呼叫開銷。而且我們很多運算元都是並行運算元，包括掃表、掃資料、掃索引、做Join、做聚合，包括做投影操作都是並行運算元，這樣一個比較智慧的優化器，加上高效，強大的執行引擎，共同提升了整個分析的效能。目前，我們也在去做優化器執行引擎的的下一步改進，希望真正能夠處理任意場景的查詢。現在，有些使用者已經在TiDB中執行幾百行的SQL，我們希望以後這種查詢也能夠更加輕鬆，不需做任何改動就能夠得到很好的處理。同時，在上百TB的資料裡面做分析時，我們採用的包括行列快取，冷熱資料分離這樣一些策略，將能夠極大加速分析的效能。我們的計算儲存架構，也能夠很方便的將儲存引擎、計算引擎分別做優化，甚至可以多套儲存和計算引擎混布在一個叢集當中，共同提供服務。系統可以智慧的將不同的資料處理請求或者一個請求內的不同任務去分發給不同的儲存或者計算引擎處理，從而讓TiDB為使用者提供了一個真正的實時資料處理平臺。使用者不需要再關心資料怎麼去處理，只需要通過介面轉載資料就可以了。
CSDN：TiDB被稱為是雲原生的資料庫，您對雲原生資料庫是怎麼看待的？
申礫：關於雲原生，我覺得這個概念可以這樣理解，就是應該能夠非常好、非常容易、非常高效的與雲結合。另一方面，使用者需要的可能不止一套資料庫，也許每個業務都需要一套資料庫，並需要做業務上的隔離。這在單機資料庫時代，雖然管理起來也相對複雜，但實際上並沒有那麼困難。但對於一個分散式資料庫來說，管理多套分散式叢集，開銷還是非常大的，我們也希望能夠藉助於雲，降低使用者使用和管理多套資料庫的成本，一方面我們開發了TiDB Operator，這款幫助K8S來管理和排程資料庫叢集的元件，另一方面，也通過雲平臺，讓使用者能夠非常簡單的建立或者銷燬多套例項，而無需管理員的參與。同時，也希望能夠藉助雲的環境，一方面簡化使用者的使用成本，另一方面也簡化我們自己的成本。雲能夠提供一個很好的底層資源的管理和排程的手段，而且雲是未來的趨勢，不管是在國內，還是在國外，很多使用者都希望資料庫能夠有云上的服務，我們馬上會在AWS上提供服務，讓使用者通過簡單的幾下點選就能建立一個數據庫叢集。
CSDN：TiDB為什麼要保持開源？您覺得開源對於TiDB的發展起到了什麼樣的作用？
申礫：分兩方面談，一方面是技術，一方面是商業。因為開源是一個軟體分發和協作的一個方式，從技術上講，我認為做基礎架構，特別是資料庫這樣非常關鍵的底層技術軟體，包括作業系統，編譯器等，開源可能是唯一正確的手段，因為開源一方面能夠讓產品接受使用者的檢驗，督促你去把產品做得更好，幫助你發現系統中的缺陷，找到多樣的應用場景，極大地加速軟體產品的成熟。另一方面，也能從開源軟體獲得了很多幫助，包括很多社群的會員會幫助我們檢驗、設計、甚至重寫程式碼。事實上，我們公司只有大概一百人左右，而我們的社群貢獻者有幾百人之多。可以看到，許多知名的基礎元件都是通過開源才獲得瞭如此廣泛的傳播，包括Hadoop、Linux，如果沒有開源，它們是不可能做起來的。開源能夠極大的加速基礎元件的成熟和開發速度，不開源，沒有足夠數量的使用者使用你的產品，那麼，很多使用者就不敢去使用產你的產品。開源實際上相當於產品的一種可信性證明。從商業方面談，開源也對我們有很大的促進，因為通過開源，軟體的分發成本，獲客成本都會變得非常低，通過開源社群，會獲得很多關注，很多人也會使用我們的產品，也會和我們共同討論商業上的一些問題，這就是開源的價值。而最近IBM收購紅帽，微軟收購GitHub，也都是因為看到了開源的價值，而且開源也確實具有很高的商業價值，才有了這一系列的收購。總之，在矽谷，開源，特別是在To B領域的開源正進行的如火如荼，在國內也有一個非常好的增長趨勢。所以，開源無論從技術還是商業上，都對基礎軟體的發展非常有利。
CSDN：分散式關係型資料庫在哪些方面還存在不足？改進的方向在哪裡？
申礫：作為一個分散式資料庫來說，對於未知應用場景的處理應該說是目前最大的挑戰，我們需要去認真思考如何去優化我們的產品，從而在未知場景下，使其依然能夠很好的工作。在技術方面，就像阿里巴巴的李飛飛教授所說的那樣，分散式關係型資料庫或者說分散式資料庫是一個遠沒有解決的問題，各資料庫廠商雖然都有自己的方案、架構，但每個方案都有自己的優點和缺點。因此在技術演進路線上還有很多技術問題需要解決，比如說剛才提到的行列快取怎麼去做、冷熱資料怎麼去分離，包括怎麼去利用現有最新的硬體，包括NVM、3D XPoint、FPGA等這樣一些先進的硬體技術去加速資料庫，跟上硬體的技術潮流，不斷改進產品的架構，從而適應技術的演進和業務發展的趨勢，是一個非常值得思考的問題。
CSDN：請您展望一下資料庫發展的未來？
申礫：資料庫現在的趨勢是，雲廠商做資料庫，資料庫廠商做雲。雲廠商做資料庫，是因為資料庫是非常核心，非常關鍵的元件，是具有很高商業價值的產品，他們希望能夠將之掌握在自己手裡。而資料庫廠商看到，雲是未來的趨勢，因此，一定要做雲。把資料庫放在雲端，不管是商業模式也好，運維的簡便性也好，擴充套件方式也好，都是非常便利的。因此，無論對於服務提供商，還是開發者，雲都是非常友好的，所以它一定是未來的趨勢。對我們來說，我們是獨立的第三方，沒有云，但很歡迎把我們的資料庫部署在各種雲上面。另外，在雲之外還有很多中小公司，他們可能有自己的機房，想獨立部署，此外，還有混合雲的方案，因此，我們一方面是希望產品儘可能通用，不需要特殊的硬體、特殊的機房頻寬，就能夠部署在各種場景之下，讓使用者能夠更簡單的使用。另一方面，使用者也不用擔心廠商的鎖定，既可以在此雲上部署，也可以在彼雲上部署，甚至還可以輕鬆的從一個雲遷到另一個雲上。而且我們堅持走開源路線，深度的與使用者做溝通交流，讓使用者知道，我們將盡可能的滿足他們的需求，為他們修改、優化需要的各種功能。這樣我們就能夠在雲和資料庫廠商之間找到較好的平衡，讓我們的資料庫產品能夠更廣泛的傳播，做一個真正通用的資料庫。當然，我們也不排除在一些雲上自己提供資料庫服務，就像MongoDB Atlas做的那樣。目前，我們在GCP上已經提供了這樣的服務，而我們的最終目標，就是要做一個真正通用的資料庫產品。
1.微信群：
新增小編微信：color_ld，備註“進群+姓名+公司職位”即可，加入【雲端計算學習交流群】，和志同道合的朋友們共同打卡學習！
2.徵稿：
投稿郵箱：[email protected]；微訊號：color_ld。請備註投稿+姓名+公司職位。
推薦閱讀
程式設計師加班很嚴重嗎？看看國外程式設計師怎麼懟老闆！
我地鐵都在努力改 Bug，為什麼還要裁掉我？
蘋果高通“情變”禍及所有中國 iPhone 使用者！
講述：一個月薪12000的北京程式設計師的真實生活
↓點選“閱讀原文”，開啟APP 閱讀更順暢