MySQL分庫分表總結：

單庫單表 ：

單庫單表是最常見的數(shù)據(jù)庫設計，例如，有一張用戶(user)表放在數(shù)據(jù)庫db中，所有的用戶都可以在db庫中的user表中查到。?

單庫多表 ：

隨著用戶數(shù)量的增加，user表的數(shù)據(jù)量會越來越大，當數(shù)據(jù)量達到一定程度的時候對user表的查詢會漸漸的變慢，從而影響整個DB的性能。如果使用

mysql, 還有一個更嚴重的問題是，當需要添加一列的時候，mysql會鎖表，期間所有的讀寫操作只能等待。 可以通過某種方式將user進行水平的切分，產(chǎn)生兩個表結構完全一樣的user_0000,user_0001等表，user_0000 + user_0001 + …的數(shù)據(jù)剛好是一份完整的數(shù)據(jù)。?

多庫多表 ：

隨著數(shù)據(jù)量增加也許單臺DB的存儲空間不夠，隨著查詢量的增加單臺數(shù)據(jù)庫服務器已經(jīng)沒辦法支撐。這個時候可以再對數(shù)據(jù)庫進行水平區(qū)分。?

分庫分表規(guī)則 ：

???????? 設計表的時候需要確定此表按照什么樣的規(guī)則進行分庫分表。例如，當有新用戶時，程序得確定將此用戶信息添加到哪個表中；同理，當?shù)卿浀臅r候我們得通過用戶的賬號找到數(shù)據(jù)庫中對應的記錄，所有的這些都需要按照某一規(guī)則進行。
路由
???????? 通過分庫分表規(guī)則查找到對應的表和庫的過程。如分庫分表的規(guī)則是user_id mod 4的方式，當用戶新注冊了一個賬號，賬號id的123,我們可以通

過id mod 4的方式確定此賬號應該保存到User_0003表中。當用戶123登錄的時候，我們通過123 mod 4后確定記錄在User_0003中。?

分庫分表產(chǎn)生的問題，及注意事項?

1.?? 分庫分表維度的問題?

假如用戶購買了商品,需要將交易記錄保存取來，如果按照用戶的緯度分表，則每個用戶的交易記錄都保存在同一表中，所以很快很方便的查找到某用

戶的購買情況，但是某商品被購買的情況則很有可能分布在多張表中，查找起來比較麻煩。反之，按照商品維度分表，可以很方便的查找到此商品的購

買情況，但要查找到買人的交易記錄比較麻煩。?

所以常見的解決方式有：
???? a.通過掃表的方式解決，此方法基本不可能，效率太低了。
???? b.記錄兩份數(shù)據(jù)，一份按照用戶緯度分表，一份按照商品維度分表。
???? c.通過搜索引擎解決，但如果實時性要求很高，又得關系到實時搜索。
2.?? 聯(lián)合查詢的問題
聯(lián)合查詢基本不可能，因為關聯(lián)的表有可能不在同一數(shù)據(jù)庫中。
3.?? 避免跨庫事務
避免在一個事務中修改db0中的表的時候同時修改db1中的表，一個是操作起來更復雜，效率也會有一定影響。
4.?? 盡量把同一組數(shù)據(jù)放到同一DB服務器上
例如將賣家a的商品和交易信息都放到db0中，當db1掛了的時候，賣家a相關的東西可以正常使用。也就是說避免數(shù)據(jù)庫中的數(shù)據(jù)依賴另一數(shù)據(jù)庫中的數(shù)據(jù)。
一主多備
在實際的應用中，絕大部分情況都是讀遠大于寫。Mysql提供了讀寫分離的機制，所有的寫操作都必須對應到Master，讀操作可以在Master和Slave機器上進行，Slave與Master的結構完全一樣，一個Master可以有多個Slave,甚至Slave下還可以掛Slave,通過此方式可以有效的提高DB集群的QPS.??????????????????????????????????????????????????????
所有的寫操作都是先在Master上操作，然后同步更新到Slave上，所以從Master同步到Slave機器有一定的延遲，當系統(tǒng)很繁忙的時候，延遲問題會更加嚴重，Slave機器數(shù)量的增加也會使這個問題更加嚴重。
此外，可以看出Master是集群的瓶頸，當寫操作過多，會嚴重影響到Master的穩(wěn)定性，如果Master掛掉，整個集群都將不能正常工作。
所以，1. 當讀壓力很大的時候，可以考慮添加Slave機器的分式解決，但是當Slave機器達到一定的數(shù)量就得考慮分庫了。 2. 當寫壓力很大的時候，就必須得進行分庫操作。
---------------------------------------------
MySQL使用為什么要分庫分表
可以用說用到MySQL的地方,只要數(shù)據(jù)量一大, 馬上就會遇到一個問題,要分庫分表.
這里引用一個問題為什么要分庫分表呢?MySQL處理不了大的表嗎?
其實是可以處理的大表的.我所經(jīng)歷的項目中單表物理上文件大小在80G多,單表記錄數(shù)在5億以上,而且這個表
屬于一個非常核用的表:朋友關系表.
但這種方式可以說不是一個最佳方式. 因為面臨文件系統(tǒng)如Ext3文件系統(tǒng)對大于大文件處理上也有許多問題.
這個層面可以用xfs文件系統(tǒng)進行替換.但MySQL單表太大后有一個問題是不好解決: 表結構調整相關的操作基
本不在可能.所以大項在使用中都會面監(jiān)著分庫分表的應用.
從Innodb本身來講數(shù)據(jù)文件的Btree上只有兩個鎖, 葉子節(jié)點鎖和子節(jié)點鎖,可以想而知道,當發(fā)生頁拆分或是添加
新葉時都會造成表里不能寫入數(shù)據(jù).
所以分庫分表還就是一個比較好的選擇了.
那么分庫分表多少合適呢?
經(jīng)測試在單表1000萬條記錄一下,寫入讀取性能是比較好的. 這樣在留點buffer,那么單表全是數(shù)據(jù)字型的保持在
800萬條記錄以下, 有字符型的單表保持在500萬以下.
如果按 100庫100表來規(guī)劃,如用戶業(yè)務:
500萬*100*100 = 50000000萬 = 5000億記錄.
心里有一個數(shù)了,按業(yè)務做規(guī)劃還是比較容易的.

