newsql和nosql的區(qū)別和聯(lián)系

在大數(shù)據(jù)時代，“多種架構(gòu)支持多類應(yīng)用”成為數(shù)據(jù)庫行業(yè)應(yīng)對大數(shù)據(jù)的基本思路，數(shù)據(jù)庫行業(yè)出現(xiàn)互為補充的三大陣營，適用于事務(wù)處理應(yīng)用的OldSQL、適用于數(shù)據(jù)分析應(yīng)用的NewSQL和適用于互聯(lián)網(wǎng)應(yīng)用的NoSQL。但在一些復(fù)雜的應(yīng)用場景中，單一數(shù)據(jù)庫架構(gòu)都不能完全滿足應(yīng)用場景對海量結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)的存儲管理、復(fù)雜分析、關(guān)聯(lián)查詢、實時性處理和控制建設(shè)成本等多方面的需要，因此不同架構(gòu)數(shù)據(jù)庫混合部署應(yīng)用成為滿足復(fù)雜應(yīng)用的必然選擇。不同架構(gòu)數(shù)據(jù)庫混合使用的模式可以概括為：OldSQL+NewSQL、OldSQL+NoSQL、NewSQL+NoSQL三種主要模式。下面通過三個案例對不同架構(gòu)數(shù)據(jù)庫的混合應(yīng)用部署進行介紹。

專注于為中小企業(yè)提供成都網(wǎng)站建設(shè)、網(wǎng)站制作服務(wù),電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)渝北免費做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了數(shù)千家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。

OldSQL+NewSQL 在數(shù)據(jù)中心類應(yīng)用中混合部署

采用OldSQL+NewSQL模式構(gòu)建數(shù)據(jù)中心，在充分發(fā)揮OldSQL數(shù)據(jù)庫的事務(wù)處理能力的同時，借助NewSQL在實時性、復(fù)雜分析、即席查詢等方面的獨特優(yōu)勢，以及面對海量數(shù)據(jù)時較強的擴展能力，滿足數(shù)據(jù)中心對當(dāng)前“熱”數(shù)據(jù)事務(wù)型處理和海量歷史“冷”數(shù)據(jù)分析兩方面的需求。OldSQL+NewSQL模式在數(shù)據(jù)中心類應(yīng)用中的互補作用體現(xiàn)在，OldSQL彌補了NewSQL不適合事務(wù)處理的不足，NewSQL彌補了OldSQL在海量數(shù)據(jù)存儲能力和處理性能方面的缺陷。

商業(yè)銀行數(shù)據(jù)中心采用OldSQL+NewSQL混合部署方式搭建，OldSQL數(shù)據(jù)庫滿足各業(yè)務(wù)系統(tǒng)數(shù)據(jù)的歸檔備份和事務(wù)型應(yīng)用，NewSQL MPP數(shù)據(jù)庫集群對即席查詢、多維分析等應(yīng)用提供高性能支持，并且通過MPP集群架構(gòu)實現(xiàn)應(yīng)對海量數(shù)據(jù)存儲的擴展能力。

商業(yè)銀行數(shù)據(jù)中心存儲架構(gòu)

與傳統(tǒng)的OldSQL模式相比，商業(yè)銀行數(shù)據(jù)中心采用OldSQL+NewSQL混合搭建模式，數(shù)據(jù)加載性能提升3倍以上，即席查詢和統(tǒng)計分析性能提升6倍以上。NewSQL MPP的高可擴展性能夠應(yīng)對新的業(yè)務(wù)需求，可隨著數(shù)據(jù)量的增長采用集群方式構(gòu)建存儲容量更大的數(shù)據(jù)中心。

OldSQL+NoSQL 在互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用中混合部署

在互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用中采用OldSQL+NoSQL混合模式，能夠很好的解決互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用對海量結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)進行存儲和快速處理的需求。在諸如大型電子商務(wù)平臺、大型SNS平臺等互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用場景中，OldSQL在應(yīng)用中負責(zé)高價值密度結(jié)構(gòu)化數(shù)據(jù)的存儲和事務(wù)型處理，NoSQL在應(yīng)用中負責(zé)存儲和處理海量非結(jié)構(gòu)化的數(shù)據(jù)和低價值密度結(jié)構(gòu)化數(shù)據(jù)。OldSQL+NoSQL模式在互聯(lián)網(wǎng)大數(shù)據(jù)應(yīng)用中的互補作用體現(xiàn)在，OldSQL彌補了NoSQL在ACID特性和復(fù)雜關(guān)聯(lián)運算方面的不足，NoSQL彌補了OldSQL在海量數(shù)據(jù)存儲和非結(jié)構(gòu)化數(shù)據(jù)處理方面的缺陷。

數(shù)據(jù)魔方是淘寶網(wǎng)的一款數(shù)據(jù)產(chǎn)品，主要提供行業(yè)數(shù)據(jù)分析、店鋪數(shù)據(jù)分析。淘寶數(shù)據(jù)產(chǎn)品在存儲層采用OldSQL+NoSQL混合模式，由基于MySQL的分布式關(guān)系型數(shù)據(jù)庫集群MyFOX和基于HBase的NoSQL存儲集群Prom組成。由于OldSQL強大的語義和關(guān)系表達能力，在應(yīng)用中仍然占據(jù)著重要地位，目前存儲在MyFOX中的統(tǒng)計結(jié)果數(shù)據(jù)已經(jīng)達到10TB，占據(jù)著數(shù)據(jù)魔方總數(shù)據(jù)量的95%以上。另一方面，NoSQL作為SQL的有益補充，解決了OldSQL數(shù)據(jù)庫無法解決的全屬性選擇器等問題。

淘寶海量數(shù)據(jù)產(chǎn)品技術(shù)架構(gòu)

基于OldSQL+NoSQL混合架構(gòu)的特點，數(shù)據(jù)魔方目前已經(jīng)能夠提供壓縮前80TB的數(shù)據(jù)存儲空間，支持每天4000萬的查詢請求，平均響應(yīng)時間在28毫秒，足以滿足未來一段時間內(nèi)的業(yè)務(wù)增長需求。

NewSQL+NoSQL 在行業(yè)大數(shù)據(jù)應(yīng)用中混合部署

行業(yè)大數(shù)據(jù)與互聯(lián)網(wǎng)大數(shù)據(jù)的區(qū)別在于行業(yè)大數(shù)據(jù)的價值密度更高，并且對結(jié)構(gòu)化數(shù)據(jù)的實時處理、復(fù)雜的多表關(guān)聯(lián)分析、即席查詢、數(shù)據(jù)強一致性等都比互聯(lián)網(wǎng)大數(shù)據(jù)有更高的要求。行業(yè)大數(shù)據(jù)應(yīng)用場景主要是分析類應(yīng)用，如：電信、金融、政務(wù)、能源等行業(yè)的決策輔助、預(yù)測預(yù)警、統(tǒng)計分析、經(jīng)營分析等。

