最近總有朋友問我數(shù)據(jù)庫選型的問題，希望我寫幾篇文章闡述下我的觀點(diǎn)。寫這種文章是十分得罪友商的，所以在這方面我一向比較謹(jǐn)慎。不過有些話還是不吐不快，今天就講幾句吧。觀點(diǎn)只是個人的看法，并不一定正確，也沒有任何學(xué)術(shù)探討的意思。實(shí)際上數(shù)據(jù)庫應(yīng)用場景的復(fù)雜性決定了不同的用戶對自己的數(shù)據(jù)庫選型都有一套自己的看法，可能對別人來說，不一定合適，不過可能只有自己會知道，這種選擇是合適的。鞋是不是合適，只有腳知道。因此今天我所表達(dá)的觀點(diǎn)，如果有些不太對您的胃口，姑且一笑而過。

談到數(shù)據(jù)庫選型，免不了要說benchnark測試，當(dāng)年數(shù)據(jù)庫與小型機(jī)市場戰(zhàn)火紛飛的時候，TPC-C打榜十分熱鬧，數(shù)據(jù)庫廠商要證明自己的數(shù)據(jù)庫是天下武功第一。數(shù)據(jù)庫市場和小型機(jī)市場塵埃落定之后，廠家很少去搞TPC-C打榜了，反倒是近些年中國和韓國的數(shù)據(jù)庫廠家偶爾會出現(xiàn)在最新的榜單中。TPC-C基準(zhǔn)測試實(shí)際上并不僅僅是數(shù)據(jù)庫的性能測試，而是一個數(shù)據(jù)庫應(yīng)用系統(tǒng)的整體性能測試，不僅僅要看TPMC的極端指標(biāo)，還要看每個TPMC的成本。我想現(xiàn)在國產(chǎn)數(shù)據(jù)庫選型的時候，每個企業(yè)都會針對TPC-C/TPC-H等進(jìn)行測試。實(shí)際上這種測試意義并不大，只要是一個合格的數(shù)據(jù)庫廠商，那么它出廠時TPC-C就能夠滿足絕大多數(shù)應(yīng)用場景的需求，而那些真正的需要高并發(fā)，大負(fù)載的場景，benchmark測試是測不出來的。TPC-H也是類似，每個數(shù)據(jù)庫廠商都會在數(shù)據(jù)庫研發(fā)時針對tpc-c/tpc-h等基準(zhǔn)測試場景做好優(yōu)化工作，因此只要是一個靠譜一點(diǎn)的數(shù)據(jù)庫產(chǎn)品，這方面都能夠滿足你的業(yè)務(wù)需求。另外一方面，TPC-C測試是一種十分專業(yè)的測試，一般的測試團(tuán)隊不具備測試與分析測試數(shù)據(jù)的能力，因此測試獲得的數(shù)據(jù)也不一定準(zhǔn)確，無法進(jìn)行橫向?qū)Ρ取?/p>

數(shù)據(jù)庫選型中的第二個常見問題是分布式數(shù)據(jù)庫和集中式數(shù)據(jù)庫之間的選擇。很多用戶在考慮數(shù)據(jù)庫選型的時候都會對橫向擴(kuò)展能力有一些執(zhí)念，認(rèn)為選擇數(shù)據(jù)庫一定要選擇具有橫向擴(kuò)展能力的數(shù)據(jù)庫產(chǎn)品。實(shí)際上絕大多數(shù)企業(yè)數(shù)據(jù)庫應(yīng)用場景對橫向擴(kuò)展的要求并沒有那么高，一臺2路服務(wù)器往往已經(jīng)能夠滿足未來5年的業(yè)務(wù)需求了，更何況我們還有更大配置的4路、8路服務(wù)器可選。而五年后，服務(wù)器的性能又可以翻番。因此對于大多數(shù)系統(tǒng)來說，橫向擴(kuò)展并不一定是剛需。我和很多金融企業(yè)的IT人員交流過，他們選擇分布式數(shù)據(jù)庫的主要考慮是安全性和可靠性，并不是更大的并發(fā)處理能力與動態(tài)擴(kuò)展能力。在他們進(jìn)行的一些測試中，也發(fā)現(xiàn)了交易在分布式數(shù)據(jù)庫上交易延時并不像分布式數(shù)據(jù)庫廠商所說的那么優(yōu)秀。對于絕大多數(shù)用戶來說也是如此，對于OLTP系統(tǒng)來說，用戶需要的是分布式數(shù)據(jù)庫的高可用架構(gòu)，而并不是其橫向擴(kuò)展能力以及極致高并發(fā)能力，大多數(shù)系統(tǒng)一個單機(jī)集中式數(shù)據(jù)庫就能夠很好的支撐了。OLAP領(lǐng)域則是相反的，支持列存引擎的MPP數(shù)據(jù)庫在低并發(fā)，復(fù)雜SQL并發(fā)執(zhí)行上面的優(yōu)勢是十分明顯的。

