數(shù)據(jù)庫(kù)選型越來越難，據(jù)DB-Engines數(shù)據(jù)庫(kù)流行度排行榜顯示，目前全球有多達(dá)359個(gè)開源和商業(yè)的數(shù)據(jù)庫(kù)。

從應(yīng)用類型看，有OLTP事務(wù)型數(shù)據(jù)庫(kù)，有OLAP分析型數(shù)據(jù)庫(kù)，還有HTAP混合型數(shù)據(jù)庫(kù)。

從存儲(chǔ)方式看，有關(guān)系型數(shù)據(jù)庫(kù)和非關(guān)系型數(shù)據(jù)庫(kù)(NoSQL)之分。而NoSQL數(shù)據(jù)庫(kù)又依據(jù)支持的數(shù)據(jù)模型不同，分為鍵值數(shù)據(jù)庫(kù)、文檔數(shù)據(jù)庫(kù)，列式數(shù)據(jù)庫(kù)，圖形數(shù)據(jù)庫(kù)等。

如果從架構(gòu)類型看，又分Share Everything、Share Storage、Share Nothing。

數(shù)據(jù)庫(kù)市場(chǎng)百花齊放雖然給企業(yè)帶來了更多選擇，但也導(dǎo)致選型變得更加困難。

專用 VS 多模

關(guān)于專用數(shù)據(jù)庫(kù)與多模數(shù)據(jù)庫(kù)之爭(zhēng)，由來已久。其中，AWS屬于專用數(shù)據(jù)庫(kù)派，認(rèn)為數(shù)據(jù)庫(kù)就應(yīng)該像汽車一樣，不同的汽車解決不同的運(yùn)輸需求，不同數(shù)據(jù)庫(kù)去解決不同場(chǎng)景需求，而不是通過關(guān)系數(shù)據(jù)庫(kù)來一刀切。

因此，AWS提供的數(shù)據(jù)庫(kù)產(chǎn)品組合多達(dá)十幾種。

AWS 數(shù)據(jù)庫(kù)服務(wù)一覽圖

而甲骨文、微軟、SAP則屬于“瑞士軍刀”派，即多模數(shù)據(jù)庫(kù)派。通過擴(kuò)展其SQL查詢功能或添加功能(如R或Python支持)來實(shí)現(xiàn)多模功能。

去年，DeveloperWeek一組調(diào)查數(shù)據(jù)顯示。有將近一半受訪者實(shí)際上使用了不止一種數(shù)據(jù)庫(kù)來支持其業(yè)務(wù)應(yīng)用程序，而不是單個(gè)數(shù)據(jù)庫(kù)!使用多個(gè)數(shù)據(jù)庫(kù)的比例為44.3%，使用一個(gè)數(shù)據(jù)庫(kù)的比例為55.7%。雖然看起來使用一個(gè)數(shù)據(jù)庫(kù)的比例還是更多，但不能忽略一點(diǎn)，多數(shù)據(jù)庫(kù)的使用在過去10年出現(xiàn)了爆炸式增長(zhǎng)。

數(shù)據(jù)顯示，75.6%的多數(shù)據(jù)庫(kù)類型組合使用了SQL和NoSQL數(shù)據(jù)庫(kù)。這進(jìn)一步說明，對(duì)于許多企業(yè)來說，并不能一刀切。

圖片及數(shù)據(jù)來源：ScaleGrid

顯然，數(shù)據(jù)格式、應(yīng)用場(chǎng)景紛繁復(fù)雜，很多需求已經(jīng)不是單一數(shù)據(jù)庫(kù)能解決的。同時(shí)，微服務(wù)架構(gòu)的崛起，也在推動(dòng)企業(yè)不同業(yè)務(wù)場(chǎng)景采用不同的數(shù)據(jù)庫(kù)，如果選擇不當(dāng)，會(huì)導(dǎo)致服務(wù)的性能上不去。

因此，選型時(shí)不要將企業(yè)的數(shù)據(jù)庫(kù)限制在一種數(shù)據(jù)庫(kù)上，相互補(bǔ)充才能填補(bǔ)數(shù)據(jù)庫(kù)需求的空白。