在行業(yè)大數(shù)據(jù)應(yīng)用中采用NewSQL+NoSQL混合模式，充分利用NewSQL在結(jié)構(gòu)化數(shù)據(jù)分析處理方面的優(yōu)勢，以及NoSQL在非結(jié)構(gòu)數(shù)據(jù)處理方面的優(yōu)勢，實現(xiàn)NewSQL與NoSQL的功能互補，解決行業(yè)大數(shù)據(jù)應(yīng)用對高價值結(jié)構(gòu)化數(shù)據(jù)的實時處理、復(fù)雜的多表關(guān)聯(lián)分析、即席查詢、數(shù)據(jù)強一致性等要求，以及對海量非結(jié)構(gòu)化數(shù)據(jù)存儲和精確查詢的要求。在應(yīng)用中，NewSQL承擔(dān)高價值密度結(jié)構(gòu)化數(shù)據(jù)的存儲和分析處理工作，NoSQL承擔(dān)存儲和處理海量非結(jié)構(gòu)化數(shù)據(jù)和不需要關(guān)聯(lián)分析、Ad-hoc查詢較少的低價值密度結(jié)構(gòu)化數(shù)據(jù)的工作。

當(dāng)前電信運營商在集中化BI系統(tǒng)建設(shè)過程中面臨著數(shù)據(jù)規(guī)模大、數(shù)據(jù)處理類型多等問題，并且需要應(yīng)對大量的固定應(yīng)用，以及占統(tǒng)計總數(shù)80%以上的突發(fā)性臨時統(tǒng)計(ad-hoc)需求。在集中化BI系統(tǒng)的建設(shè)中采用NewSQL+NoSQL混搭的模式，充分利用NewSQL在復(fù)雜分析、即席查詢等方面處理性能的優(yōu)勢，及NoSQL在非結(jié)構(gòu)化數(shù)據(jù)處理和海量數(shù)據(jù)存儲方面的優(yōu)勢，實現(xiàn)高效低成本。

集中化BI系統(tǒng)數(shù)據(jù)存儲架構(gòu)

集中化BI系統(tǒng)按照數(shù)據(jù)類型和處理方式的不同，將結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)分別存儲在不同的系統(tǒng)中：非結(jié)構(gòu)化數(shù)據(jù)在Hadoop平臺上存儲與處理;結(jié)構(gòu)化、不需要關(guān)聯(lián)分析、Ad-hoc查詢較少的數(shù)據(jù)保存在NoSQL數(shù)據(jù)庫或Hadoop平臺;結(jié)構(gòu)化、需要關(guān)聯(lián)分析或經(jīng)常ad-hoc查詢的數(shù)據(jù)，保存在NewSQL MPP數(shù)據(jù)庫中，短期高價值數(shù)據(jù)放在高性能平臺，中長期放在低成本產(chǎn)品中。

結(jié)語

當(dāng)前信息化應(yīng)用的多樣性、復(fù)雜性，以及三種數(shù)據(jù)庫架構(gòu)各自所具有的優(yōu)勢和局限性，造成任何一種架構(gòu)的數(shù)據(jù)庫都不能完全滿足應(yīng)用需求，因此不同架構(gòu)數(shù)據(jù)庫混合使用，從而彌補其他架構(gòu)的不足成為必然選擇。根據(jù)應(yīng)用場景采用不同架構(gòu)數(shù)據(jù)庫進行組合搭配，充分發(fā)揮每種架構(gòu)數(shù)據(jù)庫的特點和優(yōu)勢，并且與其他架構(gòu)數(shù)據(jù)庫形成互補，完全涵蓋應(yīng)用需求，保證數(shù)據(jù)資源的最優(yōu)化利用，將成為未來一段時期內(nèi)信息化應(yīng)用主要采用的解決方式。

目前在國內(nèi)市場上，OldSQL主要為Oracle、IBM等國外數(shù)據(jù)庫廠商所壟斷，達夢、金倉等國產(chǎn)廠商仍處于追趕狀態(tài);南大通用憑借國產(chǎn)新型數(shù)據(jù)庫GBase 8a異軍突起，與EMC的Greenplum和HP的Vertica躋身NewSQL市場三強;NoSQL方面用戶則大多采用Hadoop開源方案。

nosql是什么

NoSQL，泛指非關(guān)系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應(yīng)付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問題，而非關(guān)系型的數(shù)據(jù)庫則由于其本身的特點得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重數(shù)據(jù)種類帶來的挑戰(zhàn)，尤其是大數(shù)據(jù)應(yīng)用難題。

雖然NoSQL流行語火起來才短短一年的時間，但是不可否認，現(xiàn)在已經(jīng)開始了第二代運動。盡管早期的堆棧代碼只能算是一種實驗，然而現(xiàn)在的系統(tǒng)已經(jīng)更加的成熟、穩(wěn)定。不過現(xiàn)在也面臨著一個嚴酷的事實：技術(shù)越來越成熟——以至于原來很好的NoSQL數(shù)據(jù)存儲不得不進行重寫，也有少數(shù)人認為這就是所謂的2.0版本。這里列出一些比較知名的工具，可以為大數(shù)據(jù)建立快速、可擴展的存儲庫。

NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，是一項全新的數(shù)據(jù)庫革命性運動，早期就有人提出，發(fā)展至2009年趨勢越發(fā)高漲。NoSQL的擁護者們提倡運用非關(guān)系型的數(shù)據(jù)存儲，相對于鋪天蓋地的關(guān)系型數(shù)據(jù)庫運用，這一概念無疑是一種全新的思維的注入。

對于NoSQL并沒有一個明確的范圍和定義，但是他們都普遍存在下面一些共同特征：

不需要預(yù)定義模式：不需要事先定義數(shù)據(jù)模式，預(yù)定義表結(jié)構(gòu)。數(shù)據(jù)中的每條記錄都可能有不同的屬性和格式。當(dāng)插入數(shù)據(jù)時，并不需要預(yù)先定義它們的模式。

無共享架構(gòu)：相對于將所有數(shù)據(jù)存儲的存儲區(qū)域網(wǎng)絡(luò)中的全共享架構(gòu)。NoSQL往往將數(shù)據(jù)劃分后存儲在各個本地服務(wù)器上。因為從本地磁盤讀取數(shù)據(jù)的性能往往好于通過網(wǎng)絡(luò)傳輸讀取數(shù)據(jù)的性能，從而提高了系統(tǒng)的性能。

彈性可擴展：可以在系統(tǒng)運行的時候，動態(tài)增加或者刪除結(jié)點。不需要停機維護，數(shù)據(jù)可以自動遷移。

