今天參加了OceanBase開(kāi)發(fā)者大會(huì)DevCon，還是有蠻多的收獲的，整篇文章我分為兩個(gè)部分。第一部分是會(huì)議的議程情況，讓沒(méi)有參加的同學(xué)可以有一個(gè)簡(jiǎn)單的了解，第二部分是我個(gè)人對(duì)于一些問(wèn)題的思考，均是個(gè)人觀點(diǎn)。

第一部分：

疫情以來(lái)，這算是我第一次正式參加的一個(gè)技術(shù)大會(huì)了。

簽到后在二樓有一面很有新意的技術(shù)墻，都是用樂(lè)高一樣的小塊拼接而成的。

早上的議程還是比較滿的，比較期待的是陽(yáng)振坤老師的第一個(gè)分享《我眼中的數(shù)據(jù)庫(kù)技術(shù)》。

依然還記得上一次陽(yáng)老師在去年發(fā)布小魚4.0版本時(shí)對(duì)于數(shù)據(jù)庫(kù)的熱愛(ài)和真誠(chéng)。

華東師范大學(xué)周校長(zhǎng)分享的《未來(lái)，中國(guó)需要什么樣的數(shù)據(jù)庫(kù)？》

Keith Chan分享的《云原生技術(shù)趨勢(shì)解讀》

日照分享的《打造開(kāi)發(fā)者友好的分布式數(shù)據(jù)庫(kù)》，這一頁(yè)是精華部分。

在這次大會(huì)上也公布了四項(xiàng)“開(kāi)發(fā)者友好”實(shí)踐，包括4.1版本發(fā)布，升級(jí)工具，場(chǎng)景化文檔和統(tǒng)一企業(yè)版和社區(qū)版代碼分支。

我參加了現(xiàn)場(chǎng)圓桌對(duì)話的部分，討論了單機(jī)-分布式一體化架構(gòu)、研發(fā)關(guān)注的數(shù)據(jù)庫(kù)、HTAP數(shù)據(jù)庫(kù)討論。

這個(gè)環(huán)節(jié)還是很有新意的，在數(shù)據(jù)庫(kù)大賽中邀請(qǐng)了獲獎(jiǎng)同學(xué)，他們來(lái)自國(guó)內(nèi)知名高校，都是未來(lái)數(shù)據(jù)庫(kù)方向的人才。

第二部分：個(gè)人的一些感受，我分為4個(gè)問(wèn)題來(lái)展開(kāi)討論。

問(wèn)題1：關(guān)于數(shù)據(jù)庫(kù)近些年來(lái)的變化情況

這里我就不具體討論數(shù)據(jù)庫(kù)的發(fā)展趨勢(shì)了，我補(bǔ)充一些我觀察到和我感受到的信息。?

1）目前數(shù)據(jù)庫(kù)在垂直細(xì)分領(lǐng)域的變化越來(lái)越快，隨著業(yè)務(wù)需求的多樣化，數(shù)據(jù)庫(kù)的多品類支持，原本大數(shù)據(jù)4V模式下，數(shù)據(jù)規(guī)模增長(zhǎng)這個(gè)維度的問(wèn)題使用分布式數(shù)據(jù)庫(kù)是一個(gè)很好的切入點(diǎn)，在另外3個(gè)維度也是這些年有一定發(fā)展的新型數(shù)據(jù)庫(kù)體系，比如圖數(shù)據(jù)庫(kù)，眾包數(shù)據(jù)庫(kù)等。?

2）業(yè)務(wù)模型簡(jiǎn)化，這些年來(lái)可以明顯感受到研發(fā)的業(yè)務(wù)模型設(shè)計(jì)會(huì)趨向于簡(jiǎn)化，一個(gè)直觀的感受就是業(yè)務(wù)邏輯中很少能夠看到存儲(chǔ)過(guò)程，這對(duì)于分布式數(shù)據(jù)庫(kù)的發(fā)展有大有幫助，減輕了原有的一些包袱。

3）打破邊界。比如Oracle數(shù)據(jù)庫(kù)在2018年左右就提出了自治數(shù)據(jù)庫(kù)的概念，這個(gè)概念已經(jīng)打破了原本DBA的邊界，是一種巨大的挑戰(zhàn)；智能運(yùn)維這個(gè)體系已經(jīng)不光覆蓋數(shù)據(jù)庫(kù)方向，在運(yùn)維體系中都開(kāi)始有了場(chǎng)景化的落地；單機(jī)-分布式架構(gòu)一體化，這個(gè)概念是蠻顛覆原有的生態(tài)體系的。

