概要

1、從職業(yè)發(fā)展看選型

2、選型原則一二三

3、選型路線圖

本次分享主要有三個(gè)大的方向，一是從職業(yè)規(guī)劃的角度看為什么我會(huì)認(rèn)為數(shù)據(jù)庫(kù)選型很重要，第二個(gè)方向會(huì)根據(jù)這些經(jīng)驗(yàn)說說選型的基本原則是什么，最后總結(jié)一下這些年數(shù)據(jù)庫(kù)選型的路線圖，希望能對(duì)大家以后做數(shù)據(jù)庫(kù)選型時(shí)有幫助，可以根據(jù)你們公司的場(chǎng)景進(jìn)行套用，當(dāng)然這不一定適合所有場(chǎng)景，主要還是提供思路以方便大家借鑒。

一、從職業(yè)發(fā)展看選型

DBA這個(gè)行業(yè)有很多年了，隨著時(shí)間的變化職業(yè)規(guī)劃也有著不同的變化。我放了一張DB-Engine的圖，這是DB的排名，前三的就不說了，老三位沒什么可聊的。但是看下面的排名，除了常見的數(shù)據(jù)庫(kù)，還有ES、HBase、Neo4j這些我們之前不太認(rèn)為是DBA管理范疇內(nèi)的DB。

我經(jīng)常跟團(tuán)隊(duì)小伙伴說咱們DBA的思維不要光局限于前面的老三位或者TOP5，我們是不是可以考慮到更多的數(shù)據(jù)庫(kù)也是DBA可以從事的行業(yè)。比如你可不可以做HBase?你可不可以管理ES?這些東西都體現(xiàn)在這張表里，我們可以擴(kuò)展自己職業(yè)的領(lǐng)域，這也是職業(yè)發(fā)展方向的一種橫向擴(kuò)展方式。

這張圖是我對(duì)比去年和今年變化的展示圖，去年關(guān)系型數(shù)據(jù)庫(kù)(藍(lán)色部分)占了半壁江山，今年關(guān)系型數(shù)據(jù)庫(kù)仍然是第一，但是已經(jīng)有很多份額被多用途的數(shù)據(jù)庫(kù)占去了。

多用途數(shù)據(jù)庫(kù)是廠商選擇的趨勢(shì)，他們研發(fā)了越來越多支持多用途的數(shù)據(jù)庫(kù)。廠商為什么會(huì)這么做?供給側(cè)的改變來源于需求側(cè)，因?yàn)橛泻芏嘈枨笠呀?jīng)不是單一的數(shù)據(jù)庫(kù)能解決的了。

在這種場(chǎng)景下，廠商迫于這種需求開發(fā)了很多能適應(yīng)更多場(chǎng)景的數(shù)據(jù)庫(kù)。這種趨勢(shì)對(duì)DBA來說意味著什么?這提醒我們，對(duì)多種數(shù)據(jù)庫(kù)的掌握是現(xiàn)在這個(gè)時(shí)代對(duì)DBA的要求。

這是一個(gè)必然的發(fā)展趨勢(shì)，因?yàn)槟阋鉀Q的場(chǎng)景會(huì)越來越多，你需要掌握的數(shù)據(jù)庫(kù)領(lǐng)域也越來越廣，這就意味著之前「一招鮮」的玩法已經(jīng)落伍了。

我們?cè)倏船F(xiàn)在崗位的設(shè)置，往前其實(shí)是純自建時(shí)代，現(xiàn)在的時(shí)代是云時(shí)代，這兩個(gè)時(shí)代有著本質(zhì)的區(qū)別。

自建時(shí)代的DBA更多意義上是運(yùn)維領(lǐng)域區(qū)分出來的一個(gè)更專業(yè)、門檻更高的職業(yè)領(lǐng)域，再往前都沒有DBA，都是Ops管理的。后來出現(xiàn)DBA，再慢慢演化到DBA做一些細(xì)分，出現(xiàn)了開發(fā)DBA、內(nèi)核DBA，還有部分同學(xué)轉(zhuǎn)去專門做大數(shù)據(jù)，這就是在自建時(shí)代的整個(gè)狀態(tài)。

