基於PhalApi的DB集羣拓展 V0.1bate

#基於PhalApi的DB集羣拓展 V0.1bate

##前言## 先在這裏感謝phalapi框架創始人@dogstar,爲咱們提供了這樣一個優秀的開源框架.

編寫本次拓展出於的目的是解決大量數據寫入分析的問題,也但願本拓展能對你們有些幫助,可以解決你們遇到的一樣的問題.

注:V0.1bate版本,不少功能尚不完善,只提供技術交流使用,請不要用戶生產環境

附上:

官網地址:http://www.phalapi.net/

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

##1.原由##

說到爲何寫這個拓展,原由是這樣的,在和產品交流的時候他們但願能夠存一些東西做爲數據分析用,我考慮過hadoop可是若是說使用hadoop須要投入的成本過高了,在想有沒有什麼好辦法的時候,想到了分表分庫解決數據量大的問題,那麼能夠有一個封裝好的服務就和操做數據庫同樣操做能夠達到良好的分表分庫的效果嗎,出於這個考慮就開始這個拓展的編寫.

##2.業務場景##

1. 大量select

   當一個數據庫須要對付大量的select請求的時候,咱們每每會想到使用讀寫分離來解決此類問題,一個寫庫多個讀庫,一臺或多臺服務器用一個讀庫,全部的寫入操做使用主庫操做,應爲是大量的select操做,讀的壓力被分配到了不少個讀庫實例,能夠很好的解決問題大量select的問題,再者就是進行添加緩存機制的優化,這樣也是能很好的解決問題

2. 大量的insert

   對於大量insert上面所謂的讀寫分離徹底不夠看了,全部的壓力所有會集中在負責寫入的主庫,但並非應爲併發請求的問題,問題是在於數據量大致使不論是幹嗎都會慢,當數據量到了上億的級別簡直不敢想像,若是是經過分表分庫(若是是4庫4表也就是16張表),數據分均衡的分配到(庫數量-乘-表數量)這麼多張表裏面從而達到解決大量數據的問題(在分表分庫前面有一個主表),固然他也有缺陷就是當進行條件查詢的時候最壞的條件會遍歷(庫數量-乘-表數量)這麼多張表才能得到想要的結果,因此不是很建議用到查詢列表比較平凡的應用中,固然結合緩存和讀寫分離能夠緩解壓力

##3.使用拓展##

###3.1 下載/註冊拓展###

你們能夠到Git項目PhalApi Library下載拓展文件,把其中的DB_Cluster文件夾複製到/PhalApi/Library目錄下,以下圖:

把其中的Config中的cluster.php文件放到默認的Config配置文件中

而後在init.php中註冊如下兩句話

初始化配置文件
DI()->Cluster_DB = new Cluster_Lite(DI()->config->get('cluster'));

而後把框架自帶的Demo文件替換成拓展自帶的Demo文件以下就完成了第一步

###3.2 數據庫集羣初始化###

這裏使用Mysql做爲集羣的數據庫

你們能夠看到拓展文件裏面有一個Data/user_cluster.sql 文件,裏面有一個 user_base的建表語句和另外user0,user1,user2,user3這四個表的建表語句

在文件裏面有一些注意事項這裏這裏再次強調一下

--本次集羣採起4庫每一庫4表 4*4共16表的mysql集羣(基礎庫不算在裏面)

--基礎庫(id自增加,用表索引進行列表查詢條件)
--庫名project
--當本身創建集羣mysql的時候要注意如下幾點
--1.必定要注意ID要加上自動增加,這裏進行的分表分庫都是基於自增ID進行的,若是是自定義字符串ID須要進行算法修改,也可使用其餘緩存生成自增ID
--2.除了ID以外的字段(用於按條件查詢列表ID)必定要加上索引或者是主鍵,否則數據量大的時候獲取列表ID會很慢
--3.除了ID以外的字段必定要是更具業務需求進行查詢比較頻繁的,並且要保持儘可能的少1-2個,大於2個建議在分出一張表作對應

--庫名分表爲user_cluster0,user_cluster1,user_cluster2,user_cluster3(可自定)
--下面四張表爲每個庫中都擁有的4張表(注意ID不能使用自動增加)
--表名能夠自定可是每一個庫中的表名必定要統一	
--user0,user1,user2,user3

我這裏使用結構以下(你們能夠自由的配置能夠2庫+2表,2庫+4表等都行,只需在配置文件中配置就可)

數據庫project
		-user_base表