第三個問題是Oracle兼容性問題，這個問題上有兩派截然不同的觀點(diǎn)。第一派認(rèn)為和Oracle兼容十分重要，兼容性已經(jīng)成為他們選擇替代數(shù)據(jù)庫的最重要的原則。另外一派則認(rèn)為無所謂，數(shù)據(jù)遷移是一次性的，只要能夠做好數(shù)模轉(zhuǎn)換，花費(fèi)一次性的成本就可以解決問題了，沒必要把企業(yè)的數(shù)據(jù)庫應(yīng)用鎖定在與Oracle兼容這個圈子里，讓自己在數(shù)據(jù)庫選型方面受到限制。持這種觀點(diǎn)的人大多數(shù)都是MySQL的擁躉，因?yàn)镸ySQL與Oracle的兼容性方面確實(shí)差距有點(diǎn)大。第一派認(rèn)為與Oracle的兼容性十分關(guān)鍵，這不僅僅涉及到應(yīng)用遷移的成本，也涉及到今后長期運(yùn)維時能夠降低一些成本。在這方面我還是傾向于這種觀點(diǎn)的，因?yàn)樵诳紤]數(shù)據(jù)庫選型的企業(yè)中，往往都是已經(jīng)大規(guī)模使用Oracle數(shù)據(jù)庫的，與Oracle保持較高的兼容性，不僅僅可以降低應(yīng)用遷移的成本，更重要的是可以讓整個企業(yè)IT都維持在一個Oracle兼容性生態(tài)中，研發(fā)隊伍也不需要去適應(yīng)新的研發(fā)習(xí)慣，以往的一些積累也可以繼續(xù)沿用。這樣就可以大大節(jié)約數(shù)據(jù)庫國產(chǎn)化工作中的整體IT投資。不過兼容性不僅僅要看表面上的兼容性，如果一條SQL不加以修改就能在新數(shù)據(jù)庫上跑，但是性能下降了幾十倍，不該寫還無法正常使用，那么這種兼容性是偽兼容性，而不是真正的兼容。在企業(yè)做數(shù)據(jù)庫選型的時候，需要對一些常用的復(fù)雜SQL進(jìn)行測試，才能真正區(qū)分出兩種看似“很兼容”的數(shù)據(jù)庫產(chǎn)品中的兼容性的差別。

第四個問題是關(guān)于serverless database的，serverless database是企業(yè)數(shù)據(jù)庫應(yīng)用的問題來趨勢嗎？最近serverless database的概念很熱，這個概念也十分能吸引企業(yè)的IT部門的高層決策者。作為IT部門的領(lǐng)導(dǎo)，誰不愿意讓自己的IT中最頭痛的部分變得serverless啊。不過我也要給這些領(lǐng)導(dǎo)潑盆冷水，我覺得在未來的十年里，serverless database是屬于公有云的，而不是屬于企業(yè)云或者私有云的。Serverless database平臺的運(yùn)營需要很高的水平與技術(shù)能力，哪怕一些私有云供應(yīng)商能夠把各種serverless database解決方案賣給企業(yè)，私有化部署的數(shù)據(jù)庫云平臺也很難在企業(yè)自身IT的管理下運(yùn)作的很好。當(dāng)然有一些技術(shù)能力很強(qiáng)的企業(yè)能夠很好的運(yùn)營自己的serverless database云平臺，不過對于大多數(shù)傳統(tǒng)企業(yè)來說，運(yùn)營的就是一個黑匣子，一旦暴雷，后果不堪設(shè)想。

第五個問題是HTAP能力，關(guān)于我們的數(shù)據(jù)庫是否需要HTAP，這一點(diǎn)毋庸多言了，誰不希望自己的數(shù)據(jù)庫系統(tǒng)一個頂倆呢？不過今天我要談的觀點(diǎn)是，HTAP是要有代價的，要想實(shí)現(xiàn)很好的支持HTAP工作負(fù)載，付出的不僅僅是選一個數(shù)據(jù)庫那么簡單，在基礎(chǔ)硬件方面，肯定要付出更大的投入。在這方面我前幾年也寫過幾篇文章，大家有興趣可以去公眾號中搜索HTAP來查閱。另外要說的一件事就是，目前的國產(chǎn)數(shù)據(jù)庫產(chǎn)品雖然都號稱是HTAP的，但是在復(fù)雜負(fù)載的支撐能力上，還都存在較大的不足。真正具有很強(qiáng)HTAP能力，各方面都能讓用戶較為滿意的國產(chǎn)數(shù)據(jù)庫，可能還要等下一個版本吧。

今天只是就數(shù)據(jù)庫選型談了一些我的個人觀點(diǎn)，這些觀點(diǎn)并不一定適合于每個用戶，僅僅給大家一些參考而已。針對不同的應(yīng)用場景，考慮的因素可能會有所不同，因此也不能一概而論。