選型要點(diǎn)

1. 業(yè)務(wù)場(chǎng)景

任何脫離業(yè)務(wù)場(chǎng)景需求的數(shù)據(jù)庫(kù)選型都是耍流氓。

數(shù)據(jù)庫(kù)選型的決定性因素是結(jié)合業(yè)務(wù)應(yīng)用場(chǎng)景，分析目前已有的需求和未來可能會(huì)出現(xiàn)的新需求，來考量選擇何種數(shù)據(jù)庫(kù)。

業(yè)務(wù)用數(shù)據(jù)庫(kù)來做什么?分析還是交易?或者兩者兼而有之?業(yè)務(wù)要處理什么樣的數(shù)據(jù)?對(duì)數(shù)據(jù)庫(kù)性能需求是什么?

如果是傳統(tǒng)的ERP、CRM、財(cái)務(wù)等企業(yè)內(nèi)部應(yīng)用，需要事務(wù)完整性，保證ACID事務(wù)，那么，毫無疑問，關(guān)系型數(shù)據(jù)庫(kù)是最佳選擇。如果業(yè)務(wù)要做物聯(lián)網(wǎng)數(shù)據(jù)采集和監(jiān)控，需要高頻、實(shí)時(shí)、持續(xù)的寫入，那么，時(shí)序數(shù)據(jù)庫(kù)是正確的選擇。

業(yè)務(wù)要處理什么樣的數(shù)據(jù)?結(jié)構(gòu)化?半結(jié)構(gòu)化?非結(jié)構(gòu)化數(shù)據(jù)?決定需要支持的數(shù)據(jù)模型。原則上“什么數(shù)據(jù)模型，就用什么庫(kù)。”

如果你要存儲(chǔ)和處理的是圖片、音頻、視頻等非結(jié)構(gòu)化數(shù)據(jù)，那么，NoSQL數(shù)據(jù)庫(kù)會(huì)是最佳選擇。進(jìn)一步來說，業(yè)務(wù)要存儲(chǔ)游戲場(chǎng)景中的角色信息、經(jīng)驗(yàn)道具信息、好友排名等信息，而這些信息一般都和 ID(鍵)掛鉤，那么，鍵值數(shù)據(jù)庫(kù)是個(gè)很好的選擇。

業(yè)務(wù)需要處理的多大的數(shù)據(jù)規(guī)模、并發(fā)吞吐量、響應(yīng)時(shí)間需求是什么?決定了對(duì)數(shù)據(jù)庫(kù)的性能需求。

如果業(yè)務(wù)是秒殺，春節(jié)火車票等，有超高峰值業(yè)務(wù)，那么，分布式數(shù)據(jù)庫(kù)會(huì)是一個(gè)不錯(cuò)的選擇。

常見的數(shù)據(jù)類型和應(yīng)用場(chǎng)景(圖片來源：AWS)

不清楚什么業(yè)務(wù)場(chǎng)景下應(yīng)該選用哪種數(shù)據(jù)庫(kù)系統(tǒng)的，可以參考上圖。

2. 可運(yùn)維性

有種說法，數(shù)據(jù)庫(kù)選型不考慮可運(yùn)維性的都應(yīng)該槍斃。雖然說法夸張，但也有其道理，畢竟，數(shù)據(jù)庫(kù)買來最后是DBA來運(yùn)維，DBA的意見不能忽視。

自身團(tuán)隊(duì)技術(shù)儲(chǔ)備如何?選型要考慮現(xiàn)有開發(fā)、運(yùn)維人員的技能，盡量選擇學(xué)習(xí)曲線短的。

數(shù)據(jù)庫(kù)選型，很多人會(huì)忽略生態(tài)，一個(gè)好的數(shù)據(jù)庫(kù)不僅自身強(qiáng)大，周邊生態(tài)完善很重要。與周邊上下游產(chǎn)品的兼容性，配套軟件、工具、技術(shù)人才等都對(duì)可運(yùn)維性產(chǎn)生極大影響。

每一種數(shù)據(jù)庫(kù)都不簡(jiǎn)單，掌握都需要一個(gè)過程。數(shù)據(jù)庫(kù)發(fā)生問題，如何快速定位并解決問題?如果有個(gè)活躍的用戶社區(qū)，DBA會(huì)有信心很多。