但是云時(shí)代會(huì)有一些什么樣的變化呢?其實(shí)自建時(shí)代的傳統(tǒng)DBA現(xiàn)在還存在，因?yàn)橛谢旌显频拇嬖凇Ｄ敲醋兓鞘裁?是無(wú)論如何都不可能完全不談云，一旦上云，自有的運(yùn)維體系受到?jīng)_擊是其次，主要還是業(yè)務(wù)可以選擇的服務(wù)就多起來了。之前由于基礎(chǔ)設(shè)施導(dǎo)致需要業(yè)務(wù)適配數(shù)據(jù)庫(kù)的情況就會(huì)變成需要DBA掌握更多的數(shù)據(jù)庫(kù)類型來滿足業(yè)務(wù)了。

更有甚者是有的公司已經(jīng)全部上云了，之前賴以生存的工作都變成了云服務(wù)，這時(shí)候的DBA要做什么轉(zhuǎn)變?最后還有一種變化是云內(nèi)DBA，作為云公司的DBA，孵化一個(gè)產(chǎn)品和提供對(duì)內(nèi)服務(wù)又完全不是一回事。未來基本上我認(rèn)為DBA就是這三個(gè)領(lǐng)域里面打轉(zhuǎn)了(混合云DBA、云上DBA和云內(nèi)DBA)，但是無(wú)論哪種都需要掌握更多的數(shù)據(jù)庫(kù)，這個(gè)是不變的。

綜上，這個(gè)時(shí)代對(duì)DBA的要求就是需要掌握的數(shù)據(jù)庫(kù)領(lǐng)域越來越多的，甭管你是在哪個(gè)線上的，都需要懂很多領(lǐng)域，至少精通一種，掌握N多種，這是我這次演講想傳遞給大家的一個(gè)概念。

二、選型原則一二三

原則1：不講場(chǎng)景的選型都是耍流氓

在座做過數(shù)據(jù)庫(kù)選型相關(guān)工作的都知道場(chǎng)景很重要，但不是所有人都能把這個(gè)概念深入到骨子里。比如這個(gè)場(chǎng)景，我相信大家應(yīng)該都有實(shí)際經(jīng)歷過。

你的用戶對(duì)數(shù)據(jù)庫(kù)的了解是沒有DBA熟的，他的出發(fā)點(diǎn)跟你的出發(fā)點(diǎn)是不一樣的，你想要的是長(zhǎng)治久安，他想要的是把功能搞定。

如果你要做業(yè)務(wù)選型一定要對(duì)場(chǎng)景進(jìn)行劃分，如日志類、搜索類、離線需求等等，這些全部要跟線上分別開。業(yè)務(wù)模型是怎么樣的?活動(dòng)型還是規(guī)律型的，你是多讀還是寫多的?然后數(shù)據(jù)增長(zhǎng)方式是怎樣的，不能光滿足上線一剎那的需求，業(yè)務(wù)增長(zhǎng)是日期型的還是用戶型的、位置型的?這些都需要跟你和業(yè)務(wù)聊清楚了，如果問不清楚，后期就面臨一個(gè)最嚴(yán)重的問題：數(shù)據(jù)遷移。而數(shù)據(jù)遷移本身就可以成為一個(gè)主題，這就意味著這個(gè)事情會(huì)花費(fèi)巨大的成本，如果能從初期就避免掉盡量從初期避免。

原則2：沒有數(shù)據(jù)就沒得聊

沒法度量的東西就沒法管，放在數(shù)據(jù)領(lǐng)域一樣，沒有數(shù)據(jù)就沒法談。

這是一個(gè)場(chǎng)景，你找業(yè)務(wù)聊天的時(shí)候一問三不知，經(jīng)常會(huì)遇到，業(yè)務(wù)也確實(shí)沒有辦法。但我想說的是我們一定要讓業(yè)務(wù)方拍出來的一個(gè)數(shù)據(jù)，因?yàn)槲覀兯械臎Q策都是基于這些數(shù)據(jù)的，沒有數(shù)據(jù)就沒法決策。

另外也期望可以讓整個(gè)業(yè)務(wù)鏈條的同學(xué)養(yǎng)成有數(shù)據(jù)的習(xí)慣，評(píng)估多了自然就能積攢下來一些方法論來解決「拍數(shù)」的問題。這其中關(guān)鍵的幾個(gè)點(diǎn)，也是最后選型圖上關(guān)鍵的點(diǎn)，一個(gè)是size，第二個(gè)是qps，還有一個(gè)是rt。

