建站
咨詢
售后
建站咨詢
新聞中心
在一個(gè)日益數(shù)字化、信息化的時(shí)代，數(shù)據(jù)處理效率是一個(gè)極為重要的任務(wù)。對(duì)于大型企業(yè)、互聯(lián)網(wǎng)公司等大規(guī)模數(shù)據(jù)處理的場(chǎng)景來(lái)說(shuō)，傳統(tǒng)數(shù)據(jù)庫(kù)技術(shù)已經(jīng)無(wú)法滿足處理效率的需求。因此，數(shù)據(jù)庫(kù)分片技術(shù)的出現(xiàn)成為提高數(shù)據(jù)處理效率的有效手段。本文從數(shù)據(jù)庫(kù)分片概念、優(yōu)勢(shì)與劣勢(shì)以及應(yīng)用場(chǎng)景三個(gè)方面為大家深入探究數(shù)據(jù)庫(kù)分片技術(shù)。
專注于為中小企業(yè)提供做網(wǎng)站、成都網(wǎng)站建設(shè)服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)泌陽(yáng)免費(fèi)做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動(dòng)了上千余家企業(yè)的穩(wěn)健成長(zhǎng)，幫助中小企業(yè)通過(guò)網(wǎng)站建設(shè)實(shí)現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。
一、數(shù)據(jù)庫(kù)分片的概念
數(shù)據(jù)庫(kù)分片是將一張表按照某種規(guī)則分散存儲(chǔ)在多個(gè)物理節(jié)點(diǎn)上的技術(shù)，每個(gè)節(jié)點(diǎn)稱為一個(gè)分片。根據(jù)分片規(guī)則，對(duì)于不同的數(shù)據(jù)進(jìn)行分區(qū)存儲(chǔ)和處理。此時(shí)，不同的數(shù)據(jù)可以分散在不同的數(shù)據(jù)庫(kù)中，從而實(shí)現(xiàn)數(shù)據(jù)的擴(kuò)展存儲(chǔ)。在實(shí)際應(yīng)用中，數(shù)據(jù)分片一般指水平分片。即按照行進(jìn)行數(shù)據(jù)分割，使每個(gè)數(shù)據(jù)節(jié)點(diǎn)只存儲(chǔ)部分?jǐn)?shù)據(jù)。
二、優(yōu)勢(shì)與劣勢(shì)
數(shù)據(jù)庫(kù)分片技術(shù)可以帶來(lái)顯著的優(yōu)勢(shì)，主要體現(xiàn)在以下幾個(gè)方面：
1.提高性能：在高并發(fā)或者大規(guī)模數(shù)據(jù)情況下，使用數(shù)據(jù)庫(kù)分片技術(shù)可以提高系統(tǒng)的承載能力，減少單個(gè)節(jié)點(diǎn)的壓力，提高系統(tǒng)響應(yīng)速度。
2.可擴(kuò)展性：在系統(tǒng)面臨擴(kuò)展的情況下，數(shù)據(jù)庫(kù)分片可以通過(guò)添加節(jié)點(diǎn)的方式進(jìn)行水平擴(kuò)展，無(wú)需對(duì)系統(tǒng)進(jìn)行大規(guī)模的修改和改變。
3.增強(qiáng)可用性：由于數(shù)據(jù)經(jīng)過(guò)分散存儲(chǔ)和處理，系統(tǒng)故障時(shí)只會(huì)影響部分?jǐn)?shù)據(jù)，其他節(jié)點(diǎn)的數(shù)據(jù)仍可被訪問(wèn)，因此分片可以提高系統(tǒng)的可用性。
4.節(jié)約成本：使用數(shù)據(jù)庫(kù)分片技術(shù)可以為企業(yè)節(jié)約成本。由于分片技術(shù)可以實(shí)現(xiàn)擴(kuò)展存儲(chǔ)，無(wú)需進(jìn)行大規(guī)模的升級(jí)和更換，因此降低了企業(yè) IT 系統(tǒng)維護(hù)的成本。
然而，數(shù)據(jù)庫(kù)分片技術(shù)也存在一些劣勢(shì)。主要包括以下幾點(diǎn)：
1.數(shù)據(jù)一致性：由于不同節(jié)點(diǎn)存儲(chǔ)的數(shù)據(jù)不同，分片技術(shù)無(wú)法保證全局?jǐn)?shù)據(jù)一致性，因此需要合理的設(shè)計(jì)分片規(guī)則，以避免數(shù)據(jù)不一致的問(wèn)題。
2.分片規(guī)則設(shè)計(jì)：分片規(guī)則的設(shè)計(jì)需要考慮多個(gè)因素，比如數(shù)據(jù)量大小、性能瓶頸、負(fù)載均衡、數(shù)據(jù)分布規(guī)律等。因此，分片技術(shù)需要深入探究和合理的設(shè)計(jì)。
3.修改難度：當(dāng)系統(tǒng)數(shù)據(jù)規(guī)模發(fā)生變化時(shí)，需要修改分片規(guī)則，對(duì)系統(tǒng)的影響程度較大，因此更換分片技術(shù)需要進(jìn)行完整的數(shù)據(jù)遷移，難度較大。
三、應(yīng)用場(chǎng)景
數(shù)據(jù)庫(kù)分片技術(shù)主要應(yīng)用于大規(guī)模數(shù)據(jù)信息處理場(chǎng)景，如互聯(lián)網(wǎng)企業(yè)、金融、物聯(lián)網(wǎng)等領(lǐng)域。具體應(yīng)用場(chǎng)景如下：
1.熱點(diǎn)數(shù)據(jù)處理：大型互聯(lián)網(wǎng)公司中經(jīng)常需要處理熱點(diǎn)數(shù)據(jù)，比如電商平臺(tái)的訂單數(shù)據(jù)。此時(shí)，可以根據(jù)優(yōu)先級(jí)將這些數(shù)據(jù)單獨(dú)分片存儲(chǔ)，以便快速查詢和計(jì)算。
2.數(shù)據(jù)擴(kuò)展：企業(yè)高速發(fā)展的情況下，數(shù)據(jù)量增長(zhǎng)迅速，此時(shí)可以使用數(shù)據(jù)庫(kù)分片技術(shù)進(jìn)行水平擴(kuò)展，以滿足更加快速和高效的數(shù)據(jù)處理能力。
3.分布式應(yīng)用：分布式應(yīng)用中，需要根據(jù)不同的分片規(guī)則實(shí)現(xiàn)數(shù)據(jù)的分散存儲(chǔ)，從而使分布式應(yīng)用具有高擴(kuò)展性、高并發(fā)性能。
4.全球數(shù)據(jù)中心：在全球化的領(lǐng)域，企業(yè)需要在不同的數(shù)據(jù)中心之間存儲(chǔ)和傳輸數(shù)據(jù)。此時(shí)，可以使用分片技術(shù)將數(shù)據(jù)存儲(chǔ)在不同的數(shù)據(jù)庫(kù)中，以便于處理和維護(hù)。
數(shù)據(jù)庫(kù)分片技術(shù)是一種重要的大規(guī)模數(shù)據(jù)處理方法，它可以提高數(shù)據(jù)處理效率，實(shí)現(xiàn)系統(tǒng)的高擴(kuò)展性、高并發(fā)性能。但是，為了利用數(shù)據(jù)庫(kù)分片技術(shù)，需要合理的分片規(guī)則和數(shù)據(jù)一致性控制。在實(shí)際應(yīng)用中，需要根據(jù)具體場(chǎng)景和需求進(jìn)行靈活的選擇和設(shè)計(jì)。
成都網(wǎng)站建設(shè)公司-創(chuàng)新互聯(lián),建站經(jīng)驗(yàn)豐富以策略為先導(dǎo)10多年以來(lái)專注數(shù)字化網(wǎng)站建設(shè),提供企業(yè)網(wǎng)站建設(shè),高端網(wǎng)站設(shè)計(jì),響應(yīng)式網(wǎng)站制作,設(shè)計(jì)師量身打造品牌風(fēng)格,熱線:028-86922220數(shù)據(jù)庫(kù)為什么要分庫(kù)分表
一、NewSQL數(shù)據(jù)庫(kù)先進(jìn)在哪兒？
首先關(guān)于“中間件+關(guān)系數(shù)據(jù)庫(kù)分庫(kù)分表”算不算NewSQL分布式數(shù)據(jù)庫(kù)問(wèn)題，國(guó)外有篇論文pavlo-newsql-sigmodrec，如果根據(jù)該文中的分類，Spanner、TiDB、OB算是之一種新架構(gòu)型，Sharding-Sphere、Mycat、DRDS等中間件方案算是第二種（文中還有第三種云數(shù)據(jù)庫(kù)，本文暫不詳細(xì)介紹）。
「pavlo-newsql-sigmodrec」 參考鏈接：
基于中間件（包括SDK和Proxy兩種形式）+傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)（分庫(kù)分表）模式是不是分布式架構(gòu)？我覺(jué)得是的，因?yàn)榇鎯?chǔ)確實(shí)也分布式了，也能實(shí)現(xiàn)橫向擴(kuò)展。但是不是“偽”分布式數(shù)據(jù)庫(kù)？從架構(gòu)先進(jìn)性來(lái)看，這么說(shuō)也有一定道理。
“偽”主要體現(xiàn)在中間件層與底層DB重復(fù)的SQL解析與執(zhí)行計(jì)劃生成、存儲(chǔ)引擎基于B+Tree等，這在分布式數(shù)據(jù)庫(kù)架構(gòu)中實(shí)際上冗余低效的。為了避免引起真?zhèn)畏植际綌?shù)據(jù)庫(kù)的口水戰(zhàn)，本文中NewSQL數(shù)據(jù)庫(kù)特指這種新架構(gòu)NewSQL數(shù)據(jù)庫(kù)。
NewSQL數(shù)據(jù)庫(kù)相比中間件+分庫(kù)分表的先進(jìn)在哪兒？畫一個(gè)簡(jiǎn)單的架構(gòu)對(duì)比圖：
請(qǐng)點(diǎn)擊輸入圖片描述
傳統(tǒng)數(shù)據(jù)庫(kù)面向磁盤設(shè)計(jì)，基于內(nèi)存的存儲(chǔ)管理及并發(fā)控制，不如NewSQL數(shù)據(jù)庫(kù)那般高效利用；
中間件模式SQL解析、執(zhí)行計(jì)劃優(yōu)化等在中間件與數(shù)據(jù)庫(kù)中重復(fù)工作，效率相比較低；
NewSQL數(shù)據(jù)庫(kù)的分布式事務(wù)相比于XA進(jìn)行了優(yōu)化，性能更高；
新架構(gòu)NewSQL數(shù)據(jù)庫(kù)存儲(chǔ)設(shè)計(jì)即為基于paxos（或Raft）協(xié)議的多副本，相比于傳統(tǒng)數(shù)據(jù)庫(kù)主從模式（半同步轉(zhuǎn)異步后也存在丟數(shù)問(wèn)題），在實(shí)現(xiàn)了真正的高可用、高可靠（RTO
NewSQL數(shù)據(jù)庫(kù)天生支持?jǐn)?shù)據(jù)分片，數(shù)據(jù)的遷移、擴(kuò)容都是自動(dòng)化的，大大減輕了DBA的工作，同時(shí)對(duì)應(yīng)用透明，無(wú)需在SQL指定分庫(kù)分表鍵。
這些大多也是NewSQL數(shù)據(jù)庫(kù)產(chǎn)品主要宣傳的點(diǎn)，不過(guò)這些看起來(lái)很美好的功能是否真的如此？接下來(lái)針對(duì)以上幾點(diǎn)分別闡述下的我的理解。
二、分布式事務(wù)
這是把雙刃劍。
1、CAP限制想想更早些出現(xiàn)的NoSQL數(shù)據(jù)庫(kù)為何不支持分布式事務(wù)（最新版的MongoDB等也開(kāi)始支持了），是缺乏理論與實(shí)踐支撐嗎？并不是，原因是CAP定理依然是分布式數(shù)據(jù)庫(kù)頭上的緊箍咒，在保證強(qiáng)一致的同時(shí)必然會(huì)犧牲可用性A或分區(qū)容忍性P。為什么大部分NoSQL不提供分布式事務(wù)？
《為什么大部分NoSQL不提供分布式事務(wù)？》
參考鏈接：
那么NewSQL數(shù)據(jù)庫(kù)突破CAP定理限制了嗎？并沒(méi)有。NewSQL數(shù)據(jù)庫(kù)的鼻祖Google Spanner（目前絕大部分分布式數(shù)據(jù)庫(kù)都是按照Spanner架構(gòu)設(shè)計(jì)的）提供了一致性和大于5個(gè)9的可用性，宣稱是一個(gè)“實(shí)際上是CA”的，其真正的含義是系統(tǒng)處于CA狀態(tài)的概率非常高，由于網(wǎng)絡(luò)分區(qū)導(dǎo)致的服務(wù)停用的概率非常小，究其真正原因是其打造私有全球網(wǎng)保證了不會(huì)出現(xiàn)網(wǎng)絡(luò)中斷引發(fā)的網(wǎng)絡(luò)分區(qū)，另外就是其高效的運(yùn)維隊(duì)伍，這也是cloud spanner的賣點(diǎn)。詳細(xì)可見(jiàn)CAP提出者Eric Brewer寫的《Spanner, TrueTime和CAP理論》?！禨panner, TrueTime和CAP理論》
參考鏈接：
推薦一篇關(guān)于分布式系統(tǒng)有趣的文章《站在巨人的分布式肩膀上》，其中提到：分布式系統(tǒng)中，您可以知道工作在哪里，或者您可以知道工作何時(shí)完成，但您無(wú)法同時(shí)了解兩者；兩階段協(xié)議本質(zhì)上是反可用性協(xié)議。
《站在巨人的分布式肩膀上》
參考鏈接：
2、完備性
兩階段提交協(xié)議是否嚴(yán)格支持ACID，各種異常場(chǎng)景是不是都可以覆蓋？
2PC在commit階段發(fā)送異常，其實(shí)跟更大努力一階段提交類似也會(huì)有部分可見(jiàn)問(wèn)題，嚴(yán)格講一段時(shí)間內(nèi)并不能保證A原子性和C一致性（待故障恢復(fù)后recovery機(jī)制可以保證最終的A和C）。完備的分布式事務(wù)支持并不是一件簡(jiǎn)單的事情，需要可以應(yīng)對(duì)網(wǎng)絡(luò)以及各種硬件包括網(wǎng)卡、磁盤、CPU、內(nèi)存、電源等各類異常，通過(guò)嚴(yán)格的測(cè)試。
之前跟某友商交流，他們甚至說(shuō)目前已知的NewSQL在分布式事務(wù)支持上都是不完整的，他們都有案例跑不過(guò)，圈內(nèi)人士這么篤定，也說(shuō)明了分布式事務(wù)的支持完整程度其實(shí)是層次不齊的。
但分布式事務(wù)又是這些NewSQL數(shù)據(jù)庫(kù)的一個(gè)非常重要的底層機(jī)制，跨資源的DML、DDL等都依賴其實(shí)現(xiàn)，如果這塊的性能、完備性打折扣，上層跨分片SQL執(zhí)行的正確性會(huì)受到很大影響。
3、性能傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)也支持分布式事務(wù)XA，但為何很少有高并發(fā)場(chǎng)景下用呢？因?yàn)閄A的基礎(chǔ)兩階段提交協(xié)議存在網(wǎng)絡(luò)開(kāi)銷大，阻塞時(shí)間長(zhǎng)、死鎖等問(wèn)題，這也導(dǎo)致了其實(shí)際上很少大規(guī)模用在基于傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)的OLTP系統(tǒng)中。NewSQL數(shù)據(jù)庫(kù)的分布式事務(wù)實(shí)現(xiàn)也仍然多基于兩階段提交協(xié)議，例如google percolator分布式事務(wù)模型，采用原子鐘+MVCC+ Snapshot Isolation（SI），這種方式通過(guò)TSO(Timestamp Oracle)保證了全局一致性，通過(guò)MVCC避免了鎖，另外通過(guò)primary lock和secondary lock將提交的一部分轉(zhuǎn)為異步，相比XA確實(shí)提高了分布式事務(wù)的性能。SI是樂(lè)觀鎖，在熱點(diǎn)數(shù)據(jù)場(chǎng)景，可能會(huì)大量的提交失敗。另外SI的隔離級(jí)別與RR并非完全相同，它不會(huì)有幻想讀，但會(huì)有寫傾斜。但不管如何優(yōu)化，相比于1PC，2PC多出來(lái)的GID獲取、網(wǎng)絡(luò)開(kāi)銷、prepare日志持久化還是會(huì)帶來(lái)很大的性能損失，尤其是跨節(jié)點(diǎn)的數(shù)量比較多時(shí)會(huì)更加顯著，例如在銀行場(chǎng)景做個(gè)批量扣款，一個(gè)文件可能上W個(gè)賬戶，這樣的場(chǎng)景無(wú)論怎么做還是吞吐都不會(huì)很高。
請(qǐng)點(diǎn)擊輸入圖片描述
請(qǐng)點(diǎn)擊輸入圖片描述
▲ Spanner給出的分布式事務(wù)測(cè)試數(shù)據(jù)
雖然NewSQL分布式數(shù)據(jù)庫(kù)產(chǎn)品都宣傳完備支持分布式事務(wù)，但這并不是說(shuō)應(yīng)用可以完全不用關(guān)心數(shù)據(jù)拆分，這些數(shù)據(jù)庫(kù)的更佳實(shí)踐中仍然會(huì)寫到，應(yīng)用的大部分場(chǎng)景盡可能避免分布式事務(wù)。既然強(qiáng)一致事務(wù)付出的性能代價(jià)太大，我們可以反思下是否真的需要這種強(qiáng)一致的分布式事務(wù)？尤其是在做微服務(wù)拆分后，很多系統(tǒng)也不太可能放在一個(gè)統(tǒng)一的數(shù)據(jù)庫(kù)中。嘗試將一致性要求弱化，便是柔性事務(wù)，放棄ACID(Atomicity, Consistency, Isolation, Durability)，轉(zhuǎn)投BASE(Basically Available, Soft state, Eventually consistent)，例如Saga、TCC、可靠消息保證最終一致等模型，對(duì)于大規(guī)模高并發(fā)OLTP場(chǎng)景，我個(gè)人更建議使用柔性事務(wù)而非強(qiáng)一致的分布式事務(wù)。關(guān)于柔性事務(wù)，筆者之前也寫過(guò)一個(gè)技術(shù)組件，最近幾年也涌現(xiàn)出了一些新的模型與框架（例如阿里剛開(kāi)源的Fescar），限于篇幅不再贅述，詳細(xì)可閱讀《分布式事務(wù)選型的取舍》。解決分布式事務(wù)是否只能用兩階段提交協(xié)議？OceanBase 1.0中通過(guò)updateserver避免分布式事務(wù)的思路很有啟發(fā)性 ，不過(guò)2.0版后也變成了2PC。業(yè)界分布式事務(wù)也并非只有兩階段提交這一解。其它方案參考鏈接：its-time-to-move-on-from-two-phase翻譯版參考鏈接：
三、HA與異地多活
主從模式并不是更優(yōu)的方式，就算是半同步復(fù)制，在極端情況下（半同步轉(zhuǎn)異步）也存在丟數(shù)據(jù)問(wèn)題，目前業(yè)界公認(rèn)更好的方案是基于paxos分布式一致性協(xié)議或者其它類paxos如raft方式，Google Spanner、TiDB、CockcoachDB、OB都采用了這種方式，基于Paxos協(xié)議的多副本存儲(chǔ)，遵循過(guò)半寫原則，支持自動(dòng)選主，解決了數(shù)據(jù)的高可靠，縮短了failover時(shí)間，提高了可用性，特別是減少了運(yùn)維的工作量，這種方案技術(shù)上已經(jīng)很成熟，也是NewSQL數(shù)據(jù)庫(kù)底層的標(biāo)配。當(dāng)然這種方式其實(shí)也可以用在傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)，阿里、微信團(tuán)隊(duì)等也有將MySQL存儲(chǔ)改造支持paxos多副本的，MySQL也推出了官方版MySQL Group Cluster，預(yù)計(jì)不遠(yuǎn)的未來(lái)主從模式可能就成為歷史了。分布式一致性算法本身并不難，但具體在工程實(shí)踐時(shí)，需要考慮很多異常并做很多優(yōu)化，實(shí)現(xiàn)一個(gè)生產(chǎn)級(jí)可靠成熟的一致性協(xié)議并不容易。例如實(shí)際使用時(shí)必須轉(zhuǎn)化實(shí)現(xiàn)為multi-paxos或multi-raft，需要通過(guò)batch、異步等方式減少網(wǎng)絡(luò)、磁盤IO等開(kāi)銷。需要注意的是很多NewSQL數(shù)據(jù)庫(kù)廠商宣傳基于paxos或raft協(xié)議可以實(shí)現(xiàn)【異地多活】，這個(gè)實(shí)際上是有前提的，那就是異地之間網(wǎng)絡(luò)延遲不能太高。以銀行“兩地三中心”為例，異地之間多相隔數(shù)千里，延時(shí)達(dá)到數(shù)十毫秒，如果要多活，那便需異地副本也參與數(shù)據(jù)庫(kù)日志過(guò)半確認(rèn)，這樣高的延時(shí)幾乎沒(méi)有OLTP系統(tǒng)可以接受的。數(shù)據(jù)庫(kù)層面做異地多活是個(gè)美好的愿景，但距離導(dǎo)致的延時(shí)目前并沒(méi)有好的方案。之前跟螞蟻團(tuán)隊(duì)交流，螞蟻異地多活的方案是在應(yīng)用層通過(guò)MQ同步雙寫交易信息，異地DC將交易信息保存在分布式緩存中，一旦發(fā)生異地切換，數(shù)據(jù)庫(kù)同步中間件會(huì)告之?dāng)?shù)據(jù)延遲時(shí)間，應(yīng)用從緩存中讀取交易信息，將這段時(shí)間內(nèi)涉及到的業(yè)務(wù)對(duì)象例如用戶、賬戶進(jìn)行黑名單管理，等數(shù)據(jù)同步追上之后再將這些業(yè)務(wù)對(duì)象從黑名單中剔除。由于雙寫的不是所有數(shù)據(jù)庫(kù)操作日志而只是交易信息，數(shù)據(jù)延遲只影響一段時(shí)間內(nèi)數(shù)據(jù)，這是目前我覺(jué)得比較靠譜的異地度多活方案。另外有些系統(tǒng)進(jìn)行了單元化改造，這在paxos選主時(shí)也要結(jié)合考慮進(jìn)去，這也是目前很多NewSQL數(shù)據(jù)庫(kù)欠缺的功能。
四、Scale橫向擴(kuò)展與分片機(jī)制
paxos算法解決了高可用、高可靠問(wèn)題，并沒(méi)有解決Scale橫向擴(kuò)展的問(wèn)題，所以分片是必須支持的。NewSQL數(shù)據(jù)庫(kù)都是天生內(nèi)置分片機(jī)制的，而且會(huì)根據(jù)每個(gè)分片的數(shù)據(jù)負(fù)載(磁盤使用率、寫入速度等)自動(dòng)識(shí)別熱點(diǎn)，然后進(jìn)行分片的分裂、數(shù)據(jù)遷移、合并，這些過(guò)程應(yīng)用是無(wú)感知的，這省去了DBA的很多運(yùn)維工作量。以TiDB為例，它將數(shù)據(jù)切成region，如果region到64M時(shí)，數(shù)據(jù)自動(dòng)進(jìn)行遷移。分庫(kù)分表模式下需要應(yīng)用設(shè)計(jì)之初就要明確各表的拆分鍵、拆分方式（range、取模、一致性哈?；蛘咦远x路由表）、路由規(guī)則、拆分庫(kù)表數(shù)量、擴(kuò)容方式等。相比NewSQL數(shù)據(jù)庫(kù)，這種模式給應(yīng)用帶來(lái)了很大侵入和復(fù)雜度，這對(duì)大多數(shù)系統(tǒng)來(lái)說(shuō)也是一大挑戰(zhàn)。分庫(kù)分表模式也能做到在線擴(kuò)容，基本思路是通過(guò)異步復(fù)制先追加數(shù)據(jù)，然后設(shè)置只讀完成路由切換，最后放開(kāi)寫操作，當(dāng)然這些需要中間件與數(shù)據(jù)庫(kù)端配合一起才能完成。這里有個(gè)問(wèn)題是NewSQL數(shù)據(jù)庫(kù)統(tǒng)一的內(nèi)置分片策略（例如TiDB基于range）可能并不是更高效的，因?yàn)榕c領(lǐng)域模型中的劃分要素并不一致，這導(dǎo)致的后果是很多交易會(huì)產(chǎn)生分布式事務(wù)。舉個(gè)例子，銀行核心業(yè)務(wù)系統(tǒng)是以客戶為維度，也就是說(shuō)客戶表、該客戶的賬戶表、流水表在絕大部分場(chǎng)景下是一起寫的，但如果按照各表主鍵range進(jìn)行分片，這個(gè)交易并不能在一個(gè)分片上完成，這在高頻OLTP系統(tǒng)中會(huì)帶來(lái)性能問(wèn)題。
五、分布式SQL支持
常見(jiàn)的單分片SQL，這兩者都能很好支持。NewSQL數(shù)據(jù)庫(kù)由于定位與目標(biāo)是一個(gè)通用的數(shù)據(jù)庫(kù)，所以支持的SQL會(huì)更完整，包括跨分片的join、聚合等復(fù)雜SQL。中間件模式多面向應(yīng)用需求設(shè)計(jì)，不過(guò)大部分也支持帶拆分鍵SQL、庫(kù)表遍歷、單庫(kù)join、聚合、排序、分頁(yè)等。但對(duì)跨庫(kù)的join以及聚合支持就不夠了。NewSQL數(shù)據(jù)庫(kù)一般并不支持存儲(chǔ)過(guò)程、視圖、外鍵等功能，而中間件模式底層就是傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)，這些功能如果只是涉及單庫(kù)是比較容易支持的。NewSQL數(shù)據(jù)庫(kù)往往選擇兼容MySQL或者PostgreSQL協(xié)議，所以SQL支持僅局限于這兩種，中間件例如驅(qū)動(dòng)模式往往只需做簡(jiǎn)單的SQL解析、計(jì)算路由、SQL重寫，所以可以支持更多種類的數(shù)據(jù)庫(kù)SQL。SQL支持的差異主要在于分布式SQL執(zhí)行計(jì)劃生成器，由于NewSQL數(shù)據(jù)庫(kù)具有底層數(shù)據(jù)的分布、統(tǒng)計(jì)信息，因此可以做CBO，生成的執(zhí)行計(jì)劃效率更高，而中間件模式下沒(méi)有這些信息，往往只能基于規(guī)則RBO（Rule-Based-Opimization），這也是為什么中間件模式一般并不支持跨庫(kù)join，因?yàn)閷?shí)現(xiàn)了效率也往往并不高，還不如交給應(yīng)用去做。這里也可以看出中間件+分庫(kù)分表模式的架構(gòu)風(fēng)格體現(xiàn)出的是一種妥協(xié)、平衡，它是一個(gè)面向應(yīng)用型的設(shè)計(jì)；而NewSQL數(shù)據(jù)庫(kù)則要求更高、“大包大攬”，它是一個(gè)通用底層技術(shù)軟件，因此后者的復(fù)雜度、技術(shù)門檻也高很多。
六、存儲(chǔ)引擎
傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)的存儲(chǔ)引擎設(shè)計(jì)都是面向磁盤的，大多都基于B+樹。B+樹通過(guò)降低樹的高度減少隨機(jī)讀、進(jìn)而減少磁盤尋道次數(shù)，提高讀的性能，但大量的隨機(jī)寫會(huì)導(dǎo)致樹的分裂，從而帶來(lái)隨機(jī)寫，導(dǎo)致寫性能下降。NewSQL的底層存儲(chǔ)引擎則多采用L，相比B+樹L將對(duì)磁盤的隨機(jī)寫變成順序?qū)?，大大提高了寫的性能。不過(guò)L的的讀由于需要合并數(shù)據(jù)性能比B+樹差，一般來(lái)說(shuō)L更適合應(yīng)在寫大于讀的場(chǎng)景。當(dāng)然這只是單純數(shù)據(jù)結(jié)構(gòu)角度的對(duì)比，在數(shù)據(jù)庫(kù)實(shí)際實(shí)現(xiàn)時(shí)還會(huì)通過(guò)SSD、緩沖、bloom filter等方式優(yōu)化讀寫性能，所以讀性能基本不會(huì)下降太多。NewSQL數(shù)據(jù)由于多副本、分布式事務(wù)等開(kāi)銷，相比單機(jī)關(guān)系數(shù)據(jù)庫(kù)SQL的響應(yīng)時(shí)間并不占優(yōu)，但由于集群的彈性擴(kuò)展，整體QPS提升還是很明顯的，這也是NewSQL數(shù)據(jù)庫(kù)廠商說(shuō)分布式數(shù)據(jù)庫(kù)更看重的是吞吐，而不是單筆SQL響應(yīng)時(shí)間的原因。
七、成熟度與生態(tài)
分布式數(shù)據(jù)庫(kù)是個(gè)新型通用底層軟件，準(zhǔn)確的衡量與評(píng)價(jià)需要一個(gè)多維度的測(cè)試模型，需包括發(fā)展現(xiàn)狀、使用情況、社區(qū)生態(tài)、監(jiān)控運(yùn)維、周邊配套工具、功能滿足度、DBA人才、SQL兼容性、性能測(cè)試、高可用測(cè)試、在線擴(kuò)容、分布式事務(wù)、隔離級(jí)別、在線DDL等等，雖然NewSQL數(shù)據(jù)庫(kù)發(fā)展經(jīng)過(guò)了一定時(shí)間檢驗(yàn)，但多集中在互聯(lián)網(wǎng)以及傳統(tǒng)企業(yè)非核心交易系統(tǒng)中，目前還處于快速迭代、規(guī)模使用不斷優(yōu)化完善的階段。相比而言，傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)則經(jīng)過(guò)了多年的發(fā)展，通過(guò)完整的評(píng)測(cè)，在成熟度、功能、性能、周邊生態(tài)、風(fēng)險(xiǎn)把控、相關(guān)人才積累等多方面都具有明顯優(yōu)勢(shì)，同時(shí)對(duì)已建系統(tǒng)的兼容性也更好。對(duì)于互聯(lián)網(wǎng)公司，數(shù)據(jù)量的增長(zhǎng)壓力以及追求新技術(shù)的基因會(huì)更傾向于嘗試NewSQL數(shù)據(jù)庫(kù)，不用再考慮庫(kù)表拆分、應(yīng)用改造、擴(kuò)容、事務(wù)一致性等問(wèn)題怎么看都是非常吸引人的方案。對(duì)于傳統(tǒng)企業(yè)例如銀行這種風(fēng)險(xiǎn)意識(shí)較高的行業(yè)來(lái)說(shuō)，NewSQL數(shù)據(jù)庫(kù)則可能在未來(lái)一段時(shí)間內(nèi)仍處于探索、審慎試點(diǎn)的階段。基于中間件+分庫(kù)分表模式架構(gòu)簡(jiǎn)單，技術(shù)門檻更低，雖然沒(méi)有NewSQL數(shù)據(jù)庫(kù)功能全面，但大部分場(chǎng)景最核心的訴求也就是拆分后SQL的正確路由，而此功能中間件模式應(yīng)對(duì)還是綽綽有余的，可以說(shuō)在大多數(shù)OLTP場(chǎng)景是夠用的。限于篇幅，其它特性例如在線DDL、數(shù)據(jù)遷移、運(yùn)維工具等特性就不在本文展開(kāi)對(duì)比。
八、總結(jié)
如果看完以上內(nèi)容，您還不知道選哪種模式，那么結(jié)合以下幾個(gè)問(wèn)題，先思考下NewSQL數(shù)據(jù)庫(kù)解決的點(diǎn)對(duì)于自身是不是真正的痛點(diǎn)：
強(qiáng)一致事務(wù)是否必須在數(shù)據(jù)庫(kù)層解決？
數(shù)據(jù)的增長(zhǎng)速度是否不可預(yù)估的？
擴(kuò)容的頻率是否已超出了自身運(yùn)維能力？
相比響應(yīng)時(shí)間更看重吞吐？
是否必須做到對(duì)應(yīng)用完全透明？
是否有熟悉NewSQL數(shù)據(jù)庫(kù)的DBA團(tuán)隊(duì)？
如果以上有兩到三個(gè)是肯定的，那么你可以考慮用NewSQL數(shù)據(jù)庫(kù)了，雖然前期可能需要一定的學(xué)習(xí)成本，但它是數(shù)據(jù)庫(kù)的發(fā)展方向，未來(lái)收益也會(huì)更高，尤其是互聯(lián)網(wǎng)行業(yè)，隨著數(shù)據(jù)量的突飛猛進(jìn)，分庫(kù)分表帶來(lái)的痛苦會(huì)與日俱增。當(dāng)然選擇NewSQL數(shù)據(jù)庫(kù)你也要做好承擔(dān)一定風(fēng)險(xiǎn)的準(zhǔn)備。如果你還未做出抉擇，不妨再想想下面幾個(gè)問(wèn)題：
最終一致性是否可以滿足實(shí)際場(chǎng)景？
數(shù)據(jù)未來(lái)幾年的總量是否可以預(yù)估？
擴(kuò)容、DDL等操作是否有系統(tǒng)維護(hù)窗口？
對(duì)響應(yīng)時(shí)間是否比吞吐更敏感？
是否需要兼容已有的關(guān)系數(shù)據(jù)庫(kù)系統(tǒng)？
是否已有傳統(tǒng)數(shù)據(jù)庫(kù)DBA人才的積累？
是否可容忍分庫(kù)分表對(duì)應(yīng)用的侵入？
如果這些問(wèn)題有多數(shù)是肯定的，那還是分庫(kù)分表吧。在軟件領(lǐng)域很少有完美的解決方案，NewSQL數(shù)據(jù)庫(kù)也不是數(shù)據(jù)分布式架構(gòu)的銀彈。相比而言分庫(kù)分表是一個(gè)代價(jià)更低、風(fēng)險(xiǎn)更小的方案，它更大程度復(fù)用傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)生態(tài)，通過(guò)中間件也可以滿足分庫(kù)分表后的絕大多數(shù)功能，定制化能力更強(qiáng)。在當(dāng)前NewSQL數(shù)據(jù)庫(kù)還未完全成熟的階段，分庫(kù)分表可以說(shuō)是一個(gè)上限低但下限高的方案，尤其傳統(tǒng)行業(yè)的核心系統(tǒng)，如果你仍然打算把數(shù)據(jù)庫(kù)當(dāng)做一個(gè)黑盒產(chǎn)品來(lái)用，踏踏實(shí)實(shí)用好分庫(kù)分表會(huì)被認(rèn)為是個(gè)穩(wěn)妥的選擇。
1 基本思想之什么是分庫(kù)分表？
從字面上簡(jiǎn)單理解，就是把原本存儲(chǔ)于一個(gè)庫(kù)的數(shù)據(jù)分塊存儲(chǔ)到多個(gè)庫(kù)上，把原本存儲(chǔ)于一個(gè)表的數(shù)據(jù)分塊存儲(chǔ)到多個(gè)表上。
2 基本思想之為什么要分庫(kù)分表？
數(shù)
據(jù)庫(kù)中的數(shù)據(jù)量不一定是可控的，在未進(jìn)行分庫(kù)分表的情況下，隨著時(shí)間和業(yè)務(wù)的發(fā)展，庫(kù)中的表會(huì)越來(lái)越多，表中的數(shù)據(jù)量也會(huì)越來(lái)越大，相應(yīng)地，數(shù)據(jù)操作，增
刪改查的開(kāi)銷也會(huì)越來(lái)越大；另外，由于無(wú)法進(jìn)行分布式式部署，而一臺(tái)服務(wù)器的資源（CPU、磁盤、內(nèi)存、IO等）是有限的，最終數(shù)據(jù)庫(kù)所能承載的數(shù)據(jù)量、
數(shù)據(jù)處理能力都將遭遇瓶頸。
3 分庫(kù)分表的實(shí)施策略。
分庫(kù)分表有垂直切分和水平切分兩種。
3.1
何謂垂直切分，即將表按照功能模塊、關(guān)系密切程度劃分出來(lái)，部署到不同的庫(kù)上。例如，我們會(huì)建立定義數(shù)據(jù)庫(kù)workDB、商品數(shù)據(jù)庫(kù)payDB、用戶數(shù)據(jù)
庫(kù)userDB、日志數(shù)據(jù)庫(kù)logDB等，分別用于存儲(chǔ)項(xiàng)目數(shù)據(jù)定義表、商品定義表、用戶數(shù)據(jù)表、日志數(shù)據(jù)表等。
3.2
何謂水平切分，當(dāng)一個(gè)表中的數(shù)據(jù)量過(guò)大時(shí)，我們可以把該表的數(shù)據(jù)按照某種規(guī)則，例如userID散列，進(jìn)行劃分，然后存儲(chǔ)到多個(gè)結(jié)構(gòu)相同的表，和不同的庫(kù)
上。例如，我們的userDB中的用戶數(shù)據(jù)表中，每一個(gè)表的數(shù)據(jù)量都很大，就可以把userDB切分為結(jié)構(gòu)相同的多個(gè)userDB：part0DB、
part1DB等，再將userDB上的用戶數(shù)據(jù)表userTable，切分為很多userTable：userTable0、userTable1等，
然后將這些表按照一定的規(guī)則存儲(chǔ)到多個(gè)userDB上。
3.3 應(yīng)該使用哪一種方式來(lái)實(shí)施數(shù)據(jù)庫(kù)分庫(kù)分表，這要看數(shù)據(jù)庫(kù)中數(shù)據(jù)量的瓶頸所在，并綜合項(xiàng)目的業(yè)務(wù)類型進(jìn)行考慮。
如果數(shù)據(jù)庫(kù)是因?yàn)楸硖喽斐珊Ａ繑?shù)據(jù)，并且項(xiàng)目的各項(xiàng)業(yè)務(wù)邏輯劃分清晰、低耦合，那么規(guī)則簡(jiǎn)單明了、容易實(shí)施的垂直切分必是首選。
而
如果數(shù)據(jù)庫(kù)中的表并不多，但單表的數(shù)據(jù)量很大、或數(shù)據(jù)熱度很高，這種情況之下就應(yīng)該選擇水平切分，水平切分比垂直切分要復(fù)雜一些，它將原本邏輯上屬于一體
的數(shù)據(jù)進(jìn)行了物理分割，除了在分割時(shí)要對(duì)分割的粒度做好評(píng)估，考慮數(shù)據(jù)平均和負(fù)載平均，后期也將對(duì)項(xiàng)目人員及應(yīng)用程序產(chǎn)生額外的數(shù)據(jù)管理負(fù)擔(dān)。
在現(xiàn)實(shí)項(xiàng)目中，往往是這兩種情況兼而有之，這就需要做出權(quán)衡，甚至既需要垂直切分，又需要水平切分。我們的游戲項(xiàng)目便綜合使用了垂直與水平切分，我們首先對(duì)數(shù)據(jù)庫(kù)進(jìn)行垂直切分，然后，再針對(duì)一部分表，通常是用戶數(shù)據(jù)表，進(jìn)行水平切分。
4 分庫(kù)分表存在的問(wèn)題。
4.1 事務(wù)問(wèn)題。
在執(zhí)行分庫(kù)分表之后，由于數(shù)據(jù)存儲(chǔ)到了不同的庫(kù)上，數(shù)據(jù)庫(kù)事務(wù)管理出現(xiàn)了困難。如果依賴數(shù)據(jù)庫(kù)本身的分布式事務(wù)管理功能去執(zhí)行事務(wù)，將付出高昂的性能代價(jià)；如果由應(yīng)用程序去協(xié)助控制，形成程序邏輯上的事務(wù)，又會(huì)造成編程方面的負(fù)擔(dān)。
4.2 跨庫(kù)跨表的join問(wèn)題。
在執(zhí)行了分庫(kù)分表之后，難以避免會(huì)將原本邏輯關(guān)聯(lián)性很強(qiáng)的數(shù)據(jù)劃分到不同的表、不同的庫(kù)上，這時(shí)，表的關(guān)聯(lián)操作將受到限制，我們無(wú)法join位于不同分庫(kù)的表，也無(wú)法join分表粒度不同的表，結(jié)果原本一次查詢能夠完成的業(yè)務(wù)，可能需要多次查詢才能完成。
4.3 額外的數(shù)據(jù)管理負(fù)擔(dān)和數(shù)據(jù)運(yùn)算壓力。
額
外的數(shù)據(jù)管理負(fù)擔(dān)，最顯而易見(jiàn)的就是數(shù)據(jù)的定位問(wèn)題和數(shù)據(jù)的增刪改查的重復(fù)執(zhí)行問(wèn)題，這些都可以通過(guò)應(yīng)用程序解決，但必然引起額外的邏輯運(yùn)算，例如，對(duì)于
一個(gè)記錄用戶成績(jī)的用戶數(shù)據(jù)表userTable，業(yè)務(wù)要求查出成績(jī)更好的100位，在進(jìn)行分表之前，只需一個(gè)order
by語(yǔ)句就可以搞定，但是在進(jìn)行分表之后，將需要n個(gè)order
by語(yǔ)句，分別查出每一個(gè)分表的前100名用戶數(shù)據(jù)，然后再對(duì)這些數(shù)據(jù)進(jìn)行合并計(jì)算，才能得出結(jié)果。
TiDB 社區(qū)（AskTUG）
樓上說(shuō)的很對(duì)，傳統(tǒng)關(guān)系型數(shù)據(jù)當(dāng)數(shù)據(jù)量達(dá)到一定程度，但是還存在一定要查詢的數(shù)據(jù)，只能將數(shù)據(jù)拆分，要嘛就是引用其他數(shù)據(jù)庫(kù)來(lái)分擔(dān) 傳統(tǒng)數(shù)據(jù)庫(kù)的壓力，然而，數(shù)據(jù)的校驗(yàn)和遷移又是一個(gè)很繁瑣很耗時(shí)耗力的工作
所以 TiDB 應(yīng)運(yùn)而生，完美解決傳統(tǒng)數(shù)據(jù)庫(kù)分庫(kù)分表的麻煩，具體看下官網(wǎng)，
TiDB 官網(wǎng)
簡(jiǎn)述分布式數(shù)據(jù)庫(kù)的模式結(jié)構(gòu)
布式數(shù)據(jù)庫(kù)系統(tǒng)通常使用較小的計(jì)算機(jī)系統(tǒng)，每臺(tái)計(jì)算機(jī)可單獨(dú)放在一個(gè)地方，每臺(tái)計(jì)算機(jī)中都有DBMS的一份完整拷貝副本，并具有自己局部的數(shù)據(jù)庫(kù)，位于不同地點(diǎn)的許多計(jì)算機(jī)通過(guò)網(wǎng)絡(luò)互相連接，共同組成一個(gè)完整的、全局的大型數(shù)據(jù)庫(kù)。
這種組織數(shù)據(jù)庫(kù)的方法克服了物理中心數(shù)據(jù)庫(kù)組織的弱點(diǎn)。首先，降低了數(shù)據(jù)傳送代價(jià)，因?yàn)榇蠖鄶?shù)的對(duì)數(shù)據(jù)庫(kù)的訪問(wèn)操作都是針對(duì)局部數(shù)據(jù)庫(kù)的，而不是對(duì)其他位置的數(shù)據(jù)庫(kù)訪問(wèn)；其次，系統(tǒng)的可靠性提高了很多，因?yàn)楫?dāng)網(wǎng)絡(luò)出現(xiàn)故障時(shí)，仍然允許對(duì)局部數(shù)據(jù)庫(kù)的操作，而且一個(gè)位置的故障不影響其他位置的處理工作，只有當(dāng)訪問(wèn)出現(xiàn)故障位置的數(shù)據(jù)時(shí)，在某種程度上才受影響；第三，便于系統(tǒng)的擴(kuò)充，增加一個(gè)新的局部數(shù)據(jù)庫(kù)，或在某個(gè)位置擴(kuò)充一臺(tái)適當(dāng)?shù)男⌒陀?jì)算機(jī)，都很容易實(shí)現(xiàn)。然而有些功能要付出更高的代價(jià)。例如，為了調(diào)配在幾個(gè)位置上的活動(dòng)，事務(wù)管理的性能比在中心數(shù)據(jù)庫(kù)時(shí)花費(fèi)更高，而且甚至抵消許多其他的優(yōu)點(diǎn)。
分布式數(shù)據(jù)庫(kù)系統(tǒng)主要特點(diǎn)：
· 多數(shù)處理就地完成；
· 各地的計(jì)算機(jī)由數(shù)據(jù)通信網(wǎng)絡(luò)相聯(lián)系。
· 克服了中心數(shù)據(jù)庫(kù)的弱點(diǎn)：降低了數(shù)據(jù)傳輸代價(jià)；
· 提高了系統(tǒng)的可靠性，局部系統(tǒng)發(fā)生故障，其他部分還可繼續(xù)工作；
· 各個(gè)數(shù)據(jù)庫(kù)的位置是透明的，方便系統(tǒng)的擴(kuò)充；
· 為了協(xié)調(diào)整個(gè)系統(tǒng)的事務(wù)活動(dòng)，事務(wù)管理的性能花費(fèi)高；
數(shù)據(jù)分片
類型：
（1）水平分片：按一定的條件把全局關(guān)系的所有元組劃分成若干不相交的子集，每個(gè)子集為關(guān)系的一個(gè)片段。
?。?）垂直分片：把一個(gè)全局關(guān)系的屬性集分成若干子集，并在這些子集上作投影運(yùn)算，每個(gè)投影稱為垂直分片。
?。?）導(dǎo)出分片：又稱為導(dǎo)出水平分片，即水平分片的條件不是本關(guān)系屬性的條件，而是其他關(guān)系屬性的條件。
?。?）混合分片：以上三種方法的混合?？梢韵人椒制俅怪狈制?，或先垂直分片再水平分片，或其他形式，但他們的結(jié)果是不相同的。
條件：
?。?）完備性條件：必須把全局關(guān)系的所有數(shù)據(jù)映射到片段中，決不允許有屬于全局關(guān)系的數(shù)據(jù)卻不屬于它的任何一個(gè)片段。
?。?）可重構(gòu)條件：必須保證能夠由同一個(gè)全局關(guān)系的各個(gè)片段來(lái)重建該全局關(guān)系。對(duì)于水平分片可用并操作重構(gòu)全局關(guān)系；對(duì)于垂直分片可用聯(lián)接操作重構(gòu)全局關(guān)系。
?。?）不相交條件：要求一個(gè)全局關(guān)系被分割后所得的各個(gè)數(shù)據(jù)片段互不重疊（對(duì)垂直分片的主鍵除外）。
數(shù)據(jù)分配方式
?。?）集中式：所有數(shù)據(jù)片段都安排在同一個(gè)場(chǎng)地上。
?。?）分割式：所有數(shù)據(jù)只有一份，它被分割成若干邏輯片段，每個(gè)邏輯片段被指派在一個(gè)特定的場(chǎng)地上。
?。?）全復(fù)制式：數(shù)據(jù)在每個(gè)場(chǎng)地重復(fù)存儲(chǔ)。也就是每個(gè)場(chǎng)地上都有一個(gè)完整的數(shù)據(jù)副本。
?。?）混合式：這是一種介乎于分割式和全復(fù)制式之間的分配方式。
目前分布式數(shù)據(jù)庫(kù)分配的設(shè)計(jì)，越來(lái)越多的采用尋找更優(yōu)解的算法，比如遺傳算法、退火機(jī)制等
查詢優(yōu)化
指在執(zhí)行分布式查詢時(shí)選擇查詢執(zhí)行計(jì)劃的方法和關(guān)系運(yùn)算符的實(shí)現(xiàn)算法。根據(jù)系統(tǒng)環(huán)境的不同，查詢優(yōu)化所使用的算法也有所不同，通常分為遠(yuǎn)程廣域網(wǎng)環(huán)境和高速局域網(wǎng)環(huán)境，其區(qū)別主要在網(wǎng)絡(luò)的帶寬。對(duì)于一元運(yùn)算符可以采用集中式數(shù)據(jù)庫(kù)中的查詢優(yōu)化方法。而對(duì)于二元運(yùn)算符，由于涉及場(chǎng)地間的數(shù)據(jù)傳輸，因此必須考慮通信代價(jià)。分布式查詢中常見(jiàn)的連接運(yùn)算執(zhí)行策略包括：
（1）半連接方法：利用半連接運(yùn)算的轉(zhuǎn)換方法R∞S=（RμS）∞S。假設(shè)場(chǎng)地1和場(chǎng)地2上分別有關(guān)系R和關(guān)系S，首先在S上執(zhí)行連接屬性上的投影并將結(jié)果傳輸至場(chǎng)地1，在場(chǎng)地1上執(zhí)行關(guān)系R與投影的連接操作，再將結(jié)果傳輸至場(chǎng)地2與關(guān)系S執(zhí)行連接操作。這種方法能夠降低執(zhí)行連接運(yùn)算時(shí)的網(wǎng)絡(luò)通信代價(jià)，主要適用于帶寬較低的遠(yuǎn)程廣域網(wǎng)絡(luò)。
?。?）枚舉法方法：指枚舉關(guān)系運(yùn)算符的物理執(zhí)行計(jì)劃，通過(guò)對(duì)比執(zhí)行計(jì)劃的代價(jià)選擇執(zhí)行算法的方法。其中，連接運(yùn)算符的物理執(zhí)行計(jì)劃包括嵌套循環(huán)方法、哈希連接法和歸并連接法。枚舉法主要適用于以磁盤IO代價(jià)為主的高速局域網(wǎng)環(huán)境。
分布式數(shù)據(jù)庫(kù)系統(tǒng)是在集中式數(shù)據(jù)庫(kù)系統(tǒng)的基礎(chǔ)上發(fā)展來(lái)的。是數(shù)據(jù)庫(kù)技術(shù)與網(wǎng)絡(luò)技術(shù)結(jié)合的產(chǎn)物?！ ∈裁词欠植际綌?shù)據(jù)庫(kù)： 分布式數(shù)據(jù)庫(kù)系統(tǒng)是在集中式數(shù)據(jù)庫(kù)系統(tǒng)的基礎(chǔ)上發(fā)展來(lái)的。是數(shù)據(jù)庫(kù)技術(shù)與網(wǎng)絡(luò)技術(shù)結(jié)合的產(chǎn)物?！ 》植际綌?shù)據(jù)庫(kù)系統(tǒng)有兩種：一種是物理上分布的，但邏輯上卻是集中的。這種分布式數(shù)據(jù)庫(kù)只適宜用途比較單一的、不大的單位或部門。另一種分布式數(shù)據(jù)庫(kù)系統(tǒng)在物理上和邏輯上都是分布的，也就是所謂聯(lián)邦式分布數(shù)據(jù)庫(kù)系統(tǒng)。由于組成聯(lián)邦的各個(gè)子數(shù)據(jù)庫(kù)系統(tǒng)是相對(duì)“自治”的，這種系統(tǒng)可以容納多種不同用途的、差異較大的數(shù)據(jù)庫(kù)，比較適宜于大范圍內(nèi)數(shù)據(jù)庫(kù)的集成?！ 》植际綌?shù)據(jù)庫(kù)系統(tǒng)(DDBS)包含分布式數(shù)據(jù)庫(kù)管理系統(tǒng)(DDBMS)和分布式數(shù)據(jù)庫(kù)(DDB)?！ ≡诜植际綌?shù)據(jù)庫(kù)系統(tǒng)中，一個(gè)應(yīng)用程序可以對(duì)數(shù)據(jù)庫(kù)進(jìn)行透明操作，數(shù)據(jù)庫(kù)中的數(shù)據(jù)分別在不同的局部數(shù)據(jù)庫(kù)中存儲(chǔ)、由不同的DBMS進(jìn)行管理、在不同的機(jī)器上運(yùn)行、由不同的操作系統(tǒng)支持、被不同的通信網(wǎng)絡(luò)連接在一起?！ ∫粋€(gè)分布式數(shù)據(jù)庫(kù)在邏輯上是一個(gè)統(tǒng)一的整體：即在用戶面前為單個(gè)邏輯數(shù)據(jù)庫(kù)，在物理上則是分別存儲(chǔ)在不同的物理節(jié)點(diǎn)上。一個(gè)應(yīng)用程序通過(guò)網(wǎng)絡(luò)的連接可以訪問(wèn)分布在不同地理位置的數(shù)據(jù)庫(kù)。它的分布性表現(xiàn)在數(shù)據(jù)庫(kù)中的數(shù)據(jù)不是存儲(chǔ)在同一場(chǎng)地。更確切地講，不存儲(chǔ)在同一計(jì)算機(jī)的存儲(chǔ)設(shè)備上。 這就是與集中式數(shù)據(jù)庫(kù)的區(qū)別。從用戶的角度看，一個(gè)分布式數(shù)據(jù)庫(kù)系統(tǒng)在邏輯上和集中式數(shù)據(jù)庫(kù)系統(tǒng)一樣，用戶可以在任何一個(gè)場(chǎng)地執(zhí)行全局應(yīng)用。就好那些數(shù)據(jù)是存儲(chǔ)在同一臺(tái)計(jì)算機(jī)上，有單個(gè)數(shù)據(jù)庫(kù)管理系統(tǒng)(DBMS)管理一樣，用戶并沒(méi)有什么感覺(jué)不一樣?！ 》植际綌?shù)據(jù)庫(kù)中每一個(gè)數(shù)據(jù)庫(kù)服務(wù)器合作地維護(hù)全局?jǐn)?shù)據(jù)庫(kù)的一致性?！ 》植际綌?shù)據(jù)庫(kù)系統(tǒng)是一個(gè)客戶/服務(wù)器體系結(jié)構(gòu)。
數(shù)據(jù)庫(kù) 分片的介紹就聊到這里吧，感謝你花時(shí)間閱讀本站內(nèi)容，更多關(guān)于數(shù)據(jù)庫(kù) 分片,深入探究數(shù)據(jù)庫(kù)分片技術(shù)，提高數(shù)據(jù)處理效率,數(shù)據(jù)庫(kù)為什么要分庫(kù)分表,簡(jiǎn)述分布式數(shù)據(jù)庫(kù)的模式結(jié)構(gòu)的信息別忘了在本站進(jìn)行查找喔。
成都創(chuàng)新互聯(lián)科技有限公司，經(jīng)過(guò)多年的不懈努力，公司現(xiàn)已經(jīng)成為一家專業(yè)從事IT產(chǎn)品開(kāi)發(fā)和營(yíng)銷公司。廣泛應(yīng)用于計(jì)算機(jī)網(wǎng)絡(luò)、設(shè)計(jì)、SEO優(yōu)化、關(guān)鍵詞排名等多種行業(yè)！
本文標(biāo)題：深入探究數(shù)據(jù)庫(kù)分片技術(shù)，提高數(shù)據(jù)處理效率(數(shù)據(jù)庫(kù)分片)
分享鏈接：http://www.fisionsoft.com.cn/article/coiihpd.html