4）對(duì)于數(shù)據(jù)庫(kù)穩(wěn)定性和性能的追求有一些模糊，可以看到現(xiàn)在國(guó)產(chǎn)化數(shù)據(jù)庫(kù)發(fā)展也很快，有時(shí)候面對(duì)大量數(shù)據(jù)庫(kù)時(shí)，研發(fā)和DBA都會(huì)有一種茫然，換句話說(shuō)，我們有時(shí)候也不知道自己需要什么，而數(shù)據(jù)庫(kù)的穩(wěn)定性和性能是很核心的關(guān)注點(diǎn)，我們這些被更豐富的功能和更好的用戶體驗(yàn)占據(jù)了心智。

問(wèn)題2：如何看待OB,你是否會(huì)將OB作為選型參考

對(duì)于這個(gè)問(wèn)題我是相對(duì)開(kāi)放的，有幾點(diǎn)供參考。?

1）首先我看重的是數(shù)據(jù)庫(kù)生態(tài)，這個(gè)數(shù)據(jù)庫(kù)生態(tài)不光是包括SQL數(shù)據(jù)庫(kù)技術(shù)棧，NoSQL數(shù)據(jù)庫(kù)技術(shù)棧，還包括大數(shù)據(jù)等。我是需要在數(shù)據(jù)資源體系去看待這個(gè)事情。那么是否引入OB,是否考慮，對(duì)我來(lái)說(shuō)，現(xiàn)在的MySQL技術(shù)棧已經(jīng)遠(yuǎn)不是原本的主從標(biāo)準(zhǔn)版模式了，我們已經(jīng)通過(guò)MySQL協(xié)議兼容的方式引入了多種數(shù)據(jù)庫(kù)技術(shù)，所以具備了基礎(chǔ)兼容性的基礎(chǔ)上，我覺(jué)得對(duì)于研發(fā)沒(méi)有額外的接入成本，那么我需要考慮的就是這個(gè)產(chǎn)品本身是否匹配業(yè)務(wù)需求。

2）資源性價(jià)比，自從OB 4.0版本發(fā)布之后，我是比較關(guān)注的，因?yàn)榈团浒娴哪Ｊ绞欠衔覍?duì)于MySQL技術(shù)棧純PC路線的規(guī)劃的，這也算是打開(kāi)了一個(gè)口子，可以讓原本的資源接入和配置管理部會(huì)有明顯的變化，但是如果性能收益更高，接入的動(dòng)力會(huì)更高。?

3）資源布局，對(duì)于數(shù)據(jù)庫(kù)的整體布局，我有自己的一些認(rèn)知和思考。大體來(lái)說(shuō)，在私有云方向我是按照6:4（標(biāo)準(zhǔn)版集群和分布式集群的配比），對(duì)于公有云體系配比是8:2(RDS和云原生數(shù)據(jù)庫(kù)）甚至9:1

4）業(yè)務(wù)對(duì)于數(shù)據(jù)庫(kù)的在線遷移能力是很關(guān)注的，我們近期會(huì)發(fā)布的一個(gè)調(diào)研報(bào)告中能夠探查到業(yè)務(wù)對(duì)于在線遷移的可容忍停機(jī)時(shí)間60%以上在2個(gè)小時(shí)以內(nèi)，這就需要在數(shù)據(jù)庫(kù)生態(tài)工具如遷移工具等方面具備一定的支持。?

5）多集群融合，數(shù)據(jù)庫(kù)集群技術(shù)是各有優(yōu)劣，至少在不同的業(yè)務(wù)場(chǎng)景下存在即合理，共存本身也說(shuō)明了技術(shù)棧之間的一種動(dòng)態(tài)平衡情況。比如NewSQL,中間件集群，OB等，我是希望通過(guò)一些異步的數(shù)據(jù)同步實(shí)現(xiàn)集群在特定業(yè)務(wù)場(chǎng)景中的互補(bǔ)，所以從這個(gè)視角，我可能又多了一個(gè)選擇，而不是負(fù)擔(dān)。

問(wèn)題3：關(guān)于HTAP的一些感受和想法

HTAP是這些年來(lái)比較火的概念，從我的認(rèn)知來(lái)看，我覺(jué)得技術(shù)方向分久必合，合久必分，HTAP也是應(yīng)運(yùn)而生，是一種很自然的演進(jìn)，或者說(shuō)重新定義。?

其中的焦點(diǎn)主要在OLAP方向，從系統(tǒng)視角來(lái)看待，可以通過(guò)空間換時(shí)間來(lái)實(shí)現(xiàn)，換另外一種思路OLAP的需求其實(shí)是不追求數(shù)據(jù)庫(kù)的精確性的，它和OLTP對(duì)于數(shù)據(jù)的準(zhǔn)確性是有顯著差別的。?從算力視角來(lái)看，主要追求的是快，但是這個(gè)快會(huì)存在一些歧義，都是快，但是意義不同。比如執(zhí)行部分本身就有時(shí)間消耗，可能從3秒到1秒也是很大的提升；對(duì)于OLTP我們可能追求的是毫秒級(jí)的延遲，而在OLAP中可能是秒級(jí)甚至更大一些；對(duì)于數(shù)據(jù)庫(kù)的準(zhǔn)確性，T+1的需求是一種相對(duì)固化的需求，OLAP在追求實(shí)時(shí)性方面本質(zhì)不是準(zhǔn)確性需求，僅僅是將近實(shí)時(shí)的數(shù)據(jù)作為一種參考依據(jù)。

HTAP在我的理解中，主要有三類實(shí)現(xiàn)模式。

第一種思路是像Oracle ,SQLServer這種本身單機(jī)性能就很不錯(cuò)的數(shù)據(jù)庫(kù)，因?yàn)樽陨硇阅軓?qiáng)大，所以可以自動(dòng)適配OLAP的部分需求。