分區(qū)：相對于將數(shù)據(jù)存放于同一個節(jié)點，NoSQL數(shù)據(jù)庫需要將數(shù)據(jù)進行分區(qū)，將記錄分散在多個節(jié)點上面。并且通常分區(qū)的同時還要做復(fù)制。這樣既提高了并行性能，又能保證沒有單點失效的問題。

異步復(fù)制：和RAID存儲系統(tǒng)不同的是，NoSQL中的復(fù)制，往往是基于日志的異步復(fù)制。這樣，數(shù)據(jù)就可以盡快地寫入一個節(jié)點，而不會被網(wǎng)絡(luò)傳輸引起遲延。缺點是并不總是能保證一致性，這樣的方式在出現(xiàn)故障的時候，可能會丟失少量的數(shù)據(jù)。

BASE：相對于事務(wù)嚴格的ACID特性，NoSQL數(shù)據(jù)庫保證的是BASE特性。BASE是最終一致性和軟事務(wù)。

NoSQL數(shù)據(jù)庫并沒有一個統(tǒng)一的架構(gòu)，兩種NoSQL數(shù)據(jù)庫之間的不同，甚至遠遠超過兩種關(guān)系型數(shù)據(jù)庫的不同?？梢哉f，NoSQL各有所長，成功的NoSQL必然特別適用于某些場合或者某些應(yīng)用，在這些場合中會遠遠勝過關(guān)系型數(shù)據(jù)庫和其他的NoSQL。

一個大型、穩(wěn)健、成熟的分布式系統(tǒng)的背后，往往會涉及眾多的支撐系統(tǒng)基礎(chǔ)設(shè)施？

樹苗中2包是需要混合浸泡嗎？一個大型、穩(wěn)健、成熟的分布式系統(tǒng)的背后，往往會涉及眾多的支撐系統(tǒng)，我們將這些支撐系統(tǒng)稱為分布式系統(tǒng)的基礎(chǔ)設(shè)施。除了前面所介紹的分布式協(xié)作及配置管理系統(tǒng)ZooKeeper,我們進行系統(tǒng)架構(gòu)設(shè)計所依賴的基礎(chǔ)設(shè)施，還包括分布式緩存系統(tǒng)、持久化存儲、分布式消息系統(tǒng)、搜索引擎，以及CDN系統(tǒng)、負載均衡系統(tǒng)、運維自動化系統(tǒng)等，還有后面章節(jié)所要介紹的實時計算系統(tǒng)、離線計算系統(tǒng)、分布式文件系統(tǒng)、日志收集系統(tǒng)、監(jiān)控系統(tǒng)、數(shù)據(jù)倉庫等。

分布式緩存主要用于在高并發(fā)環(huán)境下，減輕數(shù)據(jù)庫的壓力，提高系統(tǒng)的響應(yīng)速度和并發(fā)吞吐。當(dāng)大量的讀、寫請求涌向數(shù)據(jù)庫時，磁盤的處理速度與內(nèi)存顯然不在一個量級，因此，在數(shù)據(jù)庫之前加一層緩存，能夠顯著提高系統(tǒng)的響應(yīng)速度，并降低數(shù)據(jù)庫的壓力。作為傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，MySQL提供完整的ACID操作，支持豐富的數(shù)據(jù)類型、強大的關(guān)聯(lián)查詢、where語句等，能夠非?？鸵椎亟⒉樵兯饕?，執(zhí)行復(fù)雜的內(nèi)連接、外連接、求和、排序、分組等操作，并且支持存儲過程、函數(shù)等功能，產(chǎn)品成熟度高，功能強大。但是，對于需要應(yīng)對高并發(fā)訪問并且存儲海量數(shù)據(jù)的場景來說，出于對性能的考慮，不得不放棄很多傳統(tǒng)關(guān)系型數(shù)據(jù)庫原本強大的功能，犧牲了系統(tǒng)的易用性，并且使得系統(tǒng)的設(shè)計和管理變得更為復(fù)雜。這也使得在過去幾年中，流行著另一種新的存儲解決方案——NoSQL，它與傳統(tǒng)的關(guān)系型數(shù)據(jù)庫最大的差別在于，它不使用SQL作為查詢語言來查找數(shù)據(jù)，而采用key-value形式進行查找，提供了更高的查詢效率及吞吐，并且能夠更加方便地進行擴展，存儲海量數(shù)據(jù)，在數(shù)千個節(jié)點上進行分區(qū)，自動進行數(shù)據(jù)的復(fù)制和備份。在分布式系統(tǒng)中，消息作為應(yīng)用間通信的一種方式，得到了十分廣泛的應(yīng)用。消息可以被保存在隊列中，直到被接收者取出，由于消息發(fā)送者不需要同步等待消息接收者的響應(yīng)，消息的異步接收降低了系統(tǒng)集成的耦合度，提升了分布式系統(tǒng)協(xié)作的效率，使得系統(tǒng)能夠更快地響應(yīng)用戶，提供更高的吞吐。

當(dāng)系統(tǒng)處于峰值壓力時，分布式消息隊列還能夠作為緩沖，削峰填谷，緩解集群的壓力，避免整個系統(tǒng)被壓垮。垂直化的搜索引擎在分布式系統(tǒng)中是一個非常重要的角色，它既能夠滿足用戶對于全文檢索、模糊匹配的需求，解決數(shù)據(jù)庫like查詢效率低下的問題，又能夠解決分布式環(huán)境下，由于采用分庫分表，或者使用NoSQL數(shù)據(jù)庫，導(dǎo)致無法進行多表關(guān)聯(lián)或者進行復(fù)雜查詢的問題。

分庫分表 VS newsql數(shù)據(jù)庫

最近與同行 科技 交流，經(jīng)常被問到分庫分表與分布式數(shù)據(jù)庫如何選擇，網(wǎng)上也有很多關(guān)于中間件+傳統(tǒng)關(guān)系數(shù)據(jù)庫（分庫分表）與NewSQL分布式數(shù)據(jù)庫的文章，但有些觀點與判斷是我覺得是偏激的，脫離環(huán)境去評價方案好壞其實有失公允。

本文通過對兩種模式關(guān)鍵特性實現(xiàn)原理對比，希望可以盡可能客觀、中立的闡明各自真實的優(yōu)缺點以及適用場景。

首先關(guān)于“中間件+關(guān)系數(shù)據(jù)庫分庫分表”算不算NewSQL分布式數(shù)據(jù)庫問題，國外有篇論文pavlo-newsql-sigmodrec，如果根據(jù)該文中的分類，Spanner、TiDB、OB算是第一種新架構(gòu)型，Sharding-Sphere、Mycat、DRDS等中間件方案算是第二種（文中還有第三種云數(shù)據(jù)庫，本文暫不詳細介紹）。

