電商數據庫網摘

oracle集羣
Oracle RAC是業界最流行的產品。其架構的最大特色是共享存儲架構（Shared-disk），整個RAC集羣是創建在一個共享的存儲設備之上的，節點之間採用 高速網絡互連。在 Oracle RAC 環境中，每一個 Oracle 數據塊都被賦予一個（且只有一個）「主」Oracle RAC 節點。該 Oracle RAC 節點的全局緩存服務 (GCS) 負責管理對這些數據塊集的訪問。當其中一個 Oracle 節點須要訪問某個 Oracle 數據塊時，它必須首先與該數據塊協商。而後，該主節點的 GCS 或者指示請求的 Oracle 節點從磁盤中獲取該數據塊，或者指示該Oracle 數據塊的當前持有者將被請求的數據塊發送到請求節點。Oracle 嘗試跨全部 RAC 節點統一分發該數據塊的全部權。在 Oracle RAC 環境中，數據塊大體相等的全部節點都將被指定爲主節點。（若是 Oracle RAC 節點數是 Oracle 數據塊數的約數，則全部 RAC 節點都是具備一樣數量的數據塊的主節點。）

mysql集羣
MySQL cluster和Oracle RAC徹底不一樣，它採用Shared-nothing架構。整個集羣由管理節點(ndb_mgmd)，處理節點(mysqld)和存儲節點(ndbd)組 成，不存在一個共享的存儲設備。MySQL cluster主要利用了NDB存儲引擎來實現，NDB存儲引擎是一個內存式存儲引擎，要求數據必須所有加載到內存之中。數據被自動分佈在集羣中的不一樣存 儲節點上，每一個存儲節點只保存完整數據的一個分片(fragment)。同時，用戶能夠設置同一份數據保存在多個不一樣的存儲節點上，以保證單點故障不會形成數據丟失。
MySQL cluster的優勢在於其是一個分佈式的數據庫集羣，處理節點和存儲節點均可以線性增長，整個集羣沒有單點故障，可用性和擴展性均可以作到很高，更適合 OLTP應用。可是它的問題在於：1.NDB存儲引擎必需要求數據所有加載到內存之中，限制比較大，可是目前NDB新版本對此作了改進，容許只在內存中加 載索引數據，數據能夠保存在磁盤上。2.目前的MySQL cluster的性能還不理想，由於數據是按照主鍵hash分佈到不一樣的存儲節點上，若是應用不是經過主鍵去獲取數據的話，必須在全部的存儲節點上掃描， 返回結果處處理節點上去處理。並且，寫操做須要同時寫多份數據到不一樣的存儲節點上，對節點間的網絡要求很高。

分佈式數據庫拆分

數據庫分片
Sharding 不是一個某個特定數據庫軟件附屬的功能，而是在具體技術細節之上的抽象處理，是水平擴展(Scale Out，亦或橫向擴展、向外擴展)的解決方案，其主要目的是爲突破單節點數據庫服務器的 I/O 能力限制，解決數據庫擴展性問題。
把熱度高的數據劃分開來，使用配置恰好的硬件，提升訪問速度，加強用戶體驗
把不一樣的用戶的數據根據用戶的id放到不一樣的數據庫中，不一樣用戶對應的交易數據也跟着到不一樣的數據庫；以後能夠把交易完成和正在交易的數據庫分開。
一個全國經濟信息系統，能夠按照不一樣地區把不一樣數據放到不一樣數據庫中，隨着時間增長數據也會愈來愈大，到時還能夠工具年份在從新劃分數據庫。
一個大中型的電子商的電子商務網站必定會遇到數據量巨大的問題，能夠根據用戶對象或者使用和被使用的數據進行分片。這樣避免了在一個庫中數據膨脹而帶來的瓶頸。
在數據庫分片時最好分到不一樣的服務器中，或者不一樣的存儲中，避免磁盤競爭 
數據庫分片存在比較大問題就是人查詢或者統計涉及到跨庫就比較麻煩。特別是join時若是涉及到多個節點，將很是困難，應該儘可能避免。

數據庫水平分片

讀寫分離
讀寫分離架構利用了數據庫的複製技術，將讀和寫分佈在不一樣的處理節點上，從而達到提升可用性和擴展性的目的。
讀寫分離簡單的說是把對數據庫讀和寫的操做分開對應不一樣的數據庫服務器，這樣能有效地減輕數據庫壓力，也能減輕io壓力。主數據庫提供寫操做，從數據庫提供讀操做，其實在不少系統中，主要是讀的操做。當主數據庫進行寫操做時，數據要同步到從的數據庫，這樣纔能有效保證數據庫完整性。Quest SharePlex就是比較牛的同步數據工具，據說比oracle自己的流複製還好，mysql也有本身的同步數據技術。mysql只要是經過二進制日誌來複制數據。經過日誌在從數據庫重複主數據庫的操做達到複製數據目的。這個複製比較好的就是經過異步方法，把數據同步到從數據庫。
主數據庫同步到從數據庫後，從數據庫通常由多臺數據庫組成這樣才能達到減輕壓力的目的。讀的操做怎麼樣分配到從數據庫上？應該根據服務器的壓力把讀的操做分配到服務器，而不是簡單的隨機分配。mysql提供了MySQL-Proxy實現讀寫分離操做。不過MySQL-Proxy好像好久不更新了。oracle能夠經過F5有效分配讀從數據庫的壓力。
上面說的數據庫同步複製，都是在從同一種數據庫中，若是我要把oracle的數據同步到mysql中，其實要實現這種方案的理由很簡單，mysql免費，oracle太貴。好像Quest SharePlex也實現不了改功能吧。好像如今市面尚未這個工具吧。那樣應該怎麼實現數據同步？其實咱們能夠考慮本身開發一套同步數據組件，經過消息，實現異步複製數據。其實這個實現起來要考慮不少方面問題，高併發的問題，失敗記錄等。其實這種方法也能夠同步數據到memcache中。據說oracle的Stream也能實現，不過沒有試過。
經過ebay讀寫分離的結構圖，經過Share Plex 近乎實時的複製數據到其餘數據庫節點，再經過F5特定的模塊檢查數據庫狀態，並進行負載均衡，IO 成功的作到了分佈，讀寫分離，並且極大的提升了可用性。目前讀寫分離技術比較多，比較有名的爲amoeba，有興趣的同窗能夠研究下。

數據庫緩存
讀寫分離如今應用很是普遍，特別是時國內外大型網站，都使用的很是多，不少都是本身研發緩存系統，淘寶還開源了Tair系統，有興趣的能夠研究下。比較有名的是memcached使用memcached最好的可能算facebook了。經過memcached分擔讀的操做，把經常使用的對象數據存儲到memcached中，當有讀操做過來時先訪問memcached若是memcached沒有該數據再從數據庫獲取，同時把數據放到memcached中，下次訪問就能夠直接訪問memcached了。

有一次在和一個朋友聊天時他們正在着手在線文檔系統架構設計，因爲文檔訪問壓力很是大，每次請求數據庫也很是大，因爲大量的的文檔數據在服務端和客戶端傳輸，會常常形成網絡堵塞。我建議他能夠把文檔分片，減小一次性大文件傳輸。再根據文檔熱度把一些文檔保持到緩存中。其實文檔也好，數據庫也好，不少方法只要根據業務要求也能夠達到殊途同歸的之效。