零售系統軟件架構---數據架構之數據分片

一、概述

                對於一個由多個子系統組成的一個完整的系統而言。系統之間的交互，也在很大程度上反映了數據分佈的情況。每個業務系統都具有自己本系統獨特的業務數據。所以，目前每個業務系統一個業務庫的形式。

                這種就是類似大家常說的垂直分庫。然而隨着業務單據的劇增，單一業務庫的壓力自然上升，特別是對企業應用而言，業務操作的重要性擺在第一位的。垂直分庫的基礎上，需要引入讀寫分離與水平分庫分表策略。一般而言，讀壓力大時，我們採用讀寫分離就可以了，然而剛纔說到，企業業務操作的比例，技術上講就是寫的壓力遠大於讀的壓力。特別是銷售系統以及庫存系統（不考慮報表，實際上，報表也要根據時效性，做不同處理。也分業務類，管理類）。

               一是量大，一個寫要求性能較高。

二、選型

               目前我們業務庫使用的是mysql數據庫。網上也有一些拆分標準，比如：

  1、表的體積大於2G或行數大於1000w,以單表主鍵等簡單形式訪問數據，這個時候需要分表。
  2、表的體積大於2G或行數大於500W,以兩表jion，小範圍查詢（結果集小100行）等形式訪問數據，這個時候需要分表。
  3、表的體積大於2G或行數大於200w,以多表join，範圍查詢，order by，group by，高頻率等複雜形式訪問數據，尤其DML，這個時候需要分表。

在Mysql中，如果將拆分機制，結果集處理等應用特性寫在我們的邏輯代碼中，將是很恐怖的一件事情。急需一款Mysql中間件產品。

               基礎開發組預研中，選定Mycat作爲我們的數據庫中間層。

 MyCAT的官網提到的 關鍵特性：（詳情見官網 http://mycat.org.cn/）

• 支持 SQL 92標準
• 支持Mysql集羣，可以作爲Proxy使用
• 支持JDBC連接ORACLE、DB2、SQL Server，將其模擬爲MySQL  Server使用
• 支持galera for mysql集羣，percona-cluster或者mariadb cluster，提供高可用性數據分片集羣
• 自動故障切換，高可用性
• 支持讀寫分離，支持Mysql雙主多從，以及一主多從的模式
• 支持全局表，數據自動分片到多個節點，用於高效表關聯查詢
• 支持獨有的基於E-R 關係的分片策略，實現了高效的表關聯查詢
• 多平臺支持，部署和實施簡單

              實際開發中，需要確定哪些表需要拆分，以及需要什麼樣的拆分策略。標準就是上述拆分標準。單使用什麼樣的拆分策略需要根據各子系統特徵來確定。

三、拆分策略

              數據拆分需要了解下數據分佈的方式，一種是哈希分佈，比如一致性哈希；另一種方式是順序分佈，按照主鍵整體有序。所以不管是何種中間件也好，分佈式數據庫也好，數據分佈大致是這兩種分佈形式。其他一些優化的分佈方式大都在這兩個基礎分佈之上衍生出來的。

             所以，我們講拆分策略也基本上按照數據分佈的方式來定義。具體到分片字段的選擇。分片策略會受數據訪問特點的影響，所以在進行數據分片前，最好先理清楚數據的訪問特點，並想明白是否確實需要分片。分片字段對性能的影響非常大，所以選擇一個好的分片字段是非常重要的。

             那數據訪問一般都有哪些特點呢：

             大的方面分OLAP，OLTP，我們目前的系統都是業務作業層面的，mysql數據庫。OLTP，如果再細分的話，我們可以粗略劃分，是讀密集型，還是寫密集型，以及讀寫密集型，還有更新頻度如何？不管何種形式，我們要確保的是訪問的壓力能均衡到各個存儲系統實例上去。聽上去是一個理想的做法，實際在也要做各種取捨。

             1、寫操作可擴展

                   使用分片的一個主要原因之一是分散寫操作。爲了實現這個目標，儘可能的將寫操作分散到多個分片就尤爲重要了。

             2、讀查詢隔離
                   另外一個需要考慮的是任何一個查詢操作將會由多少個分片來來提供服務。最理想的情況是，一個查詢操作直接從Mycat進程路由到一個Mysql分片上去，並且這個Mysql擁有該次查詢的全部數據。

             3、排序

四、拆分字段的提取

                拆分表爲依據，查找所以該表相關的SQL語句，關聯查詢或是子查詢。然後根據Where或是Join字段確定分片字段，再根據關聯表關係，確定相關表拆分策略。