基于中間件（包括SDK和Proxy兩種形式）+傳統(tǒng)關(guān)系數(shù)據(jù)庫（分庫分表）模式是不是分布式架構(gòu)？我覺得是的，因為存儲確實也分布式了，也能實現(xiàn)橫向擴展。但是不是"偽"分布式數(shù)據(jù)庫？從架構(gòu)先進性來看，這么說也有一定道理。"偽"主要體現(xiàn)在中間件層與底層DB重復(fù)的SQL解析與執(zhí)行計劃生成、存儲引擎基于B+Tree等，這在分布式數(shù)據(jù)庫架構(gòu)中實際上冗余低效的。為了避免引起真?zhèn)畏植际綌?shù)據(jù)庫的口水戰(zhàn)，本文中NewSQL數(shù)據(jù)庫特指這種新架構(gòu)NewSQL數(shù)據(jù)庫。

NewSQL數(shù)據(jù)庫相比中間件+分庫分表的先進在哪兒？畫一個簡單的架構(gòu)對比圖：

這些大多也是NewSQL數(shù)據(jù)庫產(chǎn)品主要宣傳的點，不過這些看起來很美好的功能是否真的如此？接下來針對以上幾點分別闡述下的我的理解。

這是把雙刃劍。

CAP限制

想想更早些出現(xiàn)的NoSQL數(shù)據(jù)庫為何不支持分布式事務(wù)（最新版的mongoDB等也開始支持了），是缺乏理論與實踐支撐嗎？并不是，原因是CAP定理依然是分布式數(shù)據(jù)庫頭上的頸箍咒，在保證強一致的同時必然會犧牲可用性A或分區(qū)容忍性P。為什么大部分NoSQL不提供分布式事務(wù)？

那么NewSQL數(shù)據(jù)庫突破CAP定理限制了嗎？并沒有。NewSQL數(shù)據(jù)庫的鼻主Google Spanner（目前絕大部分分布式數(shù)據(jù)庫都是按照Spanner架構(gòu)設(shè)計的）提供了一致性和大于5個9的可用性，宣稱是一個“實際上是CA”的，其真正的含義是 系統(tǒng)處于 CA 狀態(tài)的概率非常高，由于網(wǎng)絡(luò)分區(qū)導(dǎo)致的服務(wù)停用的概率非常小 ，究其真正原因是其打造私有全球網(wǎng)保證了不會出現(xiàn)網(wǎng)絡(luò)中斷引發(fā)的網(wǎng)絡(luò)分區(qū)，另外就是其高效的運維隊伍,這也是cloud spanner的賣點。詳細可見CAP提出者Eric Brewer寫的《Spanner, TrueTime 和CAP理論》。

完備性 ：

兩階段提交協(xié)議是否嚴格支持ACID，各種異常場景是不是都可以覆蓋？

2PC在commit階段發(fā)送異常，其實跟最大努力一階段提交類似也會有部分可見問題，嚴格講一段時間內(nèi)并不能保證A原子性和C一致性（待故障恢復(fù)后recovery機制可以保證最終的A和C）。完備的分布式事務(wù)支持并不是一件簡單的事情，需要可以應(yīng)對網(wǎng)絡(luò)以及各種硬件包括網(wǎng)卡、磁盤、CPU、內(nèi)存、電源等各類異常，通過嚴格的測試。之前跟某友商交流，他們甚至說目前已知的NewSQL在分布式事務(wù)支持上都是不完整的，他們都有案例跑不過，圈內(nèi)人士這么篤定，也說明了 分布式事務(wù)的支持完整程度其實是層次不齊的。

但分布式事務(wù)又是這些NewSQL數(shù)據(jù)庫的一個非常重要的底層機制，跨資源的DML、DDL等都依賴其實現(xiàn)，如果這塊的性能、完備性打折扣，上層跨分片SQL執(zhí)行的正確性會受到很大影響。

性能

傳統(tǒng)關(guān)系數(shù)據(jù)庫也支持分布式事務(wù)XA，但為何很少有高并發(fā)場景下用呢？ 因為XA的基礎(chǔ)兩階段提交協(xié)議存在網(wǎng)絡(luò)開銷大，阻塞時間長、死鎖等問題，這也導(dǎo)致了其實際上很少大規(guī)模用在基于傳統(tǒng)關(guān)系數(shù)據(jù)庫的OLTP系統(tǒng)中。

NewSQL數(shù)據(jù)庫的分布式事務(wù)實現(xiàn)也仍然多基于兩階段提交協(xié)議，例如google percolator分布式事務(wù)模型，

采用原子鐘+MVCC+ Snapshot Isolation（SI），這種方式通過TSO(Timestamp Oracle)保證了全局一致性，通過MVCC避免了鎖，另外通過primary lock和secondary lock將提交的一部分轉(zhuǎn)為異步，相比XA確實提高了分布式事務(wù)的性能。

但不管如何優(yōu)化，相比于1PC，2PC多出來的GID獲取、網(wǎng)絡(luò)開銷、prepare日志持久化還是會帶來很大的性能損失，尤其是跨節(jié)點的數(shù)量比較多時會更加顯著，例如在銀行場景做個批量扣款，一個文件可能上W個賬戶，這樣的場景無論怎么做還是吞吐都不會很高。

雖然NewSQL分布式數(shù)據(jù)庫產(chǎn)品都宣傳完備支持分布式事務(wù)，但這并不是說應(yīng)用可以完全不用關(guān)心數(shù)據(jù)拆分，這些數(shù)據(jù)庫的最佳實踐中仍然會寫到，應(yīng)用的大部分場景盡可能避免分布式事務(wù)。

既然強一致事務(wù)付出的性能代價太大，我們可以反思下是否真的需要這種強一致的分布式事務(wù)？尤其是在做微服務(wù)拆分后，很多系統(tǒng)也不太可能放在一個統(tǒng)一的數(shù)據(jù)庫中。嘗試將一致性要求弱化，便是柔性事務(wù)，放棄ACID(Atomicity,Consistency, Isolation, Durability)，轉(zhuǎn)投BASE(Basically Available,Soft state,Eventually consistent)，例如Saga、TCC、可靠消息保證最終一致等模型，對于大規(guī)模高并發(fā)OLTP場景，我個人更建議使用柔性事務(wù)而非強一致的分布式事務(wù)。關(guān)于柔性事務(wù)，筆者之前也寫過一個技術(shù)組件，最近幾年也涌現(xiàn)出了一些新的模型與框架（例如阿里剛開源的Fescar），限于篇幅不再贅述，有空再單獨寫篇文章。

HA與異地多活

