這些年我在一些企業(yè)的IT主管交流的時候，他們都認(rèn)為分布式數(shù)據(jù)庫才是他們企業(yè)數(shù)據(jù)庫的未來選擇。在很多情況下，想要改變一個人的觀點十分的不易，因此在大多數(shù)情況下，經(jīng)過簡單的交流后我都會放棄讓他們更加深入的了解分布數(shù)據(jù)庫的想法。確實想要把分布式數(shù)據(jù)庫講清楚并不是三言兩語就能搞定的，因為每個人，甚至十分資深的IT人員亦或是資深的數(shù)據(jù)庫專家，可能對某個分布式數(shù)據(jù)庫的想象都只是存在于他自己的四維空間里，他在按他對集中式數(shù)據(jù)庫的理解來想象一個分布式數(shù)據(jù)庫，而事實上，往往真實的分布式數(shù)據(jù)庫與他想象的不同。

事實上，在七八年前，我也是這么想象著分布式數(shù)據(jù)庫的，直到有一天，我和Oracle的研發(fā)部門的高層的一次關(guān)于Oracle 12C SHARDING數(shù)據(jù)庫的討論，才讓我開始認(rèn)真地思考分布式數(shù)據(jù)庫到底是個什么東西。當(dāng)時我十分有興趣的想了解Oracle的SHARDING數(shù)據(jù)庫，想了解Oracle是如何使用這個SHARE NOTHING的SHARDING數(shù)據(jù)庫與當(dāng)前火的一塌糊涂的NEW SQL MPP數(shù)據(jù)庫相抗衡，因為那時候，大部分NEW SQL廠家都號稱在OLAP領(lǐng)域可以秒殺Oracle。讓我感到意外的是，Oracle方面告訴我，Oracle的SHARE NOTHING SHARDING技術(shù)并不支持OLAP，而是面向高并發(fā)寫入的OLTP場景的。雖然Oracle也部分支持在SHARDING庫中進(jìn)行跨庫的分析查詢，但是其性能不見得就很好。Oracle在12C中提供的支持OLAP場景的技術(shù)是in-memory database，而不是SHARDING數(shù)據(jù)庫。當(dāng)時我感到十分的意外，于是想深入的就這個話題展開討論，不過因為時間關(guān)系，對方?jīng)]有透露更多的細(xì)節(jié)，只是說OLAP場景與OLTP場景的融合十分困難，Oracle目前也沒有更好的技術(shù)來解決，以目前Oracle所掌握的技術(shù)而言，僅僅依靠MPP技術(shù)，目前還無法商用。

為什么連數(shù)據(jù)庫大佬Oracle都認(rèn)為OLTP和OLAP完全融合的MPP技術(shù)，他們還無法完全商用呢？于是我們開始認(rèn)真的思考分布式數(shù)據(jù)庫技術(shù)，剛剛看開始的時候，我還把問題集中在分布式事務(wù)一致性的問題上，確實，以前在內(nèi)存中完成的事務(wù)，現(xiàn)在要分布在一個網(wǎng)絡(luò)環(huán)境中，似乎對一致性事務(wù)的管理會有較大的開銷吧，分布式數(shù)據(jù)庫能夠讓分布式事務(wù)的總量有所提高，但是無法提高每個單個事務(wù)的性能，這個恐怕是一個物理上的問題，不是算法和技術(shù)能夠解決的。實際上，在最近兩年我們參與過的一些分布式數(shù)據(jù)庫測試項目中，GTM導(dǎo)致的高并發(fā)事務(wù)延時問題還是常常被發(fā)現(xiàn)的。

不過事實上，經(jīng)過后來與不同的需要使用分布式數(shù)據(jù)庫的用戶的交流發(fā)現(xiàn)，大并發(fā)交易并不是他們在分布數(shù)據(jù)庫中需要解決的問題，實際上他們更多的希望用分布式數(shù)據(jù)庫來解決的是一些復(fù)雜的查詢的問題。甚至這其中還有很多用戶對數(shù)據(jù)庫性能方面的顧慮是來自于對自己所運行的硬件的不了解。我見過的最極端的一個客戶問我，我們的系統(tǒng)以前跑在一臺IBM P720上，現(xiàn)在要換成X86服務(wù)器，是不是得換分布式數(shù)據(jù)庫才能搞定啊。當(dāng)時我就安慰他，現(xiàn)在任何一臺幾萬塊錢的兩路服務(wù)器，性能都會比你的那臺老小型機(jī)快上數(shù)倍。

