https://blog.csdn.net/zhuyijian135757/article/details/40870973

"Sharding" 姑且稱之為"分片"。

Sharding 不是一門新技術(shù)，而是一個相對簡樸的軟件理念。

MySQL 5 之后才有了數(shù)據(jù)表分區(qū)(Partition)功能，那么在此之前，很多 MySQL 的潛在用戶都對 MySQL 的擴(kuò)展性有所顧慮，而是否具備分區(qū)功能就成了衡量一個數(shù)據(jù)庫可擴(kuò)展性與否的一個關(guān)鍵指標(biāo)(當(dāng)然不是唯一指標(biāo))。

如在單一數(shù)據(jù)庫上處理應(yīng)用數(shù)據(jù)捉襟見肘而需要進(jìn)行分區(qū)化之類的處理，是如何辦到的呢? 答案是：Sharding。

?Sharding 不是一個某個特定數(shù)據(jù)庫軟件附屬的功能，而是在具體技術(shù)細(xì)節(jié)之上的抽象處理，是水平擴(kuò)展(Scale Out，亦或橫向擴(kuò)展、向外擴(kuò)展)的解決方案，其主要目的是為突破單節(jié)點(diǎn)數(shù)據(jù)庫服務(wù)器的 I/O 能力限制，解決數(shù)據(jù)庫擴(kuò)展性問題。

通過一系列的切分規(guī)則將數(shù)據(jù)水平分布到不同的DB或table中，在通過相應(yīng)的DB路由或者 table路由規(guī)則找到需要查詢的具體的DB或者table，以進(jìn)行Query操作。這里所說的“sharding”通常是指“水平切分”，?這也是本文討論的重點(diǎn)。具體將有什么樣的切分方式呢和路由方式呢？行文至此，讀者難免有所疑問，接下來舉個簡單的例子：我們針對一個Blog應(yīng)用中的日志來說明，比如日志文章（article）表有如下字段：

article_id(int),title(varchar(128)),content(varchar(1024)),user_id(int)

blog的應(yīng)用中，用戶分為兩種：瀏覽者和blog的主人。瀏覽者瀏覽某個blog，實際上是在一個特定的用戶的blog下進(jìn)行瀏覽的，而blog的主人管理自己的blog，也同樣是在特定的用戶blog下進(jìn)行操作的（在自己的空間下）。所謂的特定的用戶，用數(shù)據(jù)庫的字段表示就是“user_id”。就是這個“user_id”，它就是我們需要的分庫的依據(jù)和規(guī)則的基礎(chǔ)。

們可以這樣做，將user_id為 1～10000的所有的文章信息放入DB1中的article表中，將user_id為10001～20000的所有文章信息放入DB2中的 article表中，以此類推，一直到DBn【水平切分】

這樣一來，文章數(shù)據(jù)就很自然的被分到了各個數(shù)據(jù)庫中，達(dá)到了數(shù)據(jù)切分的目的。

接下來要解決的問題就是怎樣找到具體的數(shù)據(jù)庫呢？其實問題也是簡單明顯的，既然分庫的時候我們用到了區(qū)分字段user_id，那么很自然，數(shù)據(jù)庫路由的過程當(dāng)然還是少不了 user_id的。

考慮一下我們剛才呈現(xiàn)的blog應(yīng)用，不管是訪問別人的blog還是管理自己的blog，總之我都要知道這個blog的用戶是誰吧，也就是我們知道了這個blog的user_id，就利用這個user_id，利用分庫時候的規(guī)則，反過來定位具體的數(shù)據(jù)庫，

比如user_id是234，利用該才的規(guī)則，就應(yīng)該定位到DB1，
假如user_id是12343，利用該才的規(guī)則，就應(yīng)該定位到DB2。

利用分庫的規(guī)則，反向的路由到具體的DB，這個過程我們稱之為“DB路由”。

當(dāng)然考慮到數(shù)據(jù)切分的DB設(shè)計必然是非常規(guī)，不正統(tǒng)的DB設(shè)計[nosql數(shù)據(jù)庫]。那么什么樣的DB設(shè)計是正統(tǒng)的DB設(shè)計呢？

當(dāng)然冗余字段的出現(xiàn)并不只是在分庫的場景下才出現(xiàn)的，在很多大型應(yīng)用中，冗余也是必須的，