主從模式并不是最優(yōu)的方式，就算是半同步復(fù)制，在極端情況下（半同步轉(zhuǎn)異步）也存在丟數(shù)問題，目前業(yè)界公認更好的方案是基于paxos分布式一致性協(xié)議或者其它類paxos如raft方式，Google Spanner、TiDB、cockcoachDB、OB都采用了這種方式，基于Paxos協(xié)議的多副本存儲，遵循過半寫原則，支持自動選主，解決了數(shù)據(jù)的高可靠，縮短了failover時間，提高了可用性，特別是減少了運維的工作量，這種方案技術(shù)上已經(jīng)很成熟，也是NewSQL數(shù)據(jù)庫底層的標(biāo)配。

當(dāng)然這種方式其實也可以用在傳統(tǒng)關(guān)系數(shù)據(jù)庫，阿里、微信團隊等也有將MySQL存儲改造支持paxos多副本的，MySQL也推出了官方版MySQL Group Cluster，預(yù)計不遠的未來主從模式可能就成為 歷史 了。

需要注意的是很多NewSQL數(shù)據(jù)庫廠商宣傳基于paxos或raft協(xié)議可以實現(xiàn)【異地多活】，這個實際上是有前提的，那就是異地之間網(wǎng)絡(luò)延遲不能太高 。以銀行“兩地三中心”為例，異地之間多相隔數(shù)千里，延時達到數(shù)十毫秒，如果要多活，那便需異地副本也參與數(shù)據(jù)庫日志過半確認，這樣高的延時幾乎沒有OLTP系統(tǒng)可以接受的。

數(shù)據(jù)庫層面做異地多活是個美好的愿景，但距離導(dǎo)致的延時目前并沒有好的方案。 之前跟螞蟻團隊交流，螞蟻異地多活的方案是在應(yīng)用層通過MQ同步雙寫交易信息，異地DC將交易信息保存在分布式緩存中，一旦發(fā)生異地切換，數(shù)據(jù)庫同步中間件會告之?dāng)?shù)據(jù)延遲時間，應(yīng)用從緩存中讀取交易信息，將這段時間內(nèi)涉及到的業(yè)務(wù)對象例如用戶、賬戶進行黑名單管理，等數(shù)據(jù)同步追上之后再將這些業(yè)務(wù)對象從黑名單中剔除。由于雙寫的不是所有數(shù)據(jù)庫操作日志而只是交易信息，數(shù)據(jù)延遲只影響一段時間內(nèi)數(shù)據(jù)，這是目前我覺得比較靠譜的異地度多活方案。

另外有些系統(tǒng)進行了單元化改造，這在paxos選主時也要結(jié)合考慮進去，這也是目前很多NewSQL數(shù)據(jù)庫欠缺的功能。

Scale橫向擴展與分片機制

paxos算法解決了高可用、高可靠問題，并沒有解決Scale橫向擴展的問題，所以分片是必須支持的。NewSQL數(shù)據(jù)庫都是天生內(nèi)置分片機制的，而且會根據(jù)每個分片的數(shù)據(jù)負載(磁盤使用率、寫入速度等)自動識別熱點，然后進行分片的分裂、數(shù)據(jù)遷移、合并，這些過程應(yīng)用是無感知的，這省去了DBA的很多運維工作量。以TiDB為例，它將數(shù)據(jù)切成region，如果region到64M時，數(shù)據(jù)自動進行遷移。

分庫分表模式下需要應(yīng)用設(shè)計之初就要明確各表的拆分鍵、拆分方式（range、取模、一致性哈?；蛘咦远x路由表）、路由規(guī)則、拆分庫表數(shù)量、擴容方式等。相比NewSQL數(shù)據(jù)庫，這種模式給應(yīng)用帶來了很大侵入和復(fù)雜度，這對大多數(shù)系統(tǒng)來說也是一大挑戰(zhàn)。

這里有個問題是NewSQL數(shù)據(jù)庫統(tǒng)一的內(nèi)置分片策略（例如tidb基于range）可能并不是最高效的，因為與領(lǐng)域模型中的劃分要素并不一致，這導(dǎo)致的后果是很多交易會產(chǎn)生分布式事務(wù)。 舉個例子，銀行核心業(yè)務(wù)系統(tǒng)是以客戶為維度，也就是說客戶表、該客戶的賬戶表、流水表在絕大部分場景下是一起寫的，但如果按照各表主鍵range進行分片，這個交易并不能在一個分片上完成，這在高頻OLTP系統(tǒng)中會帶來性能問題。

分布式SQL支持

常見的單分片SQL，這兩者都能很好支持。NewSQL數(shù)據(jù)庫由于定位與目標(biāo)是一個通用的數(shù)據(jù)庫，所以支持的SQL會更完整，包括跨分片的join、聚合等復(fù)雜SQL。中間件模式多面向應(yīng)用需求設(shè)計，不過大部分也支持帶拆分鍵SQL、庫表遍歷、單庫join、聚合、排序、分頁等。但對跨庫的join以及聚合支持就不夠了。

NewSQL數(shù)據(jù)庫一般并不支持存儲過程、視圖、外鍵等功能，而中間件模式底層就是傳統(tǒng)關(guān)系數(shù)據(jù)庫，這些功能如果只是涉及單庫是比較容易支持的。

NewSQL數(shù)據(jù)庫往往選擇兼容MySQL或者PostgreSQL協(xié)議，所以SQL支持僅局限于這兩種，中間件例如驅(qū)動模式往往只需做簡單的SQL解析、計算路由、SQL重寫，所以可以支持更多種類的數(shù)據(jù)庫SQL。

SQL支持的差異主要在于分布式SQL執(zhí)行計劃生成器，由于NewSQL數(shù)據(jù)庫具有底層數(shù)據(jù)的分布、統(tǒng)計信息，因此可以做CBO，生成的執(zhí)行計劃效率更高，而中間件模式下沒有這些信息，往往只能基于規(guī)則RBO（Rule-Based-Opimization），這也是為什么中間件模式一般并不支持跨庫join，因為實現(xiàn)了效率也往往并不高，還不如交給應(yīng)用去做。

存儲引擎

