PHALAPI-進(jìn)階篇6(解決大量數(shù)據(jù)存儲(chǔ)數(shù)據(jù)庫(kù)分表分庫(kù)拓展)

前言

時(shí)隔半個(gè)月隨著PHP7的推出為PHP打了一瓶興奮劑,在性能提升了一倍的情況下我們會(huì)逐漸發(fā)現(xiàn),瓶頸會(huì)集中在數(shù)據(jù)庫(kù)操作,那我們的內(nèi)容就接著數(shù)據(jù)庫(kù)讀寫(xiě)分離,來(lái)聊聊分表分庫(kù)應(yīng)該怎么玩,因?yàn)镻halApi的分表分庫(kù)并不是非常方便,筆者在這里提供了一個(gè)分表分庫(kù)數(shù)據(jù)庫(kù)集群的拓展,詳細(xì)文檔請(qǐng)見(jiàn)博客基于PhalApi的DB集群拓展 V0.1bate 大家可以自行在開(kāi)源中國(guó)擴(kuò)展Git地址中找到Cluster進(jìn)行下載使用.

先在這里感謝phalapi框架創(chuàng)始人@dogstar,為我們提供了這樣一個(gè)優(yōu)秀的開(kāi)源框架.

附上:

喵了個(gè)咪的博客:w-blog.cn

官網(wǎng)地址:http://www.phalapi.net/

開(kāi)源中國(guó)Git地址:http://git.oschina.net/dogstar/PhalApi/tree/release

開(kāi)源中國(guó)擴(kuò)展Git地址:http://git.oschina.net/dogstar/PhalApi-Library

1. 場(chǎng)景

在實(shí)際工作中,我信奉一句話一切拋開(kāi)業(yè)務(wù)的架構(gòu)設(shè)計(jì)都是耍流氓所以我們從場(chǎng)景進(jìn)行開(kāi)篇

1.1 單條數(shù)據(jù)多查多寫(xiě)多改

這里做的例子,大家都在玩游戲把,玩游戲里面是不是有角色,角色是不是有裝備,經(jīng)驗(yàn),物品以及等等,而且他會(huì)有一個(gè)特別的要求就是實(shí)時(shí)(因?yàn)槲医巧蛄艘粋€(gè)怪物獲得了100xp我們不可能告訴他你等6個(gè)小時(shí)緩存時(shí)間結(jié)束了再來(lái)看,必須是實(shí)時(shí)的),當(dāng)然我們可以使用緩存來(lái)解決這個(gè)問(wèn)題我們下節(jié)會(huì)說(shuō)到這個(gè)問(wèn)題

那么在這種場(chǎng)景下,一個(gè)用戶對(duì)于角色的操作非常頻繁而且唯一我們就很好采用分表分庫(kù)的操作了,相對(duì)于單表操作他會(huì)把所有的操作分散到各個(gè)數(shù)據(jù)庫(kù)去操作,這樣對(duì)于單個(gè)數(shù)據(jù)庫(kù)總執(zhí)行sql語(yǔ)句量就會(huì)有個(gè)指數(shù)級(jí)的下降,以及數(shù)據(jù)量也會(huì)均衡分配到每個(gè)數(shù)據(jù)庫(kù),但是當(dāng)我們進(jìn)行這類(lèi)單條數(shù)據(jù)操作的時(shí)候根本不會(huì)對(duì)性能有任何的影響,因?yàn)橹皇峭ㄟ^(guò)算法得出了這條記錄存在于那個(gè)庫(kù)那張表而已,

1.2 日志記錄分析

就已上面的例子我們繼續(xù)講,如果有一天你的領(lǐng)導(dǎo)過(guò)來(lái)提了個(gè)需求,我需要一個(gè)數(shù)據(jù)分析系統(tǒng)來(lái)統(tǒng)計(jì)用戶每天什么時(shí)間段最活躍.用戶平均每人充值了多少錢(qián)啊,多少等級(jí)下用戶充錢(qián)最多啊,如果遇到這種問(wèn)題你們會(huì)怎么辦?三分鐘思考