分布式數(shù)據(jù)庫架構--排序、分頁、分組、實現(xiàn)

最近研究分布式數(shù)據(jù)庫架構，發(fā)現(xiàn)排序、分組及分頁讓著實人有點頭疼。現(xiàn)把問題及解決思路整理如下。

一、 多分片（水平切分）返回結果合并（排序）

1、Select + None Aggregate Function的有序記錄合并排序?

?????????? 解決思路：對各分片返回的有序記錄，進行排序去重合并。此處主要是編寫排序去重合

????????? 并算法。

????????? 2、Select + None Aggregate Function的無序記錄合并

?????????? 解決思路：對各分片返回的無序記錄，進行去重合并。

?????????? 優(yōu)點：實現(xiàn)比較簡單。

?????????? 缺點：數(shù)據(jù)量越大，字段越多，去重處理就會越耗時。

????????? 3、Select + Aggregate Function的記錄合并（排序）

????????? Oracle常用聚合函數(shù)：Count、Max、Min、Avg、Sum。

????????? AF：Max、Min

????????? 思路：通過算法對各分片返回結果再求max、min值。

????????? AF：Avg、Sum、Count

????????? 思路：分片間無重復記錄或字段時，通過算法對各分片返回結果再求avg、sum、count值。分片間有重復記錄或字段時，先對各分片記錄去重合并，再通過算法求avg、sum、count值。

????????? 比如：

????????? select count(*) from user

????????? select count(deptno) from user;

????????? select count(distinct deptno) from user;

二、多分片（水平切分）返回結果分頁

解決思路：合并各分片返回結果，邏輯分頁。

??????? 優(yōu)點：? 實現(xiàn)簡單。

??????? 缺點：? 數(shù)據(jù)量越大，緩存壓力就越大。

???????????????????? 分片數(shù)據(jù)量越大，查詢也會越慢。

三、多分片（水平切分）查詢有分組語法的合并

???????? 1、Group By Having + None Aggregate Function時

???????? Select + None Aggregate Function

???????? 比如：select job user group by job;

??????? 思路：直接去重（排序）合并。

??????? Select + Aggregate Function

???????? 比如：select max(sal),job user group by job;

???????? 思路：同Select + Aggregate Function的記錄合并（排序）。

???????? 2、Group By Having + Aggregate Function時

???????? 解決思路：去掉having AF條件查詢各分片，然后把數(shù)據(jù)放到一張表里。再用group by having 聚合函數(shù)查詢。

四、分布式數(shù)據(jù)庫架構--排序分組分頁參考解決方案

???????? 解決方案1：Hadoop + Hive。

???????? 思路：使用Hadoop HDFS來存儲數(shù)據(jù)，通過Hdoop MapReduce完成數(shù)據(jù)計算，通過Hive HQL語言使用部分與RDBBS一樣的表格查詢特性和分布式存儲計算特性。

???????? 優(yōu)點： 可以解決問題

?????????????????????? 具有并發(fā)處理能力

?????????????????????? 可以離線處理

???????? 缺點：? 實時性不能保證

?????????????????????? 網(wǎng)絡延遲會增加

?????????????????????? 異常捕獲難度增加

?????????????????????? Web應用起來比較復雜

????????? 解決方案2：總庫集中查詢。

????????? 優(yōu)點： 可以解決問題????????

?????????????????????? 實現(xiàn)簡單

????????? 缺點： 總庫數(shù)據(jù)不能太大

??????????????????????? 并發(fā)壓力大

五、小結

???????? 對 于分布式數(shù)據(jù)庫架構來說，排序、分頁、分組一直就是一個比較復雜的問題。避免此問題需要好好地設計分庫、分表策略。同時根據(jù)特定的場景來解決問題。也可以 充分利用海量數(shù)據(jù)存儲（Hadoop-HDFS|Hive|HBse）、搜索引擎（Lucene|Solr）及分布式計算（MapReduce）等技術來 解決問題。
別外，也可以用NoSQL技術替代關系性數(shù)據(jù)庫來解決問題，比如MogonDB\redis。

?

【轉自】http://blog.csdn.net/carechere/article/details/51211236

轉載于:https://www.cnblogs.com/bad-man/p/7988282.html

總結

以上是生活随笔為你收集整理的【转载】分布式数据库架构--分库、分表、排序、分页、分组、实现的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。