選擇分布式數(shù)據(jù)庫的理由

分布式數(shù)據(jù)庫可以在高并發(fā)寫入時(shí)通過擴(kuò)展集群來獲得更大的并發(fā)處理能力,同時(shí)通過擴(kuò)展分布式計(jì)算節(jié)點(diǎn)來承載更多的并發(fā)SQL,這些都是正確的,不過僅此而已。

本文來自微信公眾號(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ù)本身吧。

THEEND

最新評(píng)論(評(píng)論僅代表用戶觀點(diǎn))

更多
暫無評(píng)論