傳統(tǒng)關(guān)系數(shù)據(jù)庫的存儲引擎設(shè)計都是面向磁盤的，大多都基于B+樹。B+樹通過降低樹的高度減少隨機讀、進而減少磁盤尋道次數(shù)，提高讀的性能，但大量的隨機寫會導(dǎo)致樹的分裂，從而帶來隨機寫，導(dǎo)致寫性能下降。NewSQL的底層存儲引擎則多采用LSM，相比B+樹LSM將對磁盤的隨機寫變成順序?qū)懀蟠筇岣吡藢懙男阅?。不過LSM的的讀由于需要合并數(shù)據(jù)性能比B+樹差，一般來說LSM更適合應(yīng)在寫大于讀的場景。當(dāng)然這只是單純數(shù)據(jù)結(jié)構(gòu)角度的對比，在數(shù)據(jù)庫實際實現(xiàn)時還會通過SSD、緩沖、bloom filter等方式優(yōu)化讀寫性能，所以讀性能基本不會下降太多。NewSQL數(shù)據(jù)由于多副本、分布式事務(wù)等開銷，相比單機關(guān)系數(shù)據(jù)庫SQL的響應(yīng)時間并不占優(yōu)，但由于集群的彈性擴展，整體QPS提升還是很明顯的，這也是NewSQL數(shù)據(jù)庫廠商說分布式數(shù)據(jù)庫更看重的是吞吐，而不是單筆SQL響應(yīng)時間的原因。

成熟度與生態(tài)

分布式數(shù)據(jù)庫是個新型通用底層軟件，準(zhǔn)確的衡量與評價需要一個多維度的測試模型，需包括發(fā)展現(xiàn)狀、使用情況、社區(qū)生態(tài)、監(jiān)控運維、周邊配套工具、功能滿足度、DBA人才、SQL兼容性、性能測試、高可用測試、在線擴容、分布式事務(wù)、隔離級別、在線DDL等等，雖然NewSQL數(shù)據(jù)庫發(fā)展經(jīng)過了一定時間檢驗，但多集中在互聯(lián)網(wǎng)以及傳統(tǒng)企業(yè)非核心交易系統(tǒng)中，目前還處于快速迭代、規(guī)模使用不斷優(yōu)化完善的階段。

相比而言，傳統(tǒng)關(guān)系數(shù)據(jù)庫則經(jīng)過了多年的發(fā)展，通過完整的評測，在成熟度、功能、性能、周邊生態(tài)、風(fēng)險把控、相關(guān)人才積累等多方面都具有明顯優(yōu)勢，同時對已建系統(tǒng)的兼容性也更好。

對于互聯(lián)網(wǎng)公司，數(shù)據(jù)量的增長壓力以及追求新技術(shù)的基因會更傾向于嘗試NewSQL數(shù)據(jù)庫，不用再考慮庫表拆分、應(yīng)用改造、擴容、事務(wù)一致性等問題怎么看都是非常吸引人的方案。

對于傳統(tǒng)企業(yè)例如銀行這種風(fēng)險意識較高的行業(yè)來說，NewSQL數(shù)據(jù)庫則可能在未來一段時間內(nèi)仍處于 探索 、審慎試點的階段?；谥虚g件+分庫分表模式架構(gòu)簡單，技術(shù)門檻更低，雖然沒有NewSQL數(shù)據(jù)庫功能全面，但大部分場景最核心的訴求也就是拆分后SQL的正確路由，而此功能中間件模式應(yīng)對還是綽綽有余的，可以說在大多數(shù)OLTP場景是夠用的。

限于篇幅，其它特性例如在線DDL、數(shù)據(jù)遷移、運維工具等特性就不在本文展開對比。

總結(jié)

如果看完以上內(nèi)容，您還不知道選哪種模式，那么結(jié)合以下幾個問題，先思考下NewSQL數(shù)據(jù)庫解決的點對于自身是不是真正的痛點：

如果以上有2到3個是肯定的，那么你可以考慮用NewSQL數(shù)據(jù)庫了，雖然前期可能需要一定的學(xué)習(xí)成本，但它是數(shù)據(jù)庫的發(fā)展方向，未來收益也會更高，尤其是互聯(lián)網(wǎng)行業(yè)，隨著數(shù)據(jù)量的突飛猛進，分庫分表帶來的痛苦會與日俱增。當(dāng)然選擇NewSQL數(shù)據(jù)庫你也要做好承擔(dān)一定風(fēng)險的準(zhǔn)備。

如果你還未做出抉擇，不妨再想想下面幾個問題：

如果這些問題有多數(shù)是肯定的，那還是分庫分表吧。在軟件領(lǐng)域很少有完美的解決方案，NewSQL數(shù)據(jù)庫也不是數(shù)據(jù)分布式架構(gòu)的銀彈。相比而言分庫分表是一個代價更低、風(fēng)險更小的方案，它最大程度復(fù)用傳統(tǒng)關(guān)系數(shù)據(jù)庫生態(tài)，通過中間件也可以滿足分庫分表后的絕大多數(shù)功能，定制化能力更強。 在當(dāng)前NewSQL數(shù)據(jù)庫還未完全成熟的階段，分庫分表可以說是一個上限低但下限高的方案，尤其傳統(tǒng)行業(yè)的核心系統(tǒng)，如果你仍然打算把數(shù)據(jù)庫當(dāng)做一個黑盒產(chǎn)品來用，踏踏實實用好分庫分表會被認為是個穩(wěn)妥的選擇。

很多時候軟件選型取決于領(lǐng)域特征以及架構(gòu)師風(fēng)格，限于筆者知識與所屬行業(yè)特點所限，以上僅為個人粗淺的一些觀點，歡迎討論。

MySQL數(shù)據(jù)庫性能優(yōu)化之分區(qū)分表分庫

分表是分散數(shù)據(jù)庫壓力的好方法。

分表，最直白的意思，就是將一個表結(jié)構(gòu)分為多個表，然后，可以再同一個庫里，也可以放到不同的庫。

當(dāng)然，首先要知道什么情況下，才需要分表。個人覺得單表記錄條數(shù)達到百萬到千萬級別時就要使用分表了。

分表的分類

**1、縱向分表**

將本來可以在同一個表的內(nèi)容，人為劃分為多個表。（所謂的本來，是指按照關(guān)系型數(shù)據(jù)庫的第三范式要求，是應(yīng)該在同一個表的。）

分表理由：根據(jù)數(shù)據(jù)的活躍度進行分離，（因為不同活躍的數(shù)據(jù)，處理方式是不同的）

案例：

對于一個博客系統(tǒng)，文章標(biāo)題，作者，分類，創(chuàng)建時間等，是變化頻率慢，查詢次數(shù)多，而且最好有很好的實時性的數(shù)據(jù)，我們把它叫做冷數(shù)據(jù)。而博客的瀏覽量，回復(fù)數(shù)等，類似的統(tǒng)計信息，或者別的變化頻率比較高的數(shù)據(jù)，我們把它叫做活躍數(shù)據(jù)。所以，在進行數(shù)據(jù)庫結(jié)構(gòu)設(shè)計的時候，就應(yīng)該考慮分表，首先是縱向分表的處理。

這樣縱向分表后：

首先存儲引擎的使用不同，冷數(shù)據(jù)使用MyIsam 可以有更好的查詢數(shù)據(jù)?；钴S數(shù)據(jù)，可以使用Innodb ,可以有更好的更新速度。