如果選擇了一種數(shù)據(jù)庫(kù)，但招不到DBA，一旦人員流失，讓數(shù)據(jù)庫(kù)處于無人維護(hù)的境地，那也挺要命的。

良好的工具生態(tài)可以節(jié)省企業(yè)的開發(fā)及運(yùn)維人員投入。例如：遷移工具，AWS DMS早在2016年3月就已推出，可以讓用戶輕松地將其數(shù)據(jù)庫(kù)遷移過來，同時(shí)避免停機(jī)。事實(shí)證明該服務(wù)很受歡迎，AWS官方數(shù)據(jù)顯示，截止到目前，DMS已經(jīng)幫助20萬個(gè)數(shù)據(jù)庫(kù)進(jìn)行遷移。

如果你選擇的是云數(shù)據(jù)庫(kù)，那么，有Serverless(無服務(wù)器)模式的云數(shù)據(jù)庫(kù)會(huì)讓運(yùn)維更輕松，以AWS為例，Amazon Aurora Serverless,Amazon DynamoDB,Amazon TimeStream,Amazon Keyspaces,這些都是無服務(wù)器版本的數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)可以根應(yīng)用程序需求來自動(dòng)啟動(dòng)、關(guān)閉以及擴(kuò)展或縮減，而無需管理任何數(shù)據(jù)庫(kù)實(shí)例，能極大降低數(shù)據(jù)庫(kù)管理的工作量。因?yàn)椋謩?dòng)管理數(shù)據(jù)庫(kù)容量需要占用寶貴的時(shí)間，也可能導(dǎo)致數(shù)據(jù)庫(kù)資源的使用效率低下。

3. 成本

數(shù)據(jù)庫(kù)選型不僅要考慮部署數(shù)據(jù)庫(kù)的硬件資源成本、軟件成本、服務(wù)成本和人力成本，還要考慮隱形的成本，比如遷移成本、維護(hù)成本、學(xué)習(xí)成本，運(yùn)營(yíng)成本等。

隨著開源數(shù)據(jù)庫(kù)的流行，存在一種選型誤區(qū)，認(rèn)為開源數(shù)據(jù)庫(kù)省錢。其實(shí)，開源數(shù)據(jù)庫(kù)未必就比商業(yè)數(shù)據(jù)庫(kù)成本低，雖然沒有License費(fèi)用，但對(duì)技術(shù)團(tuán)隊(duì)要求很高，對(duì)于一般傳統(tǒng)行業(yè)是玩不轉(zhuǎn)的，如果你的技術(shù)團(tuán)隊(duì)不具備這種能力，還不如商用數(shù)據(jù)庫(kù)更省心甚至省錢。

如果想在兩者中取得平衡，那么，一些結(jié)合了新技術(shù)新硬件的新興數(shù)據(jù)庫(kù)可能是不錯(cuò)的選擇。比如：AWS Aurora，既兼容主流的開源數(shù)據(jù)庫(kù)MySQL和PostgreSQL，又具備商業(yè)數(shù)據(jù)庫(kù)的性能優(yōu)勢(shì)。用大白話說，就是既能省錢，性能又要優(yōu)于開源數(shù)據(jù)庫(kù)。

分布式數(shù)據(jù)庫(kù)雖然很火，但也不要盲目趕時(shí)髦，要用對(duì)地方，要清楚什么場(chǎng)景適合分布式數(shù)據(jù)庫(kù)，什么場(chǎng)景不適合，否則，不僅達(dá)不到預(yù)期效果還更費(fèi)錢。

寫在最后

雖然，數(shù)據(jù)庫(kù)領(lǐng)域各種新技術(shù)新概念不斷涌現(xiàn)，但還談不上誰替代誰。

目前，沒有萬能的數(shù)據(jù)庫(kù)，只有最合適的數(shù)據(jù)庫(kù)。數(shù)據(jù)庫(kù)選型還是要根據(jù)業(yè)務(wù)需求來選擇最合適的產(chǎn)品，切勿盲目趕時(shí)髦，去追新求熱。