2019年6月29日，杭州天氣炎熱，智匯中心11樓的分布式數(shù)據(jù)庫技術論壇也同樣熱火朝天。

會議于2019年06月29號在杭州市濱江區(qū)智匯中心的11樓準時召開，與會的相關人員積極參與，一起聆聽了來自PlanetScale、阿里巴巴、Pivotal、沃趣科技的分布式數(shù)據(jù)庫相關議題并進行了熱烈的探討。

會議開始后，主持人首先致辭歡迎了嘉賓和會場的朋友，會議同時也通過zoom提供了遠程訪問方式，給不方便現(xiàn)場參加的朋友提供了遠程互動的方式。之后主持人介紹了一下分布式數(shù)據(jù)庫論壇的目標和屬性。

分布式數(shù)據(jù)庫論壇主要關注的是關系型數(shù)據(jù)庫和分布式技術。關系型數(shù)據(jù)庫通過SQL對應用來提供服務，并且提供了事務的ACID特性，在老一輩DBA的年代，曾經(jīng)是時代的寵兒。

但是隨著互聯(lián)網(wǎng)的發(fā)展和業(yè)務的不斷成長，傳統(tǒng)的數(shù)據(jù)庫，也可以說是單機數(shù)據(jù)庫越來越滿足不了龐大的互聯(lián)網(wǎng)人群訪問的需要。大家不得不開始利用NoSQL，map reduce，hadoop等技術來充分利用多機的能力，但是這些技術都需要開發(fā)人員做大量的工作，要自己實現(xiàn)大量的代碼，原先在數(shù)據(jù)庫管理系統(tǒng)上解決的問題都需要開發(fā)人員以相對簡單和重復低效的方式來解決。當然，最開始這些技術確實解決了單機上解決不了的問題，大家對新技術的興趣也非常高，時間長了以后，重復性、人肉的工作越來越多，大家都開始苦不堪言，開始尋找更好的解決方案。

現(xiàn)在騰訊云提供云函數(shù)、阿里云提供云API，讓開發(fā)和業(yè)務人員不用關心底層的具體工具和服務來實現(xiàn)自己的目標，也是在這方面的積極探索。天下大勢，分久必合，合久必分，現(xiàn)在該是合的時候了。

舉個例子，操作系統(tǒng)解決的對單個服務器的透明，要解決進程調(diào)度、存儲訪問、網(wǎng)絡連接的問題，而現(xiàn)在最火的k8s的技術，從某種程度上來說不就是在已有的單機操作系統(tǒng)上做了一層軟件，要解決的問題其實跟操作系統(tǒng)差不多，不過是在多個服務器上，要解決多個服務器上的存儲、在多個服務器上的網(wǎng)絡、在多個服務器上的CPU調(diào)度等等一些問題。這些問題，將解決問題的范圍從單個服務器到了多個服務器。也就是說，就是讓應用程序可以面向的是一個“操作系統(tǒng)”，而不是面向每個服務器上安裝的多個操作系統(tǒng)，讓應用程序和運維人員可以充分利用多個服務器組合起來的能力。

在數(shù)據(jù)庫這一塊，現(xiàn)在比較流行的Google Spanner，TiDB這一類NewSQL分布式解決方案;Oracle RAC、Aurora、PolarDB這種對云化環(huán)境特別有效的共享存儲式分布式解決方案;以及Vitess、MyCat等為代表的分布式中間件都在探索在數(shù)據(jù)庫這一塊的分布式是否能解決單機無法滿足客戶需要的問題。本論壇也主要是學習和探討這方面相關的知識。

作為一個中立和以技術分享、思想碰撞為目標的技術論壇，本次論壇需要特別感謝PlanetScale和Woqutech兩家公司，他們幫忙邀請我們的嘉賓，并提供了場地。

議題

Vitess：Stateful Storage on K8s

首先上場的嘉賓是Vitess原廠PlanetScale常駐日本的工程師Toliver Jue，他為大家?guī)砹祟}為“Vitess：Stateful Storage on K8s”的主題分享。