另外我們還需要提供一些基準(zhǔn)數(shù)據(jù)。什么叫基準(zhǔn)數(shù)據(jù)，像剛才那個(gè)場(chǎng)景，你問業(yè)務(wù)，他一問三不知，還有一種情況是業(yè)務(wù)問你MySQL能扛多久，你說我也不知道，咱們先跑再說，這肯定是不行的。

你如果管理一個(gè)類型的數(shù)據(jù)庫(kù)一定要對(duì)自己的東西有一個(gè)非?；鶞?zhǔn)的認(rèn)知，這個(gè)場(chǎng)景來了，我是給他做一主兩從還是分布式，要不要上來就千庫(kù)萬(wàn)表，還是用分區(qū)表等等，這些都一定要門清的。

最后有一個(gè)tips，評(píng)估是可以類比，只要邏輯說得通就行。來了一個(gè)需求你也說不清楚到底是多大量，你就看之前這個(gè)部門做沒做過類似的活動(dòng)，是在什么時(shí)間點(diǎn)做的，它跟你這個(gè)是什么樣的邏輯，是否是近似的邏輯，如果是近似的邏輯我們就往上套。比如上次熱點(diǎn)事件的峰值是多少，如果這個(gè)產(chǎn)品功能也可能和熱點(diǎn)頁(yè)面相關(guān)聯(lián)，那么就按照上次熱點(diǎn)事件的峰值進(jìn)行對(duì)應(yīng)的預(yù)估也算是符合邏輯的。

這里給大家展示一下基準(zhǔn)測(cè)試，這是我們?cè)谧龌旌显七\(yùn)維解決方案時(shí)做的測(cè)試，因?yàn)槲覀冃枰枚嗉覐S商的數(shù)據(jù)，需要門兒清，我把這個(gè)服務(wù)部署到那家云上性能到底有什么樣的波動(dòng)，也方便業(yè)務(wù)方對(duì)業(yè)務(wù)有更直觀的理解和認(rèn)知。

原則3：不考慮可運(yùn)維性的都應(yīng)該槍斃

最后一個(gè)原則跟前兩個(gè)區(qū)別比較大，前兩個(gè)原則基本都是知道的，但是難在落地。第三個(gè)原則其實(shí)很多DBA也不太關(guān)注，但真的是很重要的一個(gè)原則，那就是可運(yùn)維性。

我開始說了，DBA跟業(yè)務(wù)方評(píng)估不一樣，你的KPI也不一樣，需求的點(diǎn)也不一樣，業(yè)務(wù)要求上線，你要求可運(yùn)維性，這關(guān)系到你的幸福度，關(guān)系到你的起夜率。如圖的這個(gè)例子就很經(jīng)典，業(yè)務(wù)和DBA雙方根本沒有在一個(gè)頻道上溝通，最后只可能是不歡而散。

我認(rèn)為的可運(yùn)維性是什么?有四個(gè)方面：

一個(gè)是社區(qū)活躍度，社區(qū)活躍度決定著你獲取信息的難易程度。獲得信息的難易程度決定了什么?關(guān)系到你出現(xiàn)了故障的定位速度甚至是能不能定位出來，如果社區(qū)很活躍，自然就能得到更多的幫助。

第二個(gè)是有沒有USER CASE，最好是自己認(rèn)識(shí)的人，因?yàn)檠垡姙閷?shí)，耳聽為虛，認(rèn)識(shí)的人往往能告訴你一些真實(shí)的「坑」，而不是宣傳用的「功能」。

第三個(gè)是自身團(tuán)隊(duì)的情況、上手成本。你這個(gè)團(tuán)隊(duì)有多大，團(tuán)隊(duì)具備了什么樣技術(shù)儲(chǔ)備?畢竟你開辟一個(gè)新的戰(zhàn)場(chǎng)，每一種數(shù)據(jù)庫(kù)都不是這么簡(jiǎn)單的，可能三四個(gè)人都不見的搞得定，但是實(shí)際業(yè)務(wù)到底使用多少卻說不清楚，這就很麻煩了。

最后一個(gè)是很隱性的事情，所謂的市場(chǎng)人才情況，這是可持續(xù)的成本。你如果選擇了一種數(shù)據(jù)庫(kù)，但如果市場(chǎng)對(duì)應(yīng)的人才很少，那么一旦出現(xiàn)人員流失，就會(huì)讓這種數(shù)據(jù)庫(kù)處于無(wú)人維護(hù)的情況，這對(duì)于公司來說是絕對(duì)不允許發(fā)生的事情。

