NoSql的經常使用架構

NoSql爲輔

1. 手動同步插入數據。

//寫入數據的示例僞代碼 

//data爲咱們要存儲的數據對象
data.title=」title」;
data.name=」name」;
data.time=」2009-12-01 10:10:01」;
data.from=」1」;
id=DB.Insert(data);//寫入MySQL數據庫
NoSQL.Add(id,data);//以寫入MySQL產生的自增id爲主鍵寫入NoSQL數據庫

若是有數據一致性要求，能夠像以下的方式使用：

//寫入數據的示例僞代碼 
//data爲咱們要存儲的數據對象 
bool status=false; 
DB.startTransaction();//開始事務 
id=DB.Insert(data);//寫入MySQL數據庫 
if(id>0){ 
    status=NoSQL.Add(id,data);//以寫入MySQL產生的自增id爲主鍵寫入NoSQL數據庫 
} 
if(id>0 && status==true){ 
    DB.commit();//提交事務 
}else{ 
    DB.rollback();//不成功，進行回滾 
}

上面的代碼看起來可能以爲有點麻煩，可是隻須要在DB類或者ORM層作一個統一的封裝，就能實現重用了，其餘代碼都不用作任何的修改。

在某些能夠根據主鍵查詢的地方，使用高效的NoSQL數據庫查詢，這樣就節省了MySQL的查詢，用NoSQL的高性能來抵擋這些查詢。

2. 自動鏡像數據。

這種不經過程序代碼，而是經過MySQL把數據同步到NoSQL中，這種模式是上面一種的變體，是一種對寫入透明可是具備更高技術難度一種模式。這種模式適用於現有的比較複雜的老系統，經過修改代碼不易實現，可能引發新的問題。同時也適用於須要把數據同步到多種類型的存儲中。

MySQL到NoSQL同步的實現可使用MySQL UDF函數，MySQL binlog的解析來實現。能夠利用現有的開源項目來實現，好比：

• MySQL memcached UDFs：從經過UDF操做Memcached協議。
• 國內張宴開源的mysql-udf-http：經過UDF操做http協議。

　　有了這兩個MySQL UDF函數庫，咱們就能經過MySQL透明的處理Memcached或者Http協議，這樣只要有兼容Memcached或者Http協議的NoSQL數據庫，那麼咱們就能經過MySQL去操做以進行同步數據。再結合lib_mysqludf_json，經過UDF和MySQL觸發器功能的結合，就能夠實現數據的自動同步。

3. MySQL中只存儲須要查詢的小字段，NoSQL存儲全部數據。

//寫入數據的示例僞代碼 

//data爲咱們要存儲的數據對象
data.title=」title」;
data.name=」name」;
data.time=」2009-12-01 10:10:01」;
data.from=」1」;
bool status=false;
DB.startTransaction();//開始事務
id=DB.Insert(「INSERT INTO table (from) VALUES(data.from)」);//寫入MySQL數據庫,只寫from須要where查詢的字段
if(id>0){
status=NoSQL.Add(id,data);//以寫入MySQL產生的自增id爲主鍵寫入NoSQL數據庫
}
if(id>0 && status==true){
DB.commit();//提交事務
}else{
DB.rollback();//不成功，進行回滾
}

　把須要查詢的字段，通常都是數字，時間等類型的小字段存儲於MySQL中，根據查詢創建相應的索引，其餘不須要的字段，包括大文本字段都存儲在NoSQL中。在查詢的時候，咱們先從MySQL中查詢出數據的主鍵，而後從NoSQL中直接取出對應的數據便可。

這種架構模式把MySQL和NoSQL的做用進行了融合，各司其職，讓MySQL專門負責處理擅長的關係存儲，NoSQL做爲數據的存儲。它有如下優勢：

