戳藍字“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上已經提供了這樣的服務，而我們的最終目標，就是要做一個真正通用的數據庫產品。
添加小編微信：color_ld，備註“進群+姓名+公司職位”即可，加入【雲計算學習交流群】，和志同道合的朋友們共同打卡學習！
2.徵稿：
投稿郵箱：[email protected]；微信號：color_ld。請備註投稿+姓名+公司職位。
閱讀更多 科技百分百 的文章