其次，對冷數(shù)據(jù)進行更多的從庫配置，因為更多的操作時查詢，這樣來加快查詢速度。對熱數(shù)據(jù)，可以相對有更多的主庫的橫向分表處理。

其實，對于一些特殊的活躍數(shù)據(jù)，也可以考慮使用memcache ,redis之類的緩存，等累計到一定量再去更新數(shù)據(jù)庫?；蛘適ongodb 一類的nosql 數(shù)據(jù)庫，這里只是舉例，就先不說這個。

**2、橫向分表**

字面意思，就可以看出來，是把大的表結(jié)構(gòu)，橫向切割為同樣結(jié)構(gòu)的不同表，如，用戶信息表，user_1,user_2等。表結(jié)構(gòu)是完全一樣，但是，根據(jù)某些特定的規(guī)則來劃分的表，如根據(jù)用戶ID來取模劃分。

分表理由：根據(jù)數(shù)據(jù)量的規(guī)模來劃分，保證單表的容量不會太大，從而來保證單表的查詢等處理能力。

案例：同上面的例子，博客系統(tǒng)。當(dāng)博客的量達到很大時候，就應(yīng)該采取橫向分割來降低每個單表的壓力，來提升性能。例如博客的冷數(shù)據(jù)表，假如分為100個表，當(dāng)同時有100萬個用戶在瀏覽時，如果是單表的話，會進行100萬次請求，而現(xiàn)在分表后，就可能是每個表進行1萬個數(shù)據(jù)的請求（因為，不可能絕對的平均，只是假設(shè)），這樣壓力就降低了很多很多。

延伸：為什么要分表和分區(qū)？

日常開發(fā)中我們經(jīng)常會遇到大表的情況，所謂的大表是指存儲了百萬級乃至千萬級條記錄的表。這樣的表過于龐大，導(dǎo)致數(shù)據(jù)庫在查詢和插入的時候耗時太長，性能低下，如果涉及聯(lián)合查詢的情況，性能會更加糟糕。分表和表分區(qū)的目的就是減少數(shù)據(jù)庫的負擔(dān)，提高數(shù)據(jù)庫的效率，通常點來講就是提高表的增刪改查效率。

什么是分表？

分表是將一個大表按照一定的規(guī)則分解成多張具有獨立存儲空間的實體表，我們可以稱為子表，每個表都對應(yīng)三個文件，MYD數(shù)據(jù)文件，.MYI索引文件，.frm表結(jié)構(gòu)文件。這些子表可以分布在同一塊磁盤上，也可以在不同的機器上。app讀寫的時候根據(jù)事先定義好的規(guī)則得到對應(yīng)的子表名，然后去操作它。

什么是分區(qū)？

分區(qū)和分表相似，都是按照規(guī)則分解表。不同在于分表將大表分解為若干個獨立的實體表，而分區(qū)是將數(shù)據(jù)分段劃分在多個位置存放，可以是同一塊磁盤也可以在不同的機器。分區(qū)后，表面上還是一張表，但數(shù)據(jù)散列到多個位置了。app讀寫的時候操作的還是大表名字，db自動去組織分區(qū)的數(shù)據(jù)。

**MySQL分表和分區(qū)有什么聯(lián)系呢？**

1、都能提高mysql的性高，在高并發(fā)狀態(tài)下都有一個良好的表現(xiàn)。

2、分表和分區(qū)不矛盾，可以相互配合的，對于那些大訪問量，并且表數(shù)據(jù)比較多的表，我們可以采取分表和分區(qū)結(jié)合的方式（如果merge這種分表方式，不能和分區(qū)配合的話，可以用其他的分表試），訪問量不大，但是表數(shù)據(jù)很多的表，我們可以采取分區(qū)的方式等。

3、分表技術(shù)是比較麻煩的，需要手動去創(chuàng)建子表，app服務(wù)端讀寫時候需要計算子表名。采用merge好一些，但也要創(chuàng)建子表和配置子表間的union關(guān)系。

4、表分區(qū)相對于分表，操作方便，不需要創(chuàng)建子表。

我們知道對于大型的互聯(lián)網(wǎng)應(yīng)用，數(shù)據(jù)庫單表的數(shù)據(jù)量可能達到千萬甚至上億級別，同時面臨這高并發(fā)的壓力。Master-Slave結(jié)構(gòu)只能對數(shù)據(jù)庫的讀能力進行擴展，寫操作還是集中在Master中，Master并不能無限制的掛接Slave庫，如果需要對數(shù)據(jù)庫的吞吐能力進行進一步的擴展，可以考慮采用分庫分表的策略。

**1、分表**

在分表之前，首先要選中合適的分表策略（以哪個字典為分表字段，需要將數(shù)據(jù)分為多少張表），使數(shù)據(jù)能夠均衡的分布在多張表中，并且不影響正常的查詢。在企業(yè)級應(yīng)用中，往往使用org_id(組織主鍵)做為分表字段，在互聯(lián)網(wǎng)應(yīng)用中往往是userid。在確定分表策略后，當(dāng)數(shù)據(jù)進行存儲及查詢時，需要確定到哪張表里去查找數(shù)據(jù)，

數(shù)據(jù)存放的數(shù)據(jù)表 = 分表字段的內(nèi)容 % 分表數(shù)量

**2、分庫**

分表能夠解決單表數(shù)據(jù)量過大帶來的查詢效率下降的問題，但是不能給數(shù)據(jù)庫的并發(fā)訪問帶來質(zhì)的提升，面對高并發(fā)的寫訪問，當(dāng)Master無法承擔(dān)高并發(fā)的寫入請求時，不管如何擴展Slave服務(wù)器，都沒有意義了。我們通過對數(shù)據(jù)庫進行拆分，來提高數(shù)據(jù)庫的寫入能力，即所謂的分庫。分庫采用對關(guān)鍵字取模的方式，對數(shù)據(jù)庫進行路由。

數(shù)據(jù)存放的數(shù)據(jù)庫=分庫字段的內(nèi)容%數(shù)據(jù)庫的數(shù)量

**3、即分表又分庫**

數(shù)據(jù)庫分表可以解決單表海量數(shù)據(jù)的查詢性能問題，分庫可以解決單臺數(shù)據(jù)庫的并發(fā)訪問壓力問題。

當(dāng)數(shù)據(jù)庫同時面臨海量數(shù)據(jù)存儲和高并發(fā)訪問的時候，需要同時采取分表和分庫策略。一般分表分庫策略如下：

中間變量 = 關(guān)鍵字%（數(shù)據(jù)庫數(shù)量*單庫數(shù)據(jù)表數(shù)量）

庫 = 取整（中間變量/單庫數(shù)據(jù)表數(shù)量）