第二種思路是以O(shè)LTP為主，輔助OLAP的支持能力，其中的設(shè)計(jì)點(diǎn)主要在于資源隔離，這就帶來(lái)了兩面性，一方面是因?yàn)樾枰挥绊慜LTP而需要做資源隔離，另一方面則是因?yàn)楠?dú)立的數(shù)據(jù)副本維護(hù)帶來(lái)的復(fù)雜度，如果這個(gè)問(wèn)題能夠找到一個(gè)平衡點(diǎn)，也是一種創(chuàng)新。?

第三類思路是以O(shè)LAP作為切入點(diǎn)，如果OLAP足夠強(qiáng)大，同時(shí)有深厚的OLTP底子，這種演進(jìn)方式是一種降維打擊。比如探索性業(yè)務(wù)，業(yè)務(wù)模型復(fù)雜多變，如果在OLAP支持方面有明顯的優(yōu)勢(shì)，那么可以很自然的把OLTP的業(yè)務(wù)整合集成起來(lái)；另外一類則是OLAP的需求是強(qiáng)需求，如果通過(guò)硬件資源優(yōu)化就能夠解決，或者說(shuō)現(xiàn)在的OLAP方式支持在低配的情況下也有很大的提升，那么這個(gè)事情的性價(jià)比還不錯(cuò)。

問(wèn)題4：對(duì)于研發(fā)和DBA同學(xué)的一些學(xué)習(xí)建議

對(duì)于研發(fā)同學(xué)和DBA同學(xué)的一些通用建議，可能還是老三篇，沒(méi)有什么新意，不過(guò)這幾樣堅(jiān)持下來(lái)我相信是又收獲的。

1）多總結(jié)。好記性不如爛筆頭，手底下不能偷懶。多總結(jié)成案例，讓自己看到問(wèn)題就能夠完整的回放整個(gè)問(wèn)題處理過(guò)程。

2）建立自己的知識(shí)體系，不要把攻略當(dāng)法寶。建立自己的知識(shí)體系尤其重要，你處理的問(wèn)題多了就有了更多的感悟，可能存在的一個(gè)誤區(qū)是我們可能解決了一個(gè)問(wèn)題之后，會(huì)得出錯(cuò)誤的結(jié)論，甚至從網(wǎng)絡(luò)中搜索得到的也是錯(cuò)誤的結(jié)果，那么你把這種攻略當(dāng)做法寶路就會(huì)很窄，不斷完善自己的知識(shí)體系，就會(huì)不斷找到自己的邊界。?

3）社區(qū)連接，多參加一些社區(qū)的互動(dòng)，有精力和能力多做一些技術(shù)分享，多參加一些活動(dòng)，線下見(jiàn)見(jiàn)技術(shù)圈的朋友，總歸是有一些收獲的。