資料架構難點-資料分佈（r12筆記第43天）

   資料架構是架構設計中很重要的一環，可能對於很多DBA而言，資料管理，資料最佳化，資料遷移類的工作居多，而對於資料架構方面的工作也會思考少一些，這方面就會薄弱一些。

   如果在這個行業裡有一定的經驗，就會發現如果細細來看資料架構，原來很多東西我們是在這麼用，但是沒有一個系統的整理和分類來歸納出來，有些時候我們做技術很容易陷入一個漩渦，那就是很容易去考慮一些非常具體的事情，而很難從整體上來把握。今天下午看了下溫昱老師的書《一線架構師實踐指南》，這方面的很多盲點都得到了一個系統的解答。

    資料架構中的一個難點：資料分佈問題在資料架構中是很重要的一環。隨著資料，系統量級，業務場景的需求，資料分佈有6中具體策略。分別是獨立Schema,集中，分割槽，複製，子集，重組。

   這幾個概念聽起來可能有些抽象，我們逐個來說一下，其實我們很多場景就是這麼在用。

   獨立Schema：一個大系統由很多子系統組成，比如業務A有表testa,業務B有表testb,則他們都有獨立的Schema來定義存放，這樣能夠減少系統之間的相互影響，避免將問題複雜化。

這一點來說在Oracle是使用者Schema,在MySQL則是database這個層級體現出來。

   集中：這種策略的核心就是“集中儲存，分佈訪問”，比如很多業務都會訪問表test1,test2,test3,則這些資料是集中儲存起來的，不同的業務根據需求來分佈訪問。這一點用Oracle RAC來解釋最清晰不過了。可以使用共享儲存來集中式儲存應用資料，然後透過多個計算節點來擴充套件讀寫需求。

    分割槽：這個分割槽和資料庫裡的分割槽表不同，這個是基於架構層面，水平分割槽和垂直分割槽，水平分割槽的使用場景要廣泛的多，比如一個使用者資訊表，存放了不同的區域的使用者資料，我們可以根據地域來作為區分依據，這樣就把這個表的資料做這樣的拆分，放在不同的使用者下，或者放在同一個使用者表結構相同，表名不同的表裡裡面。 而相對來說，垂直分割槽的使用場景就侷限很多，比如表test有a,b,c,d四個欄位，做垂直分割槽就可以拆分，比如(a,b），（c,d） 。總體來說分割槽隨著資料量的增長需要提前規劃和設計。 

    複製：這個概念說通俗一些就是多副本，存在多分資料的情況，這個主要是透過實時或者快照級別來保持多個資料副本的資料一致性。這個策略在MySQL中Master,Slave的讀寫分離就是一個很典型的例子，或者是MySQL最新的MGR就是一個很經典的說明。 Oracle中的Primary,Active Data Guard也是一種體現。

最終是保證有多分資料副本，達到資料一致性。

    子集：這個模式相對有些抽象，和複製有一些相似，但是是子集資料的一致性，比如我們有大量的使用者交易資料，根據不同的渠道，比如網銀渠道，手機微信支付，支付寶支付等會做特定的資料子集的一致性同步。

    重組，這個分為兩種型別，統計性重組和結構性重組，就是從不同的維度來進行資料鑽取。比如我們根據一些交易資料的細節，需要得到一個基本的資料情況，比如交易流水總量，賬單資訊等，在很多統計分析的場景中就會存在，這是統計性重組。

而如果我們有使用者的概要資訊，使用者的詳細資訊放在更多具體表中關聯，這樣的情況就是結構性重組。其實Oracle中的物化檢視重新整理在平日的工作中，這兩種型別就很常見。

   

   我們簡單總結一下，比如一個醫院的使用者資料和病歷資料，從資料架構的分佈角度來考慮，該怎麼設計，首先是使用者資料，這個極可能要統一集中式管理，所以集中就是一個相對合適的方案，而使用者的病歷資料考慮到地域性的特點，為了提高效能和訪問情況，可以考慮使用複製的方案。

    比如電信行業的計費資料，資料量非常大，在資料架構的分佈上，就需要採用分割槽的策略，比如我們按照賬期的業務規則來劃分，把不同賬期的資料分佈在不同的資料儲存中。

   比如遊戲行業資料架構中的資料分佈，不同的遊戲服彼此獨立，沒有強耦合關聯，就可以考慮使用分割槽的策略，而使用者的基礎資訊這些需要做到平臺化，基於管理和安全形度，最好能夠統一規劃，所以集中就是一個很不錯的方案。

    當然從質量屬性方面來看。這6中方案還是有一定的特點，有優勢有劣勢。

     我們就從可靠性，可伸縮性，通訊開銷，客觀理性，資料一致性這幾個方面來看看六種資料分佈方案的情況。

    可靠性上，複製最佳。

    可伸縮性方面，分割槽中的水平分割槽最佳

    通訊開銷方面，獨立Schema最佳

    可管理性方面，獨立Schema和幾種策略最佳

    資料一致性方面，集中最佳。

可以發現，子集和重組均沒有入榜，也能夠間接說明這兩種資料分佈還是有一些特定的使用場景，不具有普適性。