建站
咨詢
售后
建站咨詢
新聞中心
數據庫分庫分表是一種常見的數據存儲和處理技術，它可以幫助我們更好地管理和利用數據資源，提升系統(tǒng)性能和穩(wěn)定性。然而，對于許多開發(fā)者來說，數據庫分庫分表仍然是一個比較陌生和復雜的主題，因此需要我們認真學習和掌握，以便正確使用并實現其更大的價值。
網站建設哪家好，找創(chuàng)新互聯(lián)公司！專注于網頁設計、網站建設、微信開發(fā)、小程序制作、集團企業(yè)網站建設等服務項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了清水河免費建站歡迎大家使用！
1. 什么是數據庫分庫分表？
數據庫分庫分表是將數據按照業(yè)務需求劃分到不同的數據庫實例或物理表中的一種技術。它的主要目的是提高數據庫的性能和可擴展性，降低單個數據庫的負擔和風險。例如，當一個應用系統(tǒng)面臨海量數據的存儲和查詢需求時，單個數據庫可能無法滿足高并發(fā)和高負載的要求，此時我們可以通過分庫分表來實現水平拆分和分布式處理，以達到更高的吞吐量和效率。
2. 如何選擇合適的分庫分表策略？
在選擇分庫分表策略時，我們需要綜合考慮多個因素，包括數據量、業(yè)務類型、查詢規(guī)律、數據安全和可靠性等方面。以下是幾種常見的分庫分表策略：
2.1 垂直分庫：垂直分庫是按照邏輯業(yè)務進行劃分，將不同的業(yè)務數據存儲在不同的數據庫中。例如，把用戶數據、訂單數據、商品數據等存儲到不同的數據庫中，可以減少數據庫之間的耦合和沖突，提高數據訪問和查詢效率。但是，垂直分庫在某些場景下也會導致數據拆分過度和業(yè)務變更難度增大的問題。
2.2 水平分庫：水平分庫是按照數據量進行劃分，將相同類型的數據均勻地分散到不同的數據庫中。例如，在用戶表中按照用戶ID進行水平分庫，可以將用戶數據分散到多個數據庫中，從而降低單個數據庫的負擔和風險。但是，水平分庫也會導致數據難以跨庫操作和查詢等問題。
2.3 垂直分表：垂直分表是將一個大表按照列進行拆分，將不同列的數據存儲到不同的物理表中。例如，一個用戶表可以拆分成用戶基本信息表、用戶地址表、用戶訂單表等，可以減少不必要的數據冗余和提高數據查詢和更新效率。但是，垂直分表也會增加表之間的關聯(lián)和操作難度。
2.4 水平分表：水平分表是將一個大表按照行進行拆分，將不同行的數據均勻地分到不同的物理表中。例如，將用戶表按照用戶ID進行水平分表，可以將用戶數據平均分配到多個表中，從而實現數據的分散存儲和高效訪問。但是，水平分表也會增加數據查詢和事務的復雜度。
3. 如何正確使用分庫分表？
分庫分表并不是一種普適的技術，需要根據業(yè)務需求和實際情況進行合理的設計和實現。以下是一些使用分庫分表的注意事項：
3.1 選取合適的分庫分表策略：在選取分庫分表策略時，需要考慮多個因素，包括數據量、業(yè)務特性、查詢和更新規(guī)律等方面，以選擇更符合業(yè)務需求的方案。
3.2 制定明確的數據分片方案：在分庫分表之前，需要制定明確的數據分片方案，包括數據劃分規(guī)則、數據復制機制、數據遷移方案等。同時，需要考慮數據的一致性和可靠性，避免數據丟失或錯誤。
3.3 優(yōu)化查詢和更新操作：在使用分庫分表時，需要優(yōu)化查詢和更新操作，盡量將操作放在同一分片或同一表中，避免多次跨分片或跨表操作。此外，還需要考慮分片路由和事務管理等問題。
3.4 監(jiān)控和調優(yōu)系統(tǒng)性能：在使用分庫分表后，需要對系統(tǒng)性能進行監(jiān)控和調優(yōu)，包括查詢響應時間、數據復制延遲、SQL性能等方面?？梢允褂靡恍╅_源或商業(yè)軟件來進行監(jiān)控和調優(yōu)。
4. 結語
數據庫分庫分表是一種常見的數據存儲和處理技術，它可以幫助我們更好地管理和利用數據資源，提升系統(tǒng)性能和穩(wěn)定性。但是，分庫分表并不是一種萬能的解決方案，需要通過合理的設計和實現來達到更優(yōu)的效果。希望本文可以為大家解決一些關于分庫分表的疑慮和困惑，同時也鼓勵大家在實踐中不斷地探索和創(chuàng)新。
成都網站建設公司-創(chuàng)新互聯(lián),建站經驗豐富以策略為先導10多年以來專注數字化網站建設,提供企業(yè)網站建設,高端網站設計,響應式網站制作,設計師量身打造品牌風格,熱線:028-86922220mysql數據庫分庫分表哪個工具好，我整理出來了五個，求點評
1 用戶類庫：用于保存了用戶的相關信息。例如：db_user,db_system,db_company等。
2 業(yè)務類庫：用于保存主要業(yè)務的信息。比如主要業(yè)務是笑話，用這個庫保存笑話業(yè)務。例如：db_joke,db_temp_joke等。
3 內存類庫：主要用Mysql的宏碧滾內存引擎。前蔽余臺的數據從內存庫中查找，速度快。例如：heap。
4 圖片類庫：主要保存圖片的索引以及慧喊關聯(lián)。例如：db_img_index，db_img_res。
5 日志類庫：記錄點擊,刷新,登錄等日志信息。例如：db_log_click,db_log_fresh,db_log_login。
6 統(tǒng)計類庫：對業(yè)務的統(tǒng)計，比如點擊量,刷新量等等。例如db_stat。
分庫分表 VS newsql數據庫
最近與同行 科技 交流，經常被問到分庫分表與分布式數據庫如何選擇，網上也有很多關于中間件+傳統(tǒng)關系數據庫（分庫分表）與NewSQL分布式數據庫的文章，但有些觀點枯茄與判斷是我覺得是偏激的，脫離環(huán)境去評價方案沒爛察好壞其實有失公允。
本文通過對兩種模式關鍵特性實現原理對比，希望可以盡可能客觀、中立的闡明各自真實的優(yōu)缺點以及適用場景。
首先關于“中間件+關系數據庫分庫分表”算不算NewSQL分布式數據庫問題，國外有篇論文pavlo-newsql-sigmodrec，如果根據該文中的分類，Spanner、TiDB、OB算是之一種新架構型，Sharding-Sphere、Mycat、DRDS等中間件方案算是第二種（文中還有第三種云數據庫，本文暫不詳細介紹）。
基于中間件（包括SDK和Proxy兩種形式）+傳統(tǒng)關系數據庫（分庫分表）模式是不是分布式架構？我覺得是的，因為存儲確實也分布式了，也能實現橫向擴展。但是不是”偽”分布式數據庫？從架構先進性來看，這么說也有一定道理。”偽”主要體現在中間件層與底層DB重復的SQL解析與執(zhí)行計劃生成、存儲引擎基于B+Tree等，這在分布式數據庫架構中實際上冗余低效的。為了避免引起真?zhèn)畏植际綌祿斓目谒畱?zhàn)，本文中NewSQL數據庫特指這種新架構NewSQL數據庫。
NewSQL數據庫相比中間件+分庫分表的先進在哪兒？畫一個簡單的架構對比圖：
這些大多也是NewSQL數據庫產品主要宣傳的點，不過這些看起來很美好的功能是否真的如此？接下來針對以上幾點分別闡述下的我的理解。
這是把雙刃劍。
CAP限制
想想更早些出現的NoSQL數據庫為何不支持分布式事務（最新版的mongoDB等也開始支持了），是缺乏理論與實踐支撐嗎？并不是，原因是CAP定理依然是分布式數據庫頭上的頸箍咒，在保證強一致的同時必然會犧牲可用性A或分區(qū)容忍性P。為什么大部分NoSQL不提供分布式事務？
那么NewSQL數據庫突破CAP定理限制了嗎？并沒有。NewSQL數據庫的鼻主Google Spanner（目前絕大部分分布式數據庫都是按照Spanner架構設計的）提供了一致性和大于5個9的可用性，宣稱是一個“實際上是CA”的，其真正的含義是
系統(tǒng)處于 CA 狀態(tài)的概率非常高，由于網絡分區(qū)導致的服務停用的概率非常小
，究其真正原因是其打造私有全球網保證了不會出現網絡中斷引發(fā)的網絡分區(qū)，另外就是其高效的運維隊伍,這也是cloud spanner的賣點。詳細可見CAP提出者Eric Brewer寫的《Spanner, TrueTime 和CAP理論》。
完備性
：
兩階段提交協(xié)議是否嚴格支持ACID，各種異常場景是不是都可以覆蓋？
2PC在commit階段發(fā)送異常，其實跟更大努力一階段提交類似也會有部分可見問題，嚴格講一段時間內并不能保證A原子性和C一致性（待故障恢復后recovery機制可以保證最終的A和C）。完備的分布式事務支持并不是一件簡單的事情，需要可以應對網絡以及各種硬件包括網卡、磁盤、CPU、內存、電源等各類異常，通過嚴格的測試。之前跟某友商交流，他們甚至說目前已知的NewSQL在分布式事務支持上都是不完整的，他們都有案例跑不過，圈內人士這么篤定，也說明了
分布式事務的支持完整程度其實是層次不齊的。
但分布式事務又是這些NewSQL數據庫的一個非常重要的底層機制，跨資源的DML、DDL等都歷悄依賴其實現，如果這塊的性能、完備性打折扣，上層跨分片SQL執(zhí)行的正確性會受到很大影響。
性能
傳統(tǒng)關系數據庫也支持分布式事務XA，但為何很少有高并發(fā)場景下用呢？ 因為XA的基礎兩階段提交協(xié)議存在網絡開銷大，阻塞時間長、死鎖等問題，這也導致了其實際上很少大規(guī)模用在基于傳統(tǒng)關系數據庫的OLTP系統(tǒng)中。
NewSQL數據庫的分布式事務實現也仍然多基于兩階段提交協(xié)議，例如google percolator分布式事務模型，
采用原子鐘+MVCC+ Snapshot Isolation（SI），這種方式通過TSO(Timestamp Oracle)保證了全局一致性，通過MVCC避免了鎖，另外通過primary lock和secondary lock將提交的一部分轉為異步，相比XA確實提高了分布式事務的性能。
但不管如何優(yōu)化，相比于1PC，2PC多出來的GID獲取、網絡開銷、prepare日志持久化還是會帶來很大的性能損失，尤其是跨節(jié)點的數量比較多時會更加顯著，例如在銀行場景做個批量扣款，一個文件可能上W個賬戶，這樣的場景無論怎么做還是吞吐都不會很高。
雖然NewSQL分布式數據庫產品都宣傳完備支持分布式事務，但這并不是說應用可以完全不用關心數據拆分，這些數據庫的更佳實踐中仍然會寫到，應用的大部分場景盡可能避免分布式事務。
既然強一致事務付出的性能代價太大，我們可以反思下是否真的需要這種強一致的分布式事務？尤其是在做微服務拆分后，很多系統(tǒng)也不太可能放在一個統(tǒng)一的數據庫中。嘗試將一致性要求弱化，便是柔性事務，放棄ACID(Atomicity,Consistency, Isolation, Durability)，轉投BASE(Basically Available,Soft state,Eventually consistent)，例如Saga、TCC、可靠消息保證最終一致等模型，對于大規(guī)模高并發(fā)OLTP場景，我個人更建議使用柔性事務而非強一致的分布式事務。關于柔性事務，筆者之前也寫過一個技術組件，最近幾年也涌現出了一些新的模型與框架（例如阿里剛開源的Fescar），限于篇幅不再贅述，有空再單獨寫篇文章。
HA與異地多活
主從模式并不是更優(yōu)的方式，就算是半同步復制，在極端情況下（半同步轉異步）也存在丟數問題，目前業(yè)界公認更好的方案是基于paxos分布式一致性協(xié)議或者其它類paxos如raft方式，Google Spanner、TiDB、cockcoachDB、OB都采用了這種方式，基于Paxos協(xié)議的多副本存儲，遵循過半寫原則，支持自動選主，解決了數據的高可靠，縮短了failover時間，提高了可用性，特別是減少了運維的工作量，這種方案技術上已經很成熟，也是NewSQL數據庫底層的標配。
當然這種方式其實也可以用在傳統(tǒng)關系數據庫，阿里、微信團隊等也有將MySQL存儲改造支持paxos多副本的，MySQL也推出了官方版MySQL Group Cluster，預計不遠的未來主從模式可能就成為 歷史 了。
需要注意的是很多NewSQL數據庫廠商宣傳基于paxos或raft協(xié)議可以實現【異地多活】，這個實際上是有前提的，那就是異地之間網絡延遲不能太高
。以銀行“兩地三中心”為例，異地之間多相隔數千里，延時達到數十毫秒，如果要多活，那便需異地副本也參與數據庫日志過半確認，這樣高的延時幾乎沒有OLTP系統(tǒng)可以接受的。
數據庫層面做異地多活是個美好的愿景，但距離導致的延時目前并沒有好的方案。
之前跟螞蟻團隊交流，螞蟻異地多活的方案是在應用層通過MQ同步雙寫交易信息，異地DC將交易信息保存在分布式緩存中，一旦發(fā)生異地切換，數據庫同步中間件會告之數據延遲時間，應用從緩存中讀取交易信息，將這段時間內涉及到的業(yè)務對象例如用戶、賬戶進行黑名單管理，等數據同步追上之后再將這些業(yè)務對象從黑名單中剔除。由于雙寫的不是所有數據庫操作日志而只是交易信息，數據延遲只影響一段時間內數據，這是目前我覺得比較靠譜的異地度多活方案。
另外有些系統(tǒng)進行了單元化改造，這在paxos選主時也要結合考慮進去，這也是目前很多NewSQL數據庫欠缺的功能。
Scale橫向擴展與分片機制
paxos算法解決了高可用、高可靠問題，并沒有解決Scale橫向擴展的問題，所以分片是必須支持的。NewSQL數據庫都是天生內置分片機制的，而且會根據每個分片的數據負載(磁盤使用率、寫入速度等)自動識別熱點，然后進行分片的分裂、數據遷移、合并，這些過程應用是無感知的，這省去了DBA的很多運維工作量。以TiDB為例，它將數據切成region，如果region到64M時，數據自動進行遷移。
分庫分表模式下需要應用設計之初就要明確各表的拆分鍵、拆分方式（range、取模、一致性哈希或者自定義路由表）、路由規(guī)則、拆分庫表數量、擴容方式等。相比NewSQL數據庫，這種模式給應用帶來了很大侵入和復雜度，這對大多數系統(tǒng)來說也是一大挑戰(zhàn)。
這里有個問題是NewSQL數據庫統(tǒng)一的內置分片策略（例如tidb基于range）可能并不是更高效的，因為與領域模型中的劃分要素并不一致，這導致的后果是很多交易會產生分布式事務。
舉個例子，銀行核心業(yè)務系統(tǒng)是以客戶為維度，也就是說客戶表、該客戶的賬戶表、流水表在絕大部分場景下是一起寫的，但如果按照各表主鍵range進行分片，這個交易并不能在一個分片上完成，這在高頻OLTP系統(tǒng)中會帶來性能問題。
分布式SQL支持
常見的單分片SQL，這兩者都能很好支持。NewSQL數據庫由于定位與目標是一個通用的數據庫，所以支持的SQL會更完整，包括跨分片的join、聚合等復雜SQL。中間件模式多面向應用需求設計，不過大部分也支持帶拆分鍵SQL、庫表遍歷、單庫join、聚合、排序、分頁等。但對跨庫的join以及聚合支持就不夠了。
NewSQL數據庫一般并不支持存儲過程、視圖、外鍵等功能，而中間件模式底層就是傳統(tǒng)關系數據庫，這些功能如果只是涉及單庫是比較容易支持的。
NewSQL數據庫往往選擇兼容MySQL或者PostgreSQL協(xié)議，所以SQL支持僅局限于這兩種，中間件例如驅動模式往往只需做簡單的SQL解析、計算路由、SQL重寫，所以可以支持更多種類的數據庫SQL。
SQL支持的差異主要在于分布式SQL執(zhí)行計劃生成器，由于NewSQL數據庫具有底層數據的分布、統(tǒng)計信息，因此可以做CBO，生成的執(zhí)行計劃效率更高，而中間件模式下沒有這些信息，往往只能基于規(guī)則RBO（Rule-Based-Opimization），這也是為什么中間件模式一般并不支持跨庫join，因為實現了效率也往往并不高，還不如交給應用去做。
存儲引擎
傳統(tǒng)關系數據庫的存儲引擎設計都是面向磁盤的，大多都基于B+樹。B+樹通過降低樹的高度減少隨機讀、進而減少磁盤尋道次數，提高讀的性能，但大量的隨機寫會導致樹的分裂，從而帶來隨機寫，導致寫性能下降。NewSQL的底層存儲引擎則多采用L，相比B+樹L將對磁盤的隨機寫變成順序寫，大大提高了寫的性能。不過L的的讀由于需要合并數據性能比B+樹差，一般來說L更適合應在寫大于讀的場景。當然這只是單純數據結構角度的對比，在數據庫實際實現時還會通過SSD、緩沖、bloom filter等方式優(yōu)化讀寫性能，所以讀性能基本不會下降太多。NewSQL數據由于多副本、分布式事務等開銷，相比單機關系數據庫SQL的響應時間并不占優(yōu)，但由于集群的彈性擴展，整體QPS提升還是很明顯的，這也是NewSQL數據庫廠商說分布式數據庫更看重的是吞吐，而不是單筆SQL響應時間的原因。
成熟度與生態(tài)
分布式數據庫是個新型通用底層軟件，準確的衡量與評價需要一個多維度的測試模型，需包括發(fā)展現狀、使用情況、社區(qū)生態(tài)、監(jiān)控運維、周邊配套工具、功能滿足度、DBA人才、SQL兼容性、性能測試、高可用測試、在線擴容、分布式事務、隔離級別、在線DDL等等，雖然NewSQL數據庫發(fā)展經過了一定時間檢驗，但多集中在互聯(lián)網以及傳統(tǒng)企業(yè)非核心交易系統(tǒng)中，目前還處于快速迭代、規(guī)模使用不斷優(yōu)化完善的階段。
相比而言，傳統(tǒng)關系數據庫則經過了多年的發(fā)展，通過完整的評測，在成熟度、功能、性能、周邊生態(tài)、風險把控、相關人才積累等多方面都具有明顯優(yōu)勢，同時對已建系統(tǒng)的兼容性也更好。
對于互聯(lián)網公司，數據量的增長壓力以及追求新技術的基因會更傾向于嘗試NewSQL數據庫，不用再考慮庫表拆分、應用改造、擴容、事務一致性等問題怎么看都是非常吸引人的方案。
對于傳統(tǒng)企業(yè)例如銀行這種風險意識較高的行業(yè)來說，NewSQL數據庫則可能在未來一段時間內仍處于 探索 、審慎試點的階段。基于中間件+分庫分表模式架構簡單，技術門檻更低，雖然沒有NewSQL數據庫功能全面，但大部分場景最核心的訴求也就是拆分后SQL的正確路由，而此功能中間件模式應對還是綽綽有余的，可以說在大多數OLTP場景是夠用的。
限于篇幅，其它特性例如在線DDL、數據遷移、運維工具等特性就不在本文展開對比。
總結
如果看完以上內容，您還不知道選哪種模式，那么結合以下幾個問題，先思考下NewSQL數據庫解決的點對于自身是不是真正的痛點：
如果以上有2到3個是肯定的，那么你可以考慮用NewSQL數據庫了，雖然前期可能需要一定的學習成本，但它是數據庫的發(fā)展方向，未來收益也會更高，尤其是互聯(lián)網行業(yè)，隨著數據量的突飛猛進，分庫分表帶來的痛苦會與日俱增。當然選擇NewSQL數據庫你也要做好承擔一定風險的準備。
如果你還未做出抉擇，不妨再想想下面幾個問題：
如果這些問題有多數是肯定的，那還是分庫分表吧。在軟件領域很少有完美的解決方案，NewSQL數據庫也不是數據分布式架構的銀彈。相比而言分庫分表是一個代價更低、風險更小的方案，它更大程度復用傳統(tǒng)關系數據庫生態(tài)，通過中間件也可以滿足分庫分表后的絕大多數功能，定制化能力更強。
在當前NewSQL數據庫還未完全成熟的階段，分庫分表可以說是一個上限低但下限高的方案，尤其傳統(tǒng)行業(yè)的核心系統(tǒng)，如果你仍然打算把數據庫當做一個黑盒產品來用，踏踏實實用好分庫分表會被認為是個穩(wěn)妥的選擇。
很多時候軟件選型取決于領域特征以及架構師風格，限于筆者知識與所屬行業(yè)特點所限，以上僅為個人粗淺的一些觀點，歡迎討論。
關于數據庫 分庫 分表的介紹到此就結束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關注本站。
成都網站建設選創(chuàng)新互聯(lián)(?:028-86922220),專業(yè)從事成都網站制作設計,高端小程序APP定制開發(fā),成都網絡營銷推廣等一站式服務。
網站題目：如何正確使用數據庫分庫分表來提升性能(數據庫分庫分表)
網頁鏈接：http://www.5511xx.com/article/djedjgj.html