數據庫user_cluster0,user_cluster1,user_cluster2,user_cluster3
		都有如下表
		-user0,user1,user2,user3

###3.3 配置文件詳解###

咱們需在在默認dbs.php 數據庫配置中配置連接好project庫

而後你們看向cluster.php集羣配置文件按照註釋配置好本身的數據庫,若是沒有多個mysql實例,能夠一個實例創建4個庫模擬4個mysql分佈式集羣.

這裏指的着重講一下的是如下配置問題

/**
 * 配置表
 */
'cluster' => array(
    //集羣分佈配置
    'list'    => array(
        'demo'  => array(
            //使用demo集羣配置最大ID和最小ID,最大ID爲0等於不上限
            'id_min' => 0,
            'id_max' => 0,
        ),
    ),
    //where查詢條件放到衍生表中的字段
    'where'   => array(
        'city'
    ),
    //ID名稱
    'id_name' => 'uId',
),

在list中能夠配置多個集羣數組KEY的名稱對應配置文件上面demo集羣而且能夠設定ID範圍,作這個設計主要是爲了當我有一個2庫*2表的集羣,已經承載了1個億的數據了,已經沒法承擔數據量了這個時候就要更換集羣,在這裏只須要吧demo的id_max配置成1億,在配置一個demo1而後把id_min設定到1億,當ID大於1億了以後就會本身找到第二集羣插入數據了(不用擔憂多集羣了以後查詢以及其餘操做這裏已經作好了兼容)

還有where屬性,這裏的where用於配置在user_base表中除了ID以外的索引字段可以增長查詢的性能,可是儘可能少應爲這個會減小base表的性能,能夠適當的取捨

###3.4 開始使用###

你們看向Demo的API文件中有四個接口select,delete,update,insert裏面的參數都是隨機生成的

在看向Cluster/User.php裏面繼承了Cluster_DB須要使用數據庫集羣就須要集成這個類而且實現如下兩個方法

/**
 * 獲取集羣實例類
 */
public function getCluster(){
    return DI()->Cluster_DB;
}

/**
 * 獲取主數據庫表實例
 */
public function getMainDB(){
    return DI()->notorm->user_base;
}

getCluster方法返回在init.php中註冊DI()->Cluster_DB便可,由於一個集羣對應一張表能夠根據需求使用不通的集羣實例

getMainDB方法是爲了獲取base表的實例只須要把表實例返回便可

當作好這幾件事情你們就能夠嘗試請求接口看看結果了

##4. 實現思想講解##

1. 實現架構思惟

   我在開始寫這個拓展以前在想要讓使用者如何去使用這個框架,怎麼讓使用者最方便,最後的到的答案是若是能夠和正常使用Model層同樣去使用的話是最好的,因此你們能夠看到在Demo/Cluster/User.php中增刪改查和正常使用基本沒有區別.

2. 分表分庫算法

   當咱們是2庫2表的狀況下,咱們用2乘2=4而後用咱們獲取的ID好比55,用55%2乘2 就會獲得一個小於4的數字,55獲得的是3,用3/表數2=1.5取整是1表,而後用3%表數2=1,也就是存入1庫1表(注意是從0開始算的)

##5. 基準測試##

###5.1 base表基準測試###

由於咱們的拓展是須要基於一個base表實現ID增加和where語句查詢在分到集羣庫,因此base庫須要應付的量比較大因此這裏對base表進行了一次針對於不一樣數據量進行的單ID查詢和where查詢基準測試

300w數據:

5700w數據:

1.3億數據:

明顯能夠看出來隨着數據量的增長查詢速度有明顯的下降,可是到了億級的時候還能維持到where條件查詢不上0.1秒的狀況仍是比較理想的,最關鍵的是在億級的時候插入仍是至關快的因此很是適合,大量數據的寫入,若是是對查詢有比較大的要求的童鞋能夠考慮吧5000W做爲一個分界點對基礎base進行劃分(後期將會把此功能集成到拓展內部)

###5.2 從小.中.大數據庫就集羣與單表實際狀況併發對比###

應爲工做量比較大還在進行測試中!

##6. 總結##

在此但願本擴展能給你們帶來解決實際問題的思路,初版是bate版本請不要使用在生產環境中,若是出現問題或者是有BUG能夠直接聯繫我QQ591235675也可加入PhalApi交流羣一同交流探討

注:筆者能力有限有說的不對的地方但願你們可以指出,也但願多多交流!

官網QQ交流羣:421032344 歡迎你們的加入!