分布式數(shù)據(jù)庫可以在高并發(fā)寫入時通過擴(kuò)展集群來獲得更大的并發(fā)處理能力，同時通過擴(kuò)展分布式計算節(jié)點來承載更多的并發(fā)SQL，這些都是正確的，不過僅此而已。如果說分布式數(shù)據(jù)庫可以提升高負(fù)載SQL的執(zhí)行效率，這一點絕對不能武斷，因為高負(fù)載SQL的性能往往取決于幾方面的因素：1）數(shù)據(jù)的分布情況；2）數(shù)據(jù)存儲的性能；3）緩沖池管理算法的性能；4）優(yōu)化器生成的執(zhí)行計劃的好壞；5）并行執(zhí)行協(xié)調(diào)器的算法以及算子下推的能力；6）可用于表連接和排序的內(nèi)存的大小；7）針對分布式數(shù)據(jù)庫，還要考慮網(wǎng)絡(luò)方面的因素，比如延時，SOCKET通訊的效率，硬件的可靠性等。

基于上面的因素我們?nèi)绻痦椀膩矸治觯€真的說不好一條比較復(fù)雜的帶有多表關(guān)聯(lián)，排序等要素的SQL語句，就一定會在分布式數(shù)據(jù)庫上運行的更快。在最近的一些用戶的業(yè)務(wù)系統(tǒng)測試中，也反映出了這一點。

既然分布式數(shù)據(jù)庫不一定會讓我們的某個SQL語句變得更快，那么我們是不是沒有理由去使用分布式數(shù)據(jù)庫了呢？也不完全是這樣的，使用分布式數(shù)據(jù)庫，想讓業(yè)務(wù)系統(tǒng)變得更快，只是一部分企業(yè)的需求。還有一些企業(yè)希望通過分布式數(shù)據(jù)庫提高數(shù)據(jù)庫系統(tǒng)的可用性，當(dāng)某些組件出問題的時候，業(yè)務(wù)系統(tǒng)不受影響，這實際上是目前大多數(shù)分布式數(shù)據(jù)庫最為擅長的。

另外有一些用戶是希望用一套分布式數(shù)據(jù)庫來替代大量的小型數(shù)據(jù)庫，從而降低運維的難度，實際上這種模式也是一個雙刃劍，用一套多節(jié)點的分布式數(shù)據(jù)庫來替代上百個小數(shù)據(jù)庫，是不是真的能夠降低運維難度，取決于你是否能夠很好地運維好這套分布式數(shù)據(jù)庫。數(shù)據(jù)庫是否足夠穩(wěn)定，運維工具是否完善，團(tuán)隊的運維能力是否足夠就成了你今后運維的關(guān)鍵。因此這樣的企業(yè)在選擇分布式數(shù)據(jù)庫的時候，就不要過多的去考慮極端性能，而是應(yīng)該更多的考慮易用性、可靠性以及運維工具的能力了。

實際上，用戶選擇分布式數(shù)據(jù)庫的理由其實是很多的，不過當(dāng)你的理由是極低的交易延時、復(fù)雜查詢的性能等因素的時候，你就要仔細(xì)去考慮了。在最近一些年我們參與的測試中，針對業(yè)務(wù)邏輯稍微復(fù)雜一些，數(shù)據(jù)量達(dá)到10TB級別的系統(tǒng)中，SHARDING模式的分布式數(shù)據(jù)庫輸給集中數(shù)據(jù)庫的案例還是挺多的。說實在的，最終取決于你使用什么數(shù)據(jù)庫產(chǎn)品的，還是應(yīng)用場景，千萬不要為了一個你所不了解的技術(shù)去盲目的作出選擇，選擇前，還是先更多的了解技術(shù)本身吧。