表 = （中間變量%單庫數(shù)據(jù)表數(shù)量）

實例：

1、分庫分表

很明顯，一個主表（也就是很重要的表，例如用戶表）無限制的增長勢必嚴重影響性能，分庫與分表是一個很不錯的解決途徑，也就是性能優(yōu)化途徑，現(xiàn)在的案例是我們有一個1000多萬條記錄的用戶表members,查詢起來非常之慢，同事的做法是將其散列到100個表中，分別從members0到members99，然后根據(jù)mid分發(fā)記錄到這些表中，牛逼的代碼大概是這樣子：

復(fù)制代碼 代碼如下:

?php

for($i=0;$i 100; $i++ ){

//echo "CREATE TABLE db2.members{$i} LIKE db1.members

";

echo "INSERT INTO members{$i} SELECT * FROM members WHERE mid%100={$i}

";

}

?

2、不停機修改mysql表結(jié)構(gòu)

同樣還是members表，前期設(shè)計的表結(jié)構(gòu)不盡合理，隨著數(shù)據(jù)庫不斷運行，其冗余數(shù)據(jù)也是增長巨大，同事使用了下面的方法來處理：

先創(chuàng)建一個臨時表：

/*創(chuàng)建臨時表*/

CREATE TABLE members_tmp LIKE members

然后修改members_tmp的表結(jié)構(gòu)為新結(jié)構(gòu)，接著使用上面那個for循環(huán)來導(dǎo)出數(shù)據(jù)，因為1000萬的數(shù)據(jù)一次性導(dǎo)出是不對的，mid是主鍵，一個區(qū)間一個區(qū)間的導(dǎo)，基本是一次導(dǎo)出5萬條吧，這里略去了

接著重命名將新表替換上去：

/*這是個頗為經(jīng)典的語句哈*/

RENAME TABLE members TO members_bak,members_tmp TO members;

就是這樣，基本可以做到無損失，無需停機更新表結(jié)構(gòu)，但實際上RENAME期間表是被鎖死的，所以選擇在線少的時候操作是一個技巧。經(jīng)過這個操作，使得原先8G多的表，一下子變成了2G多。

分庫分表技術(shù)及技術(shù)方案

一、分庫分表的必要性

分庫分表技術(shù)的使用，主要是數(shù)據(jù)庫產(chǎn)生了瓶頸，如單庫的并發(fā)訪問或單表的查詢都超出了閾值。對系統(tǒng)使用造成一定的影響，不得已而產(chǎn)生的技術(shù)。

通過分庫分表技術(shù)來解決此類問題，但正因為使用此技術(shù)，會產(chǎn)生ACID一系列的問題，各類中間件解決此類問題各有各的優(yōu)勢。

提示：如場景無必要，千萬不要使用分庫分表。

二、分庫分表的思路

1、垂直區(qū)分

垂直分庫：從業(yè)務(wù)角度，一個庫分成多個庫，如把訂單和用戶信息分成兩個庫來存儲。這樣的好處就是可以微服務(wù)了。每塊的業(yè)務(wù)單獨部署，互不影響，通過接口去調(diào)用。

垂直分表：把大表分成多個小表，如熱點數(shù)據(jù)和非熱點數(shù)據(jù)分開，提高查詢速度。

2、水平區(qū)分

水平分表：同一業(yè)務(wù)如數(shù)據(jù)量大了以后，根據(jù)一定的規(guī)則分為不同的表進行存儲。

水平分庫：如訂單分成多個庫存儲，分解服務(wù)器壓力。

以上一般來說，垂直分庫和水平分表用的會多些。

三、分庫分表的原理分析

分庫分表常用的方案：Hash取模方案和range范圍方案；

路由算法為最主要的算法，指得是把路由的Key按照指定的算法進行存放；

1、Hash取模方案

根據(jù)取余分配到不同的表里。要根據(jù)實際情況確認模的大小。此方案由于平均分配，不存在熱點問題，但數(shù)據(jù)遷移很復(fù)雜。

2、Range范圍方案

range根據(jù)范圍進行劃分，如日期，大小。此方案不存在數(shù)據(jù)遷移，但存在熱點問題。

四、分庫分表的技術(shù)選型

1、技術(shù)選型

解決方案主要分為4種：MySQL的分區(qū)技術(shù)、NoSql、NewSQL、MySQL的分庫分表。

（1）mysql分區(qū)技術(shù)：把一張表存放在不同存儲文件。由于無法負載，使用較少。

（2）NoSQL（如MongoDB）：如是訂單等比較重要數(shù)據(jù)，強關(guān)聯(lián)關(guān)系，需約束一致性，不太適應(yīng)。

（3）NewSql(具有NoSQL對海量數(shù)據(jù)的存儲管理能力，還保持了傳統(tǒng)數(shù)據(jù)庫支持ACID和SQL等特性):如TiDB可滿足需求。

（4）MySQL的分庫分表：如使用mysql,此種方案為主流方式。

2、中間件

解決此類問題的中間件主要為：Proxy模式、Client模式。

（1）Proxy模式

（2）Client模式

把分庫分表相關(guān)邏輯存放在客戶端，一版客戶端的應(yīng)用會引用一個jar，然后再jar中處理SQL組合、數(shù)據(jù)庫路由、執(zhí)行結(jié)果合并等相關(guān)功能。

（3）中間件的比較

由于Client模式少了一層，運維方便，相對來說容易些。

五、分庫分表的實踐

根據(jù)容量（當(dāng)前容量和增長量）評估分庫或分表個數(shù) - 選key（均勻）- 分表規(guī)則（hash或range等）- 執(zhí)行（一般雙寫）- 擴容問題（盡量減少數(shù)據(jù)的移動）。

在這里我們選用中間件share-jdbc。

1、引入maven依賴

2、spring boot規(guī)則配置

行表達式標(biāo)識符可以使用${...}或$-{...}，但前者與Spring本身的屬性文件占位符沖突，因此在Spring環(huán)境中使用行表達式標(biāo)識符建議使用$-{...}。

3、創(chuàng)建DataSource

通過ShardingDataSourceFactory工廠和規(guī)則配置對象獲取ShardingDataSource，ShardingDataSource實現(xiàn)自JDBC的標(biāo)準(zhǔn)接口DataSource。然后即可通過DataSource選擇使用原生JDBC開發(fā)，或者使用JPA, MyBatis等ORM工具。

當(dāng)前文章：nosql分庫,數(shù)據(jù)庫 nosql
鏈接URL：http://jinyejixie.com/article34/dsedspe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供建站公司、網(wǎng)站策劃、自適應(yīng)網(wǎng)站、網(wǎng)站導(dǎo)航、網(wǎng)站內(nèi)鏈、營銷型網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)