解決大量數(shù)據(jù)存儲數(shù)據(jù)庫分表分庫拓展

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

前言

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

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

附上:

喵了個咪的博客:w-blog.cn

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

開源中國Git地址:http://git.oschina.net/dogstar/PhalApi/tree/release

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

1. 場景

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

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

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

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

1.2 日志記錄分析

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

我們先來看看我們會遇到什么樣子的問題,數(shù)據(jù)量大積累當(dāng)1000w+之后數(shù)據(jù)庫執(zhí)行sql基本沒法看,大量的寫入數(shù)據(jù)對數(shù)據(jù)庫壓力大

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

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

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

大家先看一組圖就會明白了

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

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

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

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

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

   如果where條件在前置表存在從前置表通過where獲取結(jié)果集ID,通過ID分組到庫和表,然后進(jìn)行查詢在拼接結(jié)果集統(tǒng)一返回

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

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

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

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

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

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

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

2. 缺點(diǎn)

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

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

   對一些特定查詢天生不足比如排序

4. 總結(jié)

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

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

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