數(shù)據(jù)切分與整合可能存在的問題

在實(shí)施數(shù)據(jù)切分方案之前唾戚，有些可能存在的問題我們還是須要做一些分析的柳洋。

一般來說待诅，我們可能遇到的問題主要會(huì)有以下幾點(diǎn)：

• 引入分布式事務(wù)的問題叹坦。
• 跨節(jié)點(diǎn)Join的問題；
• 跨節(jié)點(diǎn)合并排序分頁問題卑雁。

引入分布式事務(wù)的問題

一旦數(shù)據(jù)進(jìn)行切分被分別存放在多個(gè)MySQLServer中之后募书，無論我們的切分規(guī)則設(shè)計(jì)的多么的完美（實(shí)際上并不存在完美的切分規(guī)則）绪囱，都可能造成之前的某些事務(wù)所涉及到的數(shù)據(jù)已經(jīng)不在同一個(gè)MySQLServer中了。

在這樣的場(chǎng)景下莹捡，假設(shè)我們的應(yīng)用程序仍然依照老的解決方式鬼吵，那么勢(shì)必須要引入分布式事務(wù)來解決。分布式事務(wù)本身對(duì)于系統(tǒng)資源的消耗就是非常大的篮赢，性能本身也并非太高齿椅，并且引入分布式事務(wù)本身在異常處理方面就會(huì)帶來較多比較難控制的因素。

首先須要考慮的一件事情就是：是否數(shù)據(jù)庫是唯一一個(gè)能夠解決事務(wù)的地方呢启泣？事實(shí)上并非這樣的涣脚，我們?nèi)荒軌蚪Y(jié)合數(shù)據(jù)庫以及應(yīng)用程序兩者來共同解決。各個(gè)數(shù)據(jù)庫解決自己身上的事務(wù)寥茫，然后通過應(yīng)用程序來控制多個(gè)數(shù)據(jù)庫上面的事務(wù)遣蚀。將一個(gè)跨多個(gè)數(shù)據(jù)庫的分布式事務(wù)分拆成多個(gè)僅處于單個(gè)數(shù)據(jù)庫上面的小事務(wù)，并通過應(yīng)用程序來總控各個(gè)小事務(wù)纱耻。

當(dāng)然芭梯，這樣作的要求就是我們的俄應(yīng)用程序必須要有足夠的健壯性。當(dāng)然也會(huì)給應(yīng)用程序帶來一些技術(shù)難度弄喘。

跨節(jié)點(diǎn)Join的問題

上面介紹了可能引入分布式事務(wù)的問題玖喘，如今我們?cè)倏纯错氁绻?jié)點(diǎn)Join的問題。

數(shù)據(jù)切分之后可能會(huì)造成有些老的Join語句無法繼續(xù)使用蘑志。由于Join使用的數(shù)據(jù)源可能被切分到多個(gè)MySQLServer中了芒涡。

怎么辦？這個(gè)問題從MySQL數(shù)據(jù)庫角度來看卖漫，假設(shè)非得在數(shù)據(jù)庫端來直接解決的話费尽，恐怕僅僅能通過MySQL一種特殊的存儲(chǔ)引擎Federated來攻克了。Federated存儲(chǔ)引擎是MySQL解決相似于Oracle的DBLink之類問題的解決方式羊始。

和OracleDBLink的主要差別在于Federated會(huì)保存一份遠(yuǎn)端表結(jié)構(gòu)的定義信息在本地旱幼。咋一看，F(xiàn)ederated確實(shí)是解決跨節(jié)點(diǎn)Join非常好的解決方式突委“芈保可是我們還應(yīng)該清晰一點(diǎn)，那就似乎假設(shè)遠(yuǎn)端的表結(jié)構(gòu)發(fā)生了變更匀油，本地的表定義信息是不會(huì)跟著發(fā)生對(duì)應(yīng)變化的缘缚。假設(shè)在更新遠(yuǎn)端表結(jié)構(gòu)的時(shí)候并沒有更新本地的Federated表定義信息。就非车醒粒可能造成Query執(zhí)行出錯(cuò)桥滨，無法得到正確的結(jié)果。