三、選型路線圖

最后給大家聊一下選型路線圖，如果你沒有一個(gè)專門的DBA團(tuán)隊(duì)，云就是最好的選型，沒有了。至于這幾家之間他們到底誰(shuí)好，我認(rèn)為根據(jù)投資關(guān)系選更合適一點(diǎn)，至于原因你懂的。

再講講這個(gè)技術(shù)選型路線圖，這是我根據(jù)這么多年團(tuán)隊(duì)經(jīng)驗(yàn)做的一個(gè)選型路線圖：

首先一定要做場(chǎng)景分析，到底是線上業(yè)務(wù)、離線業(yè)務(wù)還是統(tǒng)計(jì)類業(yè)務(wù)必須分出來，如果是離線的那么走h(yuǎn)adoop生態(tài)，如果是統(tǒng)計(jì)監(jiān)控類的可以走專門的時(shí)序數(shù)據(jù)庫(kù)或者ES等，即使不走也要嚴(yán)格和線上的區(qū)分。

然后是線上，特殊需求走特殊的數(shù)據(jù)庫(kù)更合適，如果是一個(gè)純粹線上TOC端的產(chǎn)品需求，我們需要進(jìn)行QPS的判斷。如果是中低的QS那往下面走，根據(jù)size來判斷擴(kuò)展性，如果有高擴(kuò)展需求那么選目前比較火的分布式數(shù)據(jù)庫(kù)是個(gè)好選擇，如果不高，那么再往下看SQL復(fù)雜程度，一般簡(jiǎn)單的互聯(lián)網(wǎng)應(yīng)用MySQL足以，如果是用了很多存儲(chǔ)過程或者復(fù)雜大查詢的，那么PG更適合一些。

返回剛才的分叉，如果QPS高的話，那么基本就是kv數(shù)據(jù)庫(kù)的天下了，我們需要先根據(jù)size來判斷，如果可控那么純內(nèi)存的kv數(shù)據(jù)庫(kù)是最佳選擇。接下來是基于RT的判斷，如果size也大、rt要求也高，那就只有分布式內(nèi)存kv數(shù)據(jù)庫(kù)(RedisCluster)選，如果對(duì)于rt要求不那么高，那么Pika/Aerospike都是比較好的節(jié)省成本的選擇。

最后說一下我們目前的最佳實(shí)踐，我們目前常規(guī)需求都使用MySQL+Cache的方案解決，特殊需求交給云RDS去解決(比如PG、MongoDB等)，并且選擇了一種HTAP的分布式數(shù)據(jù)庫(kù)來解決擴(kuò)展性問題。

Q & A

Q：現(xiàn)在所謂的云原生DB比較流行，但是我們目前還沒有使用到。一些宣傳上說云原生DB是可以擴(kuò)展的，并且和傳統(tǒng)數(shù)據(jù)庫(kù)也是類似的，我想問一下對(duì)于傳統(tǒng)數(shù)據(jù)庫(kù)來說它的不足在哪里?

A：這個(gè)不足點(diǎn)就是它要求升高了，分布式數(shù)據(jù)庫(kù)的門檻變高了，對(duì)業(yè)務(wù)來說，在功能、擴(kuò)展性上它現(xiàn)在是全面是超過了傳統(tǒng)的數(shù)據(jù)庫(kù)。但是對(duì)于DBA的要求來說，有非常高的門檻，這對(duì)我們之前的問題分析、調(diào)優(yōu)、故障定位思路都會(huì)有很大的沖擊。

講師介紹

肖鵬，前新浪微博研發(fā)中心技術(shù)副總監(jiān)，主要負(fù)責(zé)微博數(shù)據(jù)庫(kù)(MySQL、Reids、HBase、Memcached)相關(guān)的業(yè)務(wù)保障、性能優(yōu)化、架構(gòu)設(shè)計(jì)，以及周邊的自動(dòng)化系統(tǒng)建設(shè)。經(jīng)歷了微博數(shù)據(jù)庫(kù)各個(gè)階段的架構(gòu)改造，包括服務(wù)保障及SLA體系建設(shè)、微博多機(jī)房部署、微博平臺(tái)化改造等項(xiàng)目。10年互聯(lián)網(wǎng)數(shù)據(jù)庫(kù)架構(gòu)和管理經(jīng)驗(yàn)，專注于數(shù)據(jù)庫(kù)的高性能和高可用技術(shù)保障方向。