引用**：
分片（sharding）是一種與水平切分（horizontal partitioning）相關的資料庫架構模式——將乙個表裡面的行，分成多個不同的表的做法（稱為分割槽）。每個區都具有相同的模式和列，但每個表有完全不同的行。同樣，每個分割槽中儲存的資料都是唯一的，並且與其他分割槽中儲存的資料無關。
從水平切分（horizontal partitioning）與垂直切分（vertical partitioning）的關係，可能會有所幫助。在垂直切分表中，所有的列被分離出來，並放入新的不同的表中。每個垂直切分內的資料，獨立於所有其他分割槽中的資料，並且每個分割槽都包含不同的行和列。下圖說明了如何在水平和垂直方向上對錶進行分割槽：
range 分割槽是一種水平分割槽。
分片（sharding）將乙個資料分成兩個或多個較小的塊，稱為邏輯分片（logical shards）。然後，邏輯分片（logical shards）分布在單獨的資料庫節點上，稱為物理分片（physical shards）。物理分片（physical shards）可以容納多個邏輯分片（logical shards）？？。
資料庫分片（database shards）是無共享架構的乙個例子。這意味著分片是自治的：分片間不共享任何相同的資料或伺服器資源。
通常，分片（sharding）在應用程式級別進行實現。這意味著應用程式包含「要向哪個分片傳送讀和寫」的**。但是，某些資料庫管理系統內建了分片功能，允許您直接在資料庫級別實現分片。
資料庫分片的主要吸引力在於，它可以幫助促進水平擴充套件（horizontal scaling），也稱為向外擴充套件（scaling out）。水平擴充套件是將更多的機器新增到現有堆疊中，以分散負載，允許更多的流量和更快的處理。這通常與垂直擴充套件（vertical scaling）形成對比，垂直擴充套件也稱為向上擴充套件（scaling up），是指公升級現有伺服器的硬體，通常是新增更多記憶體或cpu。
要考慮的最後乙個缺點是，並不是每個資料庫引擎本身都支援分片。例如，儘管可以手動分片postgresql資料庫，但postgresql本身並不包括自動分片功能。有許多postgres分支包括自動分片功能，但這些分支通常落後於最新的postgresql版本，並且缺乏某些其他的功能特性。一些專業的資料庫技術——如mysql cluster或某些資料庫即服務產品（如mongodb atlas）確實包含自動分片功能，但這些資料庫管理系統的普通版本卻並不包含。因此，分片通常需要「自己動手」的方法。這意味著通常很難找到有關分片或故障排除技巧的文件。
基於鍵值的分片
基於範圍的分片
基於範圍的分片（range based sharding），基於給定值的範圍進行資料分片。為了說明，假設您有乙個資料庫，用於儲存零售商目錄中所有產品的資訊。您可以建立一些不同的分片，並根據每個產品的**範圍分配每個產品的資訊，如下所示：
本案例中基於第二列 price 進行範圍劃分得到分片
基於目錄的分片
要實現基於目錄的分片，必須建立並維護乙個使用分片鍵的查詢表，以跟蹤哪個分片儲存哪些資料。簡而言之，查詢表是乙個表，其中包含一組靜態資訊，這些資訊描述可以在何處找到特定資料。下圖顯示了基於目錄分片的簡化示例：
此處，「交付區」列定義為分片鍵。分片鍵中的資料與每行應寫入的分片一起被寫入查詢表。這類似於基於範圍的分片，但不是確定分片金鑰的資料屬於哪個範圍，而是將每個金鑰繫結到其自己的特定分片。如果分片金鑰的基數較低，並且分片儲存一定範圍的金鑰沒有意義，那麼基於目錄分片是基於範圍分片的不錯選擇。注意，它也與基於金鑰的分片不同，因為它不通過雜湊函式處理分片金鑰。它只是對照查詢表檢查金鑰，以檢視需要將資料寫入何處。
基於目錄分片的主要優勢在於它的靈活性。基於範圍分片將限制為指定值的範圍，而基於鍵的分片將限制為使用固定的雜湊函式，（此雜湊函式以後很難更改）。而基於目錄分片允許使用任何系統演算法為分片分配資料條目，並且使用此方法動態新增分片相對容易。
儘管基於目錄分片是此處討論最靈活的分片方法，但是在每次查詢或寫入之前，連線到查詢表的需求可能會對應用程式的效能產生不利影響。此外，查詢表可能會成為單點故障：如果它損壞或以其他方式失敗，則會影響寫入新資料或訪問其現有資料。
是否應該實施分片資料庫是乙個辯證的問題。有些人認為分片是達到一定規模的資料庫的必然結果，而另一些人則認為這是令人頭痛的事情，除非絕對必要，否則應該避免，因為分片會增加操作的複雜性。
由於增加了複雜性，因此通常僅在處理大量資料時才執行分片。以下是一些常見的場景，在這些場景中分片資料庫可能會有所幫助：
· 應用程式資料量增長到超過單個資料庫節點的儲存容量。
· 對資料庫的寫或讀量超過單個節點或其唯讀副本可以處理的量，導致響應時間變慢或超時。
· 應用程式所需的網路頻寬超過了單個資料庫節點和任何唯讀副本可用的頻寬，導致響應時間變慢或超時。
在分片之前，應該用盡所有其他方式來優化資料庫。您可能要考慮的一些優化包括：
·建立乙個遠端資料庫。如果您正在使用其所有元件都位於同一伺服器上的整體應用程式，則可以通過將資料庫移至其自己的計算機上來提高資料庫的效能。由於資料庫表保持完好無損，所以這不會像分片那樣增加複雜性。但是，它仍然允許您與其他基礎架構分開縱向擴充套件資料庫。
·實現快取。如果您的應用程式的讀取效能是造成您麻煩的原因，那麼快取是可以幫助改進它的一種策略。快取涉及將已經請求的資料臨時儲存在記憶體中，從而使您以後可以更快地訪問它。
·建立乙個或多個唯讀副本。可以幫助提高讀取效能的另一種策略是，將資料從乙個資料庫伺服器（主伺服器）複製到乙個或多個輔助伺服器上。此後，每個新的寫操作都會先複製到主伺服器上，然後再複製到輔助伺服器上，而讀操作將僅對輔助伺服器進行。像這樣分布讀寫，可以防止任何一台計算機承擔過多的負載，從而有助於防止速度下降和崩潰。請注意，建立唯讀副本會涉及更多的計算資源，因此會花費更多的金錢，這對於某些人而言可能是乙個重大限制。
·公升級伺服器硬體。在大多數情況下，將資料庫伺服器公升級更多資源比分片需要更少的工作。與建立唯讀副本一樣，具有更多資源的伺服器可能會花費更多資金。因此，只有在真正成為最佳選擇的情況下，才應調整大小。
請記住，如果您的應用程式或**增長到一定程度，這些策略都不足以滿足效能需求。這時候，分片可能確實是您的最佳選擇。
對於希望水平擴充套件資料庫的使用者來說，分片是乙個很好的解決方案。但是，這也增加了很多複雜性，並為您的應用程式建立了更多潛在的故障點。某些人可能需要分片，但是建立和維護分片架構所需的時間和資源可能會超過其他人的利益。
通過閱讀本文，您應該對分片的利弊有更清晰的了解。接下來，您可以利用這種見解來做出更明智的決定，以了解分布式資料庫是否適合您的應用程式。
原文：參考：
資料庫分片
隨著網際網路的發展，資料的量級也是指數的增長，從 gb 到tb到 pb。對資料的各種操作也是愈加的困難，傳統的關係性資料庫已經無法滿足快速查詢與插入資料的需求。這個時候 nosql 的出現暫時解決了這一危機。它通過降低資料的安全性，減少對事務的支援，減少對複雜查詢的支援，來獲取效能上的提公升。但是，...
資料庫分片技術
假如您有乙個應用程式，隨著業務越來越有起色，系統所牽涉到的資料量也就越來越大，此時您要涉及到對系統進行伸縮 scale 的問題了。一種典型的擴充套件方法叫做 向上伸縮 scale up 它的意思是通過使用更好的硬體來提高系統的效能引數。而另一種方法則叫做 向外伸縮 scale out 它是指通過增加...
資料庫分片技術
垂直切?存放在同一目錄 資料中的的資料分散存放到多個資料庫 1.一種是按照不同的表 或者schema 來切分到不同的資料庫 主機 之上，這種切可以稱之為資料的垂直 縱向 切分 另外一種則是根據表中的資料的邏輯關係，將同乙個表中的資料按照某種條件拆分到多台資料庫 主機 上面，這種切分稱之為資料的水平 ...