對(duì)待這類問題，我還是推薦通過應(yīng)用程序來進(jìn)行處理蒲每，先在驅(qū)動(dòng)表所在的MySQLServer中取出對(duì)應(yīng)的驅(qū)動(dòng)結(jié)果集。然后依據(jù)驅(qū)動(dòng)結(jié)果集再到被驅(qū)動(dòng)表所在的MySQLServer中取出對(duì)應(yīng)的數(shù)據(jù)∑兀可能非常多讀者朋友會(huì)覺得這樣做對(duì)性能會(huì)產(chǎn)生一定的影響，是的状您，確實(shí)是會(huì)對(duì)性能有一定的負(fù)面影響，可是除了此法兜挨，基本上沒有太多其它更好的解決的方法了膏孟。

并且，由于數(shù)據(jù)庫通過較好的擴(kuò)展之后拌汇，每臺(tái)MySQLServer的負(fù)載就能夠得到較好的控制噪舀。單純針對(duì)單條Query來說，其響應(yīng)時(shí)間可能比不切分之前要提高一些纺座，所以性能方面所帶來的負(fù)面影響也并非太大净响。更何況少欺。相似于這樣的須要跨節(jié)點(diǎn)Join的需求也并非太多。相對(duì)于總體性能而言馋贤，可能也僅僅是非常小一部分而已惠毁。所以為了總體性能的考慮，偶爾犧牲那么一點(diǎn)點(diǎn)志电。事實(shí)上是值得的孝情。畢竟系統(tǒng)優(yōu)化本身就是存在非常多取舍和平衡的過程。

跨節(jié)點(diǎn)合并排序分頁問題

一旦進(jìn)行了數(shù)據(jù)的水平切分之后箫荡，可能就并不僅僅僅僅有跨節(jié)點(diǎn)Join無法正常執(zhí)行魁亦，有些排序分頁的Query語句的數(shù)據(jù)源可能也會(huì)被切分到多個(gè)節(jié)點(diǎn)。這樣造成的直接后果就是這些排序分頁Query無法繼續(xù)正常執(zhí)行洁奈。事實(shí)上這和跨節(jié)點(diǎn)Join是一個(gè)道理。數(shù)據(jù)源存在于多個(gè)節(jié)點(diǎn)上绞灼，要通過一個(gè)Query來解決利术，就和跨節(jié)點(diǎn)Join是一樣的操作。相同F(xiàn)ederated也能夠部分解決低矮。當(dāng)然存在的風(fēng)險(xiǎn)也一樣氯哮。

解決的思路大體上和跨節(jié)點(diǎn)Join的解決相似，可是有一點(diǎn)和跨節(jié)點(diǎn)Join不太一樣商佛。Join非常多時(shí)候都有一個(gè)驅(qū)動(dòng)與被驅(qū)動(dòng)的關(guān)系喉钢。所以Join本身涉及到的多個(gè)表之間的數(shù)據(jù)讀取一般都會(huì)存在一個(gè)順序關(guān)系×寄罚可是排序分頁就不太一樣了肠虽，排序分頁的數(shù)據(jù)源基本上能夠說是一個(gè)表（或者一個(gè)結(jié)果集）。本身并不存在一個(gè)順序關(guān)系玛追，所以在從多個(gè)數(shù)據(jù)源取數(shù)據(jù)的過程是全然能夠并行的税课。

這樣排序分頁數(shù)據(jù)的取數(shù)效率我們能夠做的比跨庫Join更高闲延。所以帶來的性能損失相對(duì)的要更小，在有些情況下可能比在原來未進(jìn)行數(shù)據(jù)切分的數(shù)據(jù)庫中效率更高了韩玩。

小結(jié)

當(dāng)然垒玲，不論是跨節(jié)點(diǎn)Join還是跨節(jié)點(diǎn)排序分頁。都會(huì)使我們的應(yīng)用server消耗很多其它的資源找颓，尤其是內(nèi)存資源合愈，由于我們?cè)谧x取訪問以及合并結(jié)果集的這個(gè)過程須要比原來處理很多其它的數(shù)據(jù)。

事實(shí)上全然不是這樣击狮，首先應(yīng)用程序由于其特殊性佛析。能夠非常容易做到非常好的擴(kuò)展性，可是數(shù)據(jù)庫就不一樣彪蓬。必須借助非常多其它的方式才干做到擴(kuò)展寸莫。并且在這個(gè)擴(kuò)展過程中，非常難避免帶來有些原來在集中式數(shù)據(jù)庫中能夠解決但被切分開成一個(gè)數(shù)據(jù)庫集群之后就成為一個(gè)難題的情況档冬。

要想讓系統(tǒng)總體得到最大限度的擴(kuò)展膘茎，我們僅僅能讓應(yīng)用程序做很多其它的事情來解決數(shù)據(jù)庫集群無法較好解決的問題。