本文來自微信公眾號(hào)“白鱔的洞穴”，作者/白鱔。
這些年我在一些企業(yè)的IT主管交流的時(shí)候，他們都認(rèn)為分布式數(shù)據(jù)庫才是他們企業(yè)數(shù)據(jù)庫的未來選擇。在很多情況下，想要改變一個(gè)人的觀點(diǎn)十分的不易，因此在大多數(shù)情況下，經(jīng)過簡單的交流后我都會(huì)放棄讓他們更加深入的了解分布數(shù)據(jù)庫的想法。確實(shí)想要把分布式數(shù)據(jù)庫講清楚并不是三言兩語就能搞定的，因?yàn)槊總€(gè)人，甚至十分資深的IT人員亦或是資深的數(shù)據(jù)庫專家，可能對(duì)某個(gè)分布式數(shù)據(jù)庫的想象都只是存在于他自己的四維空間里，他在按他對(duì)集中式數(shù)據(jù)庫的理解來想象一個(gè)分布式數(shù)據(jù)庫，而事實(shí)上，往往真實(shí)的分布式數(shù)據(jù)庫與他想象的不同。
事實(shí)上，在七八年前，我也是這么想象著分布式數(shù)據(jù)庫的，直到有一天，我和Oracle的研發(fā)部門的高層的一次關(guān)于Oracle 12C SHARDING數(shù)據(jù)庫的討論，才讓我開始認(rèn)真地思考分布式數(shù)據(jù)庫到底是個(gè)什么東西。當(dāng)時(shí)我十分有興趣的想了解Oracle的SHARDING數(shù)據(jù)庫，想了解Oracle是如何使用這個(gè)SHARE NOTHING的SHARDING數(shù)據(jù)庫與當(dāng)前火的一塌糊涂的NEW SQL MPP數(shù)據(jù)庫相抗衡，因?yàn)槟菚r(shí)候，大部分NEW SQL廠家都號(hào)稱在OLAP領(lǐng)域可以秒殺Oracle。讓我感到意外的是，Oracle方面告訴我，Oracle的SHARE NOTHING SHARDING技術(shù)并不支持OLAP，而是面向高并發(fā)寫入的OLTP場(chǎng)景的。雖然Oracle也部分支持在SHARDING庫中進(jìn)行跨庫的分析查詢，但是其性能不見得就很好。Oracle在12C中提供的支持OLAP場(chǎng)景的技術(shù)是in-memory database，而不是SHARDING數(shù)據(jù)庫。當(dāng)時(shí)我感到十分的意外，于是想深入的就這個(gè)話題展開討論，不過因?yàn)闀r(shí)間關(guān)系，對(duì)方?jīng)]有透露更多的細(xì)節(jié)，只是說OLAP場(chǎng)景與OLTP場(chǎng)景的融合十分困難，Oracle目前也沒有更好的技術(shù)來解決，以目前Oracle所掌握的技術(shù)而言，僅僅依靠MPP技術(shù)，目前還無法商用。
為什么連數(shù)據(jù)庫大佬Oracle都認(rèn)為OLTP和OLAP完全融合的MPP技術(shù)，他們還無法完全商用呢？于是我們開始認(rèn)真的思考分布式數(shù)據(jù)庫技術(shù)，剛剛看開始的時(shí)候，我還把問題集中在分布式事務(wù)一致性的問題上，確實(shí)，以前在內(nèi)存中完成的事務(wù)，現(xiàn)在要分布在一個(gè)網(wǎng)絡(luò)環(huán)境中，似乎對(duì)一致性事務(wù)的管理會(huì)有較大的開銷吧，分布式數(shù)據(jù)庫能夠讓分布式事務(wù)的總量有所提高，但是無法提高每個(gè)單個(gè)事務(wù)的性能，這個(gè)恐怕是一個(gè)物理上的問題，不是算法和技術(shù)能夠解決的。實(shí)際上，在最近兩年我們參與過的一些分布式數(shù)據(jù)庫測(cè)試項(xiàng)目中，GTM導(dǎo)致的高并發(fā)事務(wù)延時(shí)問題還是常常被發(fā)現(xiàn)的。
不過事實(shí)上，經(jīng)過后來與不同的需要使用分布式數(shù)據(jù)庫的用戶的交流發(fā)現(xiàn)，大并發(fā)交易并不是他們?cè)诜植紨?shù)據(jù)庫中需要解決的問題，實(shí)際上他們更多的希望用分布式數(shù)據(jù)庫來解決的是一些復(fù)雜的查詢的問題。甚至這其中還有很多用戶對(duì)數(shù)據(jù)庫性能方面的顧慮是來自于對(duì)自己所運(yùn)行的硬件的不了解。我見過的最極端的一個(gè)客戶問我，我們的系統(tǒng)以前跑在一臺(tái)IBM P720上，現(xiàn)在要換成X86服務(wù)器，是不是得換分布式數(shù)據(jù)庫才能搞定啊。當(dāng)時(shí)我就安慰他，現(xiàn)在任何一臺(tái)幾萬塊錢的兩路服務(wù)器，性能都會(huì)比你的那臺(tái)老小型機(jī)快上數(shù)倍。
分布式數(shù)據(jù)庫可以在高并發(fā)寫入時(shí)通過擴(kuò)展集群來獲得更大的并發(fā)處理能力，同時(shí)通過擴(kuò)展分布式計(jì)算節(jié)點(diǎn)來承載更多的并發(fā)SQL，這些都是正確的，不過僅此而已。如果說分布式數(shù)據(jù)庫可以提升高負(fù)載SQL的執(zhí)行效率，這一點(diǎn)絕對(duì)不能武斷，因?yàn)楦哓?fù)載SQL的性能往往取決于幾方面的因素：1）數(shù)據(jù)的分布情況；2）數(shù)據(jù)存儲(chǔ)的性能；3）緩沖池管理算法的性能；4）優(yōu)化器生成的執(zhí)行計(jì)劃的好壞；5）并行執(zhí)行協(xié)調(diào)器的算法以及算子下推的能力；6）可用于表連接和排序的內(nèi)存的大??；7）針對(duì)分布式數(shù)據(jù)庫，還要考慮網(wǎng)絡(luò)方面的因素，比如延時(shí)，SOCKET通訊的效率，硬件的可靠性等。
基于上面的因素我們?nèi)绻痦?xiàng)的來分析，還真的說不好一條比較復(fù)雜的帶有多表關(guān)聯(lián)，排序等要素的SQL語句，就一定會(huì)在分布式數(shù)據(jù)庫上運(yùn)行的更快。在最近的一些用戶的業(yè)務(wù)系統(tǒng)測(cè)試中，也反映出了這一點(diǎn)。
既然分布式數(shù)據(jù)庫不一定會(huì)讓我們的某個(gè)SQL語句變得更快，那么我們是不是沒有理由去使用分布式數(shù)據(jù)庫了呢？也不完全是這樣的，使用分布式數(shù)據(jù)庫，想讓業(yè)務(wù)系統(tǒng)變得更快，只是一部分企業(yè)的需求。還有一些企業(yè)希望通過分布式數(shù)據(jù)庫提高數(shù)據(jù)庫系統(tǒng)的可用性，當(dāng)某些組件出問題的時(shí)候，業(yè)務(wù)系統(tǒng)不受影響，這實(shí)際上是目前大多數(shù)分布式數(shù)據(jù)庫最為擅長的。
另外有一些用戶是希望用一套分布式數(shù)據(jù)庫來替代大量的小型數(shù)據(jù)庫，從而降低運(yùn)維的難度，實(shí)際上這種模式也是一個(gè)雙刃劍，用一套多節(jié)點(diǎn)的分布式數(shù)據(jù)庫來替代上百個(gè)小數(shù)據(jù)庫，是不是真的能夠降低運(yùn)維難度，取決于你是否能夠很好地運(yùn)維好這套分布式數(shù)據(jù)庫。數(shù)據(jù)庫是否足夠穩(wěn)定，運(yùn)維工具是否完善，團(tuán)隊(duì)的運(yùn)維能力是否足夠就成了你今后運(yùn)維的關(guān)鍵。因此這樣的企業(yè)在選擇分布式數(shù)據(jù)庫的時(shí)候，就不要過多的去考慮極端性能，而是應(yīng)該更多的考慮易用性、可靠性以及運(yùn)維工具的能力了。
實(shí)際上，用戶選擇分布式數(shù)據(jù)庫的理由其實(shí)是很多的，不過當(dāng)你的理由是極低的交易延時(shí)、復(fù)雜查詢的性能等因素的時(shí)候，你就要仔細(xì)去考慮了。在最近一些年我們參與的測(cè)試中，針對(duì)業(yè)務(wù)邏輯稍微復(fù)雜一些，數(shù)據(jù)量達(dá)到10TB級(jí)別的系統(tǒng)中，SHARDING模式的分布式數(shù)據(jù)庫輸給集中數(shù)據(jù)庫的案例還是挺多的。說實(shí)在的，最終取決于你使用什么數(shù)據(jù)庫產(chǎn)品的，還是應(yīng)用場(chǎng)景，千萬不要為了一個(gè)你所不了解的技術(shù)去盲目的作出選擇，選擇前，還是先更多的了解技術(shù)本身吧。