我們先來(lái)看看我們會(huì)遇到什么樣子的問(wèn)題,數(shù)據(jù)量大積累當(dāng)1000w+之后數(shù)據(jù)庫(kù)執(zhí)行sql基本沒(méi)法看,大量的寫(xiě)入數(shù)據(jù)對(duì)數(shù)據(jù)庫(kù)壓力大

我們?cè)賮?lái)看看分表分庫(kù)怎么解決這個(gè)問(wèn)題,1000w+數(shù)據(jù)庫(kù)的情況下 比如你是4表4庫(kù)一共16張表,那每張表的數(shù)量就是1000w/16=62w也就是每張表只需要存儲(chǔ)62w的數(shù)據(jù)就ok了,當(dāng)寫(xiě)入數(shù)據(jù)的時(shí)候會(huì)根據(jù)ID的順序均衡寫(xiě)入4庫(kù)執(zhí)行sql的壓力也就分布到了4個(gè)數(shù)據(jù)庫(kù),唯一的問(wèn)題就是在執(zhí)行where條件的時(shí)候可能需要對(duì)前置表進(jìn)行遍歷,而前置表的數(shù)據(jù)量就是1000w,當(dāng)然前置表里面只存放ID和where條件的字段

2. 實(shí)現(xiàn)思路

就筆者在工作中接觸到了很多案例的分表分庫(kù)，使用了根據(jù)城市,或者是其他的特性進(jìn)行分表分庫(kù)規(guī)則,這樣一定會(huì)出現(xiàn)用戶分布不均勻?qū)е碌哪骋粋€(gè)庫(kù)表壓力巨大,我這里使用了均等分分割

大家先看一組圖就會(huì)明白了

1. 當(dāng)我們進(jìn)行插入的時(shí)候的操作如下:

   插入前置表獲取主鍵,通過(guò)id得出應(yīng)該存入幾庫(kù)幾表在相應(yīng)的地方寫(xiě)入數(shù)據(jù)

2. 當(dāng)我們進(jìn)行單條讀取操作的時(shí)候操作如下:

   通過(guò)id獲取應(yīng)該在幾庫(kù)幾表在相應(yīng)的地方獲取數(shù)據(jù)

3. 當(dāng)我們使用where查詢(xún)的時(shí)候操作如下:

   如果where條件在前置表存在從前置表通過(guò)where獲取結(jié)果集ID,通過(guò)ID分組到庫(kù)和表,然后進(jìn)行查詢(xún)?cè)谄唇咏Y(jié)果集統(tǒng)一返回

3. 優(yōu)缺點(diǎn)

1. 優(yōu)點(diǎn):

   很好的避開(kāi)了數(shù)據(jù)庫(kù)存放數(shù)據(jù)過(guò)多效率底下的瓶頸

   在單條記錄操作性能指數(shù)及提升

   數(shù)據(jù)量大的情況下where條件查詢(xún)性能提高基本

   能對(duì)億級(jí)的數(shù)據(jù)進(jìn)行處理而且效率較高

   不需要考慮分表分庫(kù)規(guī)則數(shù)據(jù)均等分布

2. 缺點(diǎn)

   where查詢(xún)字段必須預(yù)先添加到,前置表不然就必須遍歷數(shù)據(jù)庫(kù)數(shù)量 * 表數(shù)量才能得到想要的結(jié)果

   where查詢(xún)就算有前置表的情況下最壞的情況也需要遍歷數(shù)據(jù)庫(kù)數(shù)量 * 表數(shù)量才能得到想要的結(jié)果

   對(duì)一些特定查詢(xún)天生不足比如排序

4. 總結(jié)

在本小節(jié)的最好簡(jiǎn)單提及一下,基于PhalApi的DB集群拓展 V0.1bate功能展示比較局限童鞋們可以根據(jù)自己的業(yè)務(wù)需求來(lái)覺(jué)得是否使用,筆者也會(huì)在后期繼續(xù)更新維護(hù)完善為一個(gè)比較方便的集群拓展.

注:筆者能力有限有說(shuō)的不對(duì)的地方希望大家能夠指出,也希望多多交流!

官網(wǎng)QQ交流群:421032344 歡迎大家的加入!