對於乙個由多個子系統組成的乙個完整的系統而言。系統之間的互動，也在很大程度上反映了資料分布的情況。每個業務系統都具有自己本系**特的業務資料。所以，目前每個業務系統乙個業務庫的形式。
這種就是類似大家常說的垂直分庫。然而隨著業務單據的劇增，單一業務庫的壓力自然上公升，特別是對企業應用而言，業務操作的重要性擺在第一位的。垂直分庫的基礎上，需要引入讀寫分離與水平分庫分表策略。一般而言，讀壓力大時，我們採用讀寫分離就可以了，然而剛才說到，企業業務操作的比例，技術上講就是寫的壓力遠大於讀的壓力。特別是銷售系統以及庫存系統（不考慮報表，實際上，報表也要根據時效性，做不同處理。也分業務類，管理類）。
一是量大，乙個寫要求效能較高。
目前我們業務庫使用的是mysql資料庫。網上也有一些拆分標準，比如：
1、表的體積大於2g或行數大於1000w,以單錶主鍵等簡單形式訪問資料，這個時候需要分表。
2、表的體積大於2g或行數大於500w,以兩表jion，小範圍查詢（結果集小100行）等形式訪問資料，這個時候需要分表。
3、表的體積大於2g或行數大於200w,以多表join，範圍查詢，order by，group by，高頻率等複雜形式訪問資料，尤其dml，這個時候需要分表。
在mysql中，如果將拆分機制，結果集處理等應用特性寫在我們的邏輯**中，將是很恐怖的一件事情。急需一款mysql中介軟體產品。
基礎開發組預研中，選定mycat作為我們的資料庫中間層。
mycat的官網提到的 關鍵特性：（詳情見官網
實際開發中，需要確定哪些表需要拆分，以及需要什麼樣的拆分策略。標準就是上述拆分標準。單使用什麼樣的拆分策略需要根據各子系統特徵來確定。
資料拆分需要了解下資料分布的方式，一種是雜湊分布，比如一致性雜湊；另一種方式是順序分布，按照主鍵整體有序。所以不管是何種中介軟體也好，分布式資料庫也好，資料分布大致是這兩種分布形式。其他一些優化的分布方式大都在這兩個基礎分布之上衍生出來的。
所以，我們講拆分策略也基本上按照資料分布的方式來定義。具體到分片欄位的選擇。分片策略會受資料訪問特點的影響，所以在進行資料分片前，最好先理清楚資料的訪問特點，並想明白是否確實需要分片。分片欄位對效能的影響非常大，所以選擇乙個好的分片欄位是非常重要的。
那資料訪問一般都有哪些特點呢：
大的方面分olap，oltp，我們目前的系統都是業務作業層面的，mysql資料庫。oltp，如果再細分的話，我們可以粗略劃分，是讀密集型，還是寫密集型，以及讀寫密集型，還有更新頻度如何？不管何種形式，我們要確保的是訪問的壓力能均衡到各個儲存系統例項上去。聽上去是乙個理想的做法，實際在也要做各種取捨。
1、寫操作可擴充套件
使用分片的乙個主要原因之一是分散寫操作。為了實現這個目標，盡可能的將寫操作分散到多個分片就尤為重要了。
2、讀查詢隔離
另外乙個需要考慮的是任何乙個查詢操作將會由多少個分片來來提供服務。最理想的情況是，乙個查詢操作直接從mycat程序路由到乙個mysql分片上去，並且這個mysql擁有該次查詢的全部資料。
3、排序
拆分表為依據，查詢所以該錶相關的sql語句，關聯查詢或是子查詢。然後根據where或是join欄位確定分片字段，再根據關聯表關係，確定相關表拆分策略。
零售系統軟體架構 設計之快取篇
快取在我們系統內部也廣泛使用，基本分本地快取和分布式快取。本地快取由自定義寫的快取元件，分靜態快取與動態快取，所謂靜態就是資料存入就不會被應用清除，動態快取採用lru淘汰策略。本地快取自不多說。但就使用的分布式快取redis說明下。說到快取的使用場景，1 需要經常訪問 2 是很少發生改動 如果使用快...
零售魔方 大資料質變零售企業價值
在這個資訊化迅速的當下，大資料已經悄然改變我們的生活。可能你不能直接觸碰的到資料的領域，但是一舉一動，卻在大資料分析下能夠清晰地描繪出你的 模樣 最初，大資料影響還是在電商平台，他們開始利用自己的 平台，對於消費者的購買習慣 瀏覽習慣和潛在消費能力都依靠資料去掌握。如今，大資料分析更是讓企業能夠洞悉...
零售行業資料分析運用
隨著移動網際網路十年紅利期的結束，線上流量成本越來越貴，許多企業紛紛將目光又從線上業務轉移至線下，傳統零售行業面臨著激烈的競爭，而以往的粗獷式運營，已不能滿足現階段市場環境及商業競爭的要求，精細化運營勢在必行。在此背景下，運用計算機及網際網路技術為企業進行數位化 智慧型化賦能是所有企業都必須考慮的問...