• 節省MySQL的IO開銷。因爲MySQL只存儲須要查詢的小字段，再也不負責存儲大文本字段，這樣就能夠節省MySQL存儲的空間開銷，從而節省MySQL的磁盤IO。咱們曾經經過這種優化，把MySQL一個40G的表縮減到幾百M。
• 提升MySQl Query Cache緩存命中率。咱們知道query cache緩存失效是表級的，在MySQL表一旦被更新就會失效，通過這種字段的分離，更新的字段若是不是存儲在MySQL中，那麼對query cache就沒有任何影響。而NoSQL的Cache每每都是行級別的，只對更新的記錄的緩存失效。
• 提高MySQL主從同步效率。因爲MySQL存儲空間的減少，同步的數據記錄也減少了，而部分數據的更新落在NoSQL而不是MySQL，這樣也減小了MySQL數據須要同步的次數。
• 提升MySQL數據備份和恢復的速度。因爲MySQL數據庫存儲的數據的減少，很容易看到數據備份和恢復的速度也將極大的提升。
• 比之前更容易擴展。NoSQL天生就容易擴展。通過這種優化，MySQL性能也獲得提升。

NoSql爲主： 

1. 純nosql。

在一些數據庫結構常常變化，數據結構不定的系統中，就很是適合使用NoSQL來存儲。好比監控系統中的監控信息的存儲，可能每種類型的監控信息都不太同樣。這樣能夠避免常常對MySQL進行表結構調整，增長字段帶來的性能問題。

　　這種架構的缺點就是數據直接存儲在NoSQL中，不能作關係數據庫的複雜查詢，若是因爲需求變動，須要進行某些查詢，可能沒法知足，因此採用這種架構的時候須要確認將來是否會進行復雜關係查詢以及如何應對。

　MongoDB就帶有關係查詢的功能，能解決經常使用的關係查詢。

2. 以NoSQL爲數據源的架構。

 

純NoSQL的架構雖然結構簡單，易於開發，可是在應付需求的變動、穩定性和可靠性上，老是給開發人員一種風險難於控制的感受。爲了下降風險，系統的功能不侷限在NoSQL的簡單功能上，咱們可使用以NoSQL爲數據源的架構。

　　在這種架構中，應用程序只負責把數據直接寫入到NoSQL數據庫就OK，而後經過NoSQL的複製協議，把NoSQL數據的每次寫入，更新，刪除操做都複製到MySQL數據庫中。同 時，也能夠經過複製協議把數據同步複製到全文檢索實現強大的檢索功能。在海量數據下面，咱們也能夠根據不一樣的規則，把數據同步複製到設計好的分表分庫的 MySQL中。這種架構：

• 很是靈活。能夠很是方便的在線上系統運行過程當中進行數據的調整，好比調整分庫分表的規則、要添加一種新的存儲類型等等。
• 操做簡單。只須要寫入NoSQL數據庫源，應用程序就不用管了。須要增長存儲類型或者調整存儲規則的時候，只須要增長同步的數據存儲，調整同步規則便可，無需更改應用程序的代碼。
• 性能高。數據的寫入和更新直接操做NoSQL，實現了寫的高性能。而經過同步協議，把數據複製到各類適合查詢類型的存儲中（按照業務邏輯區分不一樣的存儲），能實現查詢的高性能，不像之前MySQL一種數據庫就全包了。或者就一個表負責跟這個表相關的全部的查詢，如今能夠把一個表的數據複製到各類存儲，讓各類存儲用本身的長處來對外服務。
• 易擴展。開發人員只須要關心寫入NoSQL數據庫。數據的擴展能夠方便的在後端由複製協議根據規則來完成。

　　這種架構須要考慮數據複製的延遲問題，這跟使用MySQL的master-salve模式的延遲問題是同樣的，解決方法也同樣。

　　在這種以NoSQL爲數據源的架構中，最核心的就是NoSQL數據庫的複製功能的實現。而當前的幾乎全部的NoSQL都沒有提供比較易於使用的複製接口來完成這種架構，對NoSQL進行復制協議的二次開發，須要更高的技術水平，因此這種架構看起來很好，可是卻不是很是容易實現的。個人開源項目PHPBuffer中有個實現TokyoTyrant複製的例子，雖然是PHP版本的，可是很容易就能夠翻譯成其餘語言。經過這個例子的代碼，能夠實現從Tokyo Tyrant實時的複製數據到其餘系統中。