分布式數(shù)據(jù)庫技術(shù)論壇

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

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

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

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

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

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

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

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

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

議題

Vitess：Stateful Storage on K8s

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

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

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

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

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

Pivotal的資深產(chǎn)品經(jīng)理吳疆介紹了他負(fù)責(zé)的其中一個產(chǎn)品Greenplum數(shù)據(jù)平臺。Greenplum 大數(shù)據(jù)平臺基于MPP(大規(guī)模并行處理)架構(gòu)，內(nèi)置并行存儲、并行通訊、并行計算和優(yōu)化技術(shù)，廣泛的應(yīng)用在金融、證券、電信各行各業(yè)。在最新的Gartner排名中，Greenplum在經(jīng)典數(shù)據(jù)分析領(lǐng)域排名第三位。Greenplum自2015年開源以來，2017年發(fā)布了全新的5.0版本，2019年中將發(fā)布6.0版本。本次分享結(jié)合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)架構(gòu)增強(qiáng)。Greenplum是基于大規(guī)模并行處理(massive parallel processing，MPP)架構(gòu)的數(shù)據(jù)平臺，在即將發(fā)布的6.0中，新增了若干MPP架構(gòu)增強(qiáng)的特性，例如復(fù)制表(replicated table)，在線擴(kuò)容，磁盤配額管理等

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

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

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

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

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

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

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

QFusion通過CSI標(biāo)準(zhǔn)接口支持多種存儲類型，利用Operator構(gòu)建數(shù)據(jù)庫應(yīng)用業(yè)務(wù)，從整體上介紹了怎么基于k8s構(gòu)建數(shù)據(jù)庫RDS服務(wù)的基本注意點(diǎn)。

圓桌會議及技術(shù)討論

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

Spanner和Vitess的取舍

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PolarDB相比Oracle的性能

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

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

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

Vitess和MyCat怎么競爭

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

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

Greenplum對OLTP的支持程度

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

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

Oceanbase和PolarDB的優(yōu)劣

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

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

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

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

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

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

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

公眾號搜索“沃趣技術(shù)”，關(guān)注并在后臺回復(fù)“技術(shù)論壇”，戳鏈接即可領(lǐng)取嘉賓分享PPT。

生成海報

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