Toliver算半個中國人，他的父親是香港人，不過他出生在美國，母語是英文，只能通過英語給與會者來分享。Toliver畢業(yè)于麻省理工學院，在Google服務了12年，之后加入了同樣從Google出來的Jiten創(chuàng)立的PlanetScale來負責Vitess相關模塊的開發(fā)工作及亞太區(qū)的相關事務。

Toliver的演講風趣而幽默，他主要給大家介紹了Vitess的由來以及使用案例，Vitess是Youtube為了解決不斷增長的業(yè)務需求來專門設計的數(shù)據(jù)庫中間件，目前來說已經(jīng)在全球排名最前的應用上使用起來了，包括Cash app、Youtube、slack、Pinterest等，目前在國內(nèi)的京東也被大規(guī)模使用，包括3000+ Databases, 18000+ Tablets。

Youtube加入Google以后，Vitess對Borg進行了深度適配，所以對k8s天生是適配的，目前在京東也是在k8s體系上運行。之后Toliver介紹了業(yè)務性能從小到大擴展，Vitess怎么通過讀寫分離、垂直分片、水平分片來支持，以滿足需求的各種場景化案例。

Greenplum數(shù)據(jù)平臺新趨勢

Pivotal的資深產(chǎn)品經(jīng)理吳疆介紹了他負責的其中一個產(chǎn)品Greenplum數(shù)據(jù)平臺。Greenplum 大數(shù)據(jù)平臺基于MPP(大規(guī)模并行處理)架構，內(nèi)置并行存儲、并行通訊、并行計算和優(yōu)化技術，廣泛的應用在金融、證券、電信各行各業(yè)。在最新的Gartner排名中，Greenplum在經(jīng)典數(shù)據(jù)分析領域排名第三位。Greenplum自2015年開源以來，2017年發(fā)布了全新的5.0版本，2019年中將發(fā)布6.0版本。本次分享結合Greenplum的歷史，從五個方面介紹了Greenplum的發(fā)展趨勢：

1) Greenplum和Postgresql的代碼合并(Merge)。從Greenplum開源以來，Greenplum一直致力于上游Postgresql的代碼合并(merge)，在已經(jīng)發(fā)布的greenplum 5.0是基于postgresql 8.3，即將發(fā)布的Greenplum 6.0則橫跨postgresql 的6個大版本，基于postgresql 9.4，在Greenplum 7.0則計劃將代碼merge到greenplum 9.6。隨著代碼合并的加速，越來越多的postgresql新特性被合并到了Greenplum中

2) 大規(guī)模并行處理(massive parallel processing，MPP)架構增強。Greenplum是基于大規(guī)模并行處理(massive parallel processing，MPP)架構的數(shù)據(jù)平臺，在即將發(fā)布的6.0中，新增了若干MPP架構增強的特性，例如復制表(replicated table)，在線擴容，磁盤配額管理等

3) 新的管理工具。介紹了Greenplum的管理運維工具Greenplum Command Center (GPCC)和Greenplum backup/restore工具的新特性

4) 數(shù)據(jù)分析工具的大發(fā)展。介紹了GPText，MADlib，PostGIS等用作文本分析，機器學習，地理信息數(shù)據(jù)分析的新工具

5) 新的運行時環(huán)境。介紹了高性能一體機Greenplum Building Box(GBB)和容器環(huán)境下的Greenplum--Greenplum for Kubernetes。

全球唯一深度兼容Oracle云原生數(shù)據(jù)庫!POLARDB v2.0重磅來襲

絳云作為阿里巴巴PolarDB for pg的資深工程師，給大家介紹了PolarDB體系架構，詳細介紹了對于傳統(tǒng)數(shù)據(jù)庫中不能彈性擴容，TB級實例備份慢，數(shù)據(jù)庫主從延遲高問題等痛點問題在PolarDB中如何解決的。主要強調(diào)了最新的PolarDB 2.0對于Oracle兼容性的支持，并對多模計算等業(yè)務場景進行了詳細的講解。

云原生RDS在K8S中的實現(xiàn)

麻鵬飛作為沃趣科技QFusion的產(chǎn)品經(jīng)理，介紹了QFusion怎么基于k8s來實現(xiàn)全球前三大關系型數(shù)據(jù)庫Oracle、MySQL、SQL server的自動部署，彈性擴容和高可用和一致性保證。

QFusion通過CSI標準接口支持多種存儲類型，利用Operator構建數(shù)據(jù)庫應用業(yè)務，從整體上介紹了怎么基于k8s構建數(shù)據(jù)庫RDS服務的基本注意點。

圓桌會議及技術討論

議題分享完成后，四位嘉賓一起跟現(xiàn)場的聽眾進行了圓桌會議，一起討論分布式數(shù)據(jù)庫的各種技術問題。

Spanner和Vitess的取舍

首先主持人先問了Toliver一個“尖銳”的問題。

Q：在Google內(nèi)部既有Spanner又有Vitess，這兩個從分布式數(shù)據(jù)庫來說是兩個不同的方向，是競爭對手，他們之間的區(qū)別是什么，分別有哪些優(yōu)缺點，Google內(nèi)部是怎么定義這兩款產(chǎn)品的。

Toliver：首先指出主持人的一個問題，Google內(nèi)部并不只有這兩款分布式數(shù)據(jù)庫類型的產(chǎn)品，而是有20多種。Google Spanner和CockroachDB、國內(nèi)的TiDB一樣，是基于BigTable來實現(xiàn)的，就像TiDB是基于TiKV實現(xiàn)的，而Vitess是基于成熟穩(wěn)定的目前最流行的開源數(shù)據(jù)庫MySQL來實現(xiàn)的。Google Spanner專注于數(shù)據(jù)一致性，QPS要求沒有那么高，Youtube之前也考慮過使用Spanner，但是受限于其性能的問題，沒有遷移過去。Vitess的成本比Google Spanner要低的多，又是基于MySQL來實現(xiàn)的，可以充分利用20多年MySQL成熟的各種數(shù)據(jù)庫特性，性能也能線性擴展，能滿足并發(fā)要求高、彈性擴展的各種場景。對于絕大部分的公司來說，要實現(xiàn)Google的這種超大規(guī)模的集群，代價和成本太高，收益和成本不成正比。所以對絕大部分公司來說vitess是更加現(xiàn)實和可落地的。

分布式數(shù)據(jù)庫發(fā)展和未來的趨勢

主持人接著問了Pivotal的資深產(chǎn)品經(jīng)理吳疆一個“超大”的問題。

Q：請您談一下當前分布式數(shù)據(jù)庫的發(fā)展情況，不同的方向和未來的趨勢。

吳疆首先從技術人員關心的高可用、性能、數(shù)據(jù)量介紹了一下分布式數(shù)據(jù)庫需要解決的問題。另外作為資深的產(chǎn)品經(jīng)理，他提到，要做ToB的生意，讓客戶認可你的產(chǎn)品的價值，能夠從口袋里掏錢，你需要做的遠遠不止讓數(shù)據(jù)庫能及時切換、性能達到業(yè)務的要求以及利用多服務器來支持龐大的數(shù)據(jù)量，你還需要關注企業(yè)級特性，比如怎么備份，怎么管理，給客戶培訓讓客戶能方便使用，有高大上的架構要做，有臟活累活你也得做。從分布式數(shù)據(jù)庫趨勢來說，第一：從分布式數(shù)據(jù)庫在互聯(lián)網(wǎng)使用來看，NoSQL等開始加入SQL接口。例如基于hadoop上層開發(fā)了hive等。其實原因很簡單，SQL深入人心，表達能力強，一個不是DBA出身，甚至不是計算機出生的人都可以利用SQL來完成他的工作。第二：老的數(shù)據(jù)庫是基于老的硬件來做的。不管是Oracle、Teradata還是其他的數(shù)據(jù)庫?，F(xiàn)在新Flash硬件、云的環(huán)境都對數(shù)據(jù)庫提供了新的挑戰(zhàn)，分布式數(shù)據(jù)庫必須要適配新的硬件，跟云環(huán)境配合?？偨Y下來兩個趨勢：1)SQL回歸，用戶希望通過SQL這個統(tǒng)一的接口來操作數(shù)據(jù)庫，2)適用新的環(huán)境。分布式數(shù)據(jù)庫需要根據(jù)新的硬件，云環(huán)境來開發(fā)和支持。

沃趣科技的技術總監(jiān)魏興華引用百度前產(chǎn)品經(jīng)理和首席產(chǎn)品架構師俞軍的公式：“用戶價值 = (新體驗-舊體驗) - 替換成本”作為分布式數(shù)據(jù)庫當前發(fā)展情況和趨勢議題的補充。首先，他以沃趣科技的QData的價值為例，說明在替換老的IOE時遇到的困難和阻礙，用戶替換為新的架構需要考慮新的產(chǎn)品的價值是否足夠大，遷移成本是否足夠低以決定是否要替換為QData。而在他看來分布式數(shù)據(jù)庫目前還在寒武紀，處在萬物生長的時刻，各種新技術層出不窮，但是這些技術目前成熟度還不夠，還處在不斷進化的過程中。新產(chǎn)品的價值比舊產(chǎn)品價值好才可能會產(chǎn)生替換，現(xiàn)在來看其實新的分布式數(shù)據(jù)庫是否真正可用和它的價值有多大還有待驗證。而從寒武紀后期的經(jīng)驗來說，要再往前走一步，需要大量的優(yōu)勝劣汰，在這個過程中鍛煉出真金，涌現(xiàn)出真正對客戶有價值的產(chǎn)品才是未來。他對這個未來充滿信心，也期待能早日擁抱這樣的產(chǎn)品。

CAP和BASE理論對PolarDB實現(xiàn)的影響

Q：對分布式數(shù)據(jù)庫而言，繞不過去的一個話題就是CAP理論。魚與熊掌不可兼得，PolarDB在具體實現(xiàn)方面是怎么解決的?

絳云：CAP定理(CAP theorem)，又被稱作布魯爾定理(Brewer's theorem)，它指出對于一個分布式計算系統(tǒng)來說，不可能同時滿足以下三點：

1.一致性(Consistency) (等同于所有節(jié)點訪問同一份最新的數(shù)據(jù)副本)

2.可用性(Availability)(每次請求都能獲取響應，不會出錯)

3.分區(qū)容錯性(Partition tolerance)(以實際效果而言，分區(qū)相當于對通信的時限要求。系統(tǒng)如果不能在時限內(nèi)達成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當前操作在C和A之間做出選擇。)

由于分布式數(shù)據(jù)庫的結構特性，根據(jù)分布式系統(tǒng)的CAP定理，實現(xiàn)ACID事務需要付出很大的成本來維護可用性，所以為了保障可用性而總結出一套弱化的事務特性：

1.基本可用(Basically Available)：系統(tǒng)能夠基本運行、一直提供服務。

2.軟狀態(tài)(Soft-state)：系統(tǒng)不要求一直保持強一致狀態(tài)。

3.最終一致性(Eventual consistency)：系統(tǒng)需要在某一時刻后達到一致性要求。

簡稱BASE，與ACID相對應(acid為“酸”的英文名稱，base為“堿”的英文名稱)。除了上述這些大家耳熟能詳?shù)姆植际嚼碚撘酝?，在實現(xiàn)過程和用戶使用過程，PolarDB還考慮到了因果一致性，寫后讀一致性，會話一致性，單調(diào)讀一致性，單調(diào)寫一致性等的場景。舉個例子，如果用戶對一致性要求比較高，讀到數(shù)據(jù)就必須從寫節(jié)點上取，當然性能肯定就無法保證了。而其實PolarDB是支持ms級延遲的可讀節(jié)點讀的，雖然無法保證那么強的一致性，但是讀性能的擴展能大大提升。類似的PolarDB還有很多這種設計，來進行設計和實現(xiàn)上的平衡。

分布式數(shù)據(jù)庫中間件的全局一致性問題

主持人問完問題以后，就是自由交流時間了，想不到首先發(fā)難的反而是場上的嘉賓。

絳云首先向Toliver提出了一個通常分布式數(shù)據(jù)庫中間件的致命問題：vitess是否能保證全局一致性。也就是說，在分布式場景下，多個服務器來進行同一個事務的操作，是否會出現(xiàn)不一致，另外，對應的死鎖是否能避免。

Toliver解釋，雖然vitess在3.0是支持2PC的分布式事務的，但是對arbitrary deadlock問題目前來說沒有太好的解決方案。

PolarDB相比Oracle的性能

現(xiàn)場的火藥味開始濃烈起來。結果懟人者終被懟，第一個聽眾也對絳云提出了一個關鍵的問題。

Q：PolarDB號稱要替換Oracle，有沒有對比過性能列?

絳云：首先糾正聽眾的一個誤區(qū)，直接的性能對比是不科學的，PolarDB和Oracle沒法采用同樣的服務器、軟硬件，PolarDB采用了自研的Polar Storage存儲，并且采用了三副本，SQL和數(shù)據(jù)量都不太可能一樣。目前PolarDB已經(jīng)支持每秒百萬級的查詢，已經(jīng)滿足絕大部分業(yè)務場景。

Vitess和MyCat怎么競爭

Q：Vitess相對國內(nèi)現(xiàn)在已經(jīng)流行起來的MyCat、DRDS、Sharding Sphere來說是一個新來的競爭者，后續(xù)準備怎么應對?

Toliver：首先說明Vitess是完全開源的，目前開源的版本跟企業(yè)版以及Google內(nèi)部使用的版本是一致的，大家可以放心使用。第二，目前來說，開源的時代來說各個產(chǎn)品都有其側重點，各個產(chǎn)品都會相互借鑒，如果說某一個產(chǎn)品全面優(yōu)于另外一個產(chǎn)品，另外一個產(chǎn)品自然就會被淘汰掉。

Greenplum對OLTP的支持程度

Q：Greenplum是專門對OLAP來設計的，但是其實現(xiàn)實的環(huán)境中，用戶既有OLAP又有OLTP類型的需求，在新的版本中Greenplum對OLTP的支持有沒有提升，大概是多少。

吳疆：在6.0的版本中，對OLTP的支持提升了非常多，目前實測結果是100倍，并且之前的表鎖目前被拆分成了行鎖，性能會有非常大的提升。

Oceanbase和PolarDB的優(yōu)劣

最后的一個問題也很“勁爆”，聽眾直接提問絳云。

Q：在阿里里面Oceanbase和PolarDB的定位和優(yōu)劣勢，性能到底誰比較強。

絳云：首先，這兩種分布式數(shù)據(jù)庫的架構不同，Oceanbase是share noting的，而PolarDB是share everything的，兩者的定位會有所區(qū)別;性能方面，因為兩個都是公司的產(chǎn)品，只能說性能都不相伯仲。

問卷調(diào)查及抽獎

論壇的最后有兩位現(xiàn)場的幸運聽眾抽到了PlanetScale從美國帶過來的UBL Speaker，提問的和現(xiàn)場的朋友也拿到了Vitess的T恤，并參與了問卷調(diào)查。

從問卷調(diào)查的結果來說，阿里、騰訊等的分布式數(shù)據(jù)庫的呼聲最高，而丁奇、彭立勛、何登成、梁飛龍等大神的分享也最讓人期待。

讓我們繼續(xù)期待下一場分布式數(shù)據(jù)庫技術論壇的盛宴!

公眾號搜索“沃趣技術”，關注并在后臺回復“技術論壇”，戳鏈接即可領取嘉賓分享PPT。

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內(nèi)容或斷開相關鏈接。