資料庫分庫分表

分庫的優點是：實現簡單，庫與庫之間界限分明，便於維護，缺點是不利於頻繁跨庫操作，單錶資料量大的問題解決不了。

分表的優點是：能解決分庫的不足點，但是缺點卻恰恰是分庫的優點，分表實現起來比較複雜，特別是分表規則的劃分，程式的編寫，以及後期的

資料庫拆分移植維護。

實際應用中，一般網際網路企業的路線都是先分庫再分表，兩者結合使用，取長補短，這樣發揮了mysql擴充套件的最大優勢，但是缺點是架構很大，很複雜，應用程式的編寫也比較複雜。

在現實專案中，往往是這兩種情況兼而有之，這就需要做出權衡，甚至既需要垂直切分，又需要水平切分。我們的遊戲專案便綜合使用了垂直與水平切分，我們首先對資料庫進行垂直切分，然後，再針對一部分表，通常是使用者資料表，進行水平切分。

4 分庫分表存在的問題。

4.1 事務問題。

在執行分庫分表之後，由於資料儲存到了不同的庫上，資料庫事務管理出現了困難。如果依賴資料庫本身的分布式事務管理功能去執行事務，將付出高昂的效能代價；如果由應用程式去協助控制，形成程式邏輯上的事務，又會造成程式設計方面的負擔。

4.2 跨庫跨表的join問題。

在執行了分庫分表之後，難以避免會將原本邏輯關聯性很強的資料劃分到不同的表、不同的庫上，這時，表的關聯操作將受到限制，我們無法join位於不同分庫的表，也無法join分表粒度不同的表，結果原本一次查詢能夠完成的業務，可能需要多次查詢才能完成。

4.3 額外的資料管理負擔和資料運算壓力。

額外的資料管理負擔，最顯而易見的就是資料的定位問題和資料的增刪改查的重複執行問題，這些都可以通過應用程式解決，但必然引起額外的邏輯運算，例如，對於乙個記錄使用者成績的使用者資料表usertable，業務要求查出成績最好的100位，在進行分表之前，只需乙個order by語句就可以搞定，但是在進行分表之後，將需要n個order by語句，分別查出每乙個分表的前100名使用者資料，然後再對這些資料進行合併計算，才能得出結果。

.事務問題：

解決事務問題目前有兩種可行的方案：分布式事務和通過應用程式與資料庫共同控制實現事務下面對兩套方案進行乙個簡單的對比。

方案一：使用分布式事務

優點：交由資料庫管理，簡單有效

缺點：效能代價高，特別是shard越來越多時

方案二：由應用程式和資料庫共同控制

原理：將乙個跨多個資料庫的分布式事務分拆成多個僅處

於單個資料庫上面的小事務，並通過應用程式來總控

各個小事務。

優點：效能上有優勢

缺點：需要應用程式在事務控制上做靈活設計。如果使用

了spring的事務管理，改動起來會面臨一定的困難。

2.跨節點join的問題

只要是進行切分，跨節點join的問題是不可避免的。但是良好的設計和切分卻可以減少此類情況的發生。解決這一問題的普遍做法是分兩次查詢實現。在第一次查詢的結果集中找出關聯資料的id,根據這些id發起第二次請求得到關聯資料。

3.跨節點的count,order by,group by以及聚合函式問題

這些是一類問題，因為它們都需要基於全部資料集合進行計算。多數的**都不會自動處理合併工作。解決方案：與解決跨節點join問題的類似，分別在各個節點上得到結果後在應用程式端進行合併。和join不同的是每個結點的查詢可以並行執行，因此很多時候它的速度要比單一大表快很多。但如果結果集很大，對應用程式記憶體的消耗是乙個問題。

資料庫分庫 分表

資料庫分庫分表

資料庫分庫分表

資料庫分庫分表

相關推薦

資料庫分庫分表