假如您有一個應用程式，隨著業務越來越有起色，系統所牽涉到的資料量也就越來越大，此時您要涉及到對系統進行伸縮（Scale）的問題了。

一種典型的擴充套件方法叫做“向上伸縮（Scale Up）”，它的意思是通過使用更好的硬體來提高系統的效能引數。

而另一種方法則叫做“向外伸縮（Scale Out）”，它是指通過增加額外的硬體（如伺服器）來達到相同的效果。

從“硬體成本”還是“系統極限”的角度來說，“向外伸縮”一般都會優於“向上伸縮”，因此大部分上規模的系統都會在一定程度上考慮“向外”的方式。由於許多系統的瓶頸都處在資料儲存上，因此一種叫做“資料分片（Database Sharding）”的資料架構方式應運而生，本文便會討論這種資料架構方式的一種比較典型的實現方式。

簡介

資料分片，是將整體資料分攤在多個儲存裝置（下文統稱為“資料分割槽”或“分割槽”）上，這樣每個儲存裝置的資料量相對就會小很多，以此滿足系統的效能需求。

    值得注意的是，系統分片的策略有很多，例如常見的有以下幾種：

　　（1）根據ID特徵：例如對記錄的ID取模，得到的結果是幾，那麼這條記錄就放在編號為幾的資料分割槽上。

　　（2）根據時間範圍：例如前100萬個使用者資料在第1個分割槽中，第二個100萬用戶資料放在第2個分割槽中。

    基於檢索表：根據ID先去一個表內找到它所在的分割槽，然後再去目標分割槽進行查詢。

　　在這些資料分片策略之中沒有哪個有絕對的優勢，選擇哪種策略完全是根據系統的業務或是資料特徵來確定的。值得強調的是：資料分片不是銀彈，它對系統的效能和伸縮性（Scalability）帶來一定好處的同時，也會對系統開發帶來許多複雜度。例如，有兩條記錄分別處在不同的伺服器上，那麼如果有一個業務是為它們建立一個“關聯”，那麼很可能表示“關聯”的記錄就必須在兩個分割槽內各放一條。另外，如果您重視資料的完整性，那麼跨資料分割槽的事務又立即變成了效能殺手。最後，如果有一些需要進行全域性查詢的業務，光有資料分片策略也很難對系統性能帶來什麼優勢。

資料分片
　　在ORACLE 中，【全域性關係】是一個【檢視】，而資料分片是通過關係資料的基本運算實現的，這一點在全域性檢視的定義中體現。

資料分片主要有兩種方式：
(1) 水平分片
　　按一定條件將  全域性關係  的所有元組劃分成若干個相交的子集，每個子集為關係的一個片段。
　　例如，一個公司下屬兩個子公司，每個子公司建有自己的資料庫，並存放本公司的職員資訊。在總公司的資料庫上建立一個全域性關係，可以看到全公司的全體職員資訊。建立全域性關係emp（檢視）的語句如下：
　　CREARTE VIEW emp AS
　　（SELECT* FROM [email protected]

(2) 垂直分片
　　把全域性關係的屬性集分成若干子集，形成幾個垂直片段。
　　例如，全域性關係emp中，有關職工的人事資訊在資料庫D1上，而職工的業務資訊在資料庫D2上。當然，有些屬性（如職工號這樣的關鍵字屬性）應出現在每個垂直片中。建立全域性關係EMP（檢視）的語句如下：
　　CREATTE VIEW emp AS
　　SELECRT emp1.eno， emp1.ename， emp2.sal，…
　　FROM [email protected], [email protected]
　　WHERE emp1.eno=emp2.eno;
　　全域性關係實際上是將分佈在不同資料庫中的一個職工記錄的各部分重新連線起來,然後投影出所要的屬性。
實際上,我們可以通過檢視的定義,實現全域性關係資料的多種分佈要求，全域性關係遮蔽了資料的物理分佈,提供了資料分佈的又一個透明性。

--------------------------------------------------------------------------------------------------

“Shard”字面意思為碎片，Sharding可以譯為【分片】。

MySQL5以後提供了Sharding的能力，其目的就是為突破單節點資料伺服器I/O能力限制，解決資料庫Scale Out水平擴充套件的問題。通過Sharding可以將資料按照物理位置貼合用戶分佈，得到更加快速的響應；操作龐然大物總是讓人頭疼，Sharding將資料分塊，更小的資料集操作彙總能夠得到更加的體驗；

分片使得資料分攤在各個資料節點，對其操作實現負載均衡！