什麼是分片，爲什麼它很重要？

Question

我想我明白分割會將你的分片數據（碎片）放回一個容易處理的聚合，在上下文中是合理的。它是否正確？

更新：我想我在這裏掙扎。在我看來，應用層應該沒有業務決定數據應該存儲在哪裏。充其量，它應該是某種碎片客戶端。兩個回答都回答了什麼，但不是爲什麼它是重要的方面。除了顯而易見的績效收益之外，它有什麼影響？這些收益是否足以抵消MVC違規？在非常大規模的應用中分片是非常重要的，還是適用於小規模應用？

Answer 1

分片是數據庫的「水平分區」的另一個名稱。您可能想要搜索該術語以使其更清晰。

從Wikipedia：

水平分區是一個設計原則，即一個數據庫表的行是通過列分開保存，而不是分裂（作爲歸一化）。每個分區構成分片的一部分，分片又可位於單獨的數據庫服務器或物理位置上。優點是減少了每個表中的行數（這減少了索引大小，從而提高了搜索性能）。如果分片基於數據的某些真實世界方面（例如，歐洲客戶與美國客戶），則可以容易且自動地推斷適當的分片成員資格，並且僅查詢相關的分片。

約分片部分的更多信息：

首先，每個數據庫服務器是相同的，具有相同的表結構。其次，數據記錄在邏輯上被拆分成分片數據庫。與分區數據庫不同，每個完整的數據記錄只存在於一個分區中（除非鏡像備份/冗餘），並且所有CRUD操作都在該數據庫中執行。您可能不喜歡使用的術語，但這確實代表了將邏輯數據庫組織成更小部分的不同方式。

更新：你不會打破MVC。確定正確的分片在哪裏存儲數據的工作將透明地由您的數據訪問層完成。在那裏你必須根據你用來分割數據庫的標準來確定正確的分片。 （因爲您必須根據應用程序的某些具體方面手動將數據庫分割成不同的分片。）然後，在從/向數據庫加載和存儲數據以使用正確的分片時，必須小心。

也許this example與Java代碼使它更清晰（這是關於Hibernate Shards項目），這將如何在現實世界的情況下工作。

，解決「why sharding」：這是主要只針對超大規模應用，大量數據。首先，它有助於最小化數據庫查詢的響應時間。其次，您可以使用更便宜的「低端」機器來託管您的數據，而不是一個大型服務器，這可能不足以滿足您的需求。

Answer 2

如果你有一個數據庫管理系統的查詢，這些數據庫的局部性是非常有限的（比如說，用戶只用'where username = $ my_username'來激發選擇），那麼把所有以AN開頭的用戶名放在一個服務器上是有意義的所有來自MZ。通過這個，你可以對某些查詢進行線性縮放。

長話短說：分片基本上是將表分配到不同服務器上的過程，以平衡兩者之間的負載。

當然，它在現實中要複雜得多。 :)

Answer 3

是非常 大規模應用主要分片重要的或者它 適用於規模較小的呢？

當且僅當您的需求超出單個數據庫服務器可以提供的服務範圍時，分片才成爲問題。如果您有可分片數據，並且您具有令人難以置信的高可擴展性和性能要求，那麼這是一個膨脹的工具。我想，在我整整12年裏，我一直是一名軟件專業人員，我遇到過一種可能從分片中受益的情況。這是一種適用性非常有限的先進技術。

而且，未來很可能會成爲一些有趣和令人興奮的像一個大質量天體「雲」是將刪除所有潛在的性能限制，對不對？ :)

Answer 4

在我看來，應用層 應該沒有企業判斷 在數據應該存儲

這是一個很好的規則，但最喜歡的事情並不總是正確的。

當你做你的架構開始與責任和合作。一旦你確定了你的功能架構，你必須平衡非功能性的力量。

如果這些非功能性的力量之一是巨大的可擴展性，你必須適應你的架構，以迎合這股力量，即使這意味着您的數據存儲抽象現在泄漏到您的應用程序層。

Answer 5

分片最初是由谷歌工程師創造的，你可以看到寫在谷歌App Engine應用程序時，它使用相當嚴重。由於您的查詢可以使用的資源數量有嚴格的限制，並且由於查詢本身具有嚴格的限制，因此分片不僅受到鼓勵，而且幾乎被該體系結構強制執行。

另一個地方拆分可以使用是減少對數據實體的爭用。當構建可擴展的系統來關注經常編寫的那些數據時，這一點尤爲重要，因爲它們始終是瓶頸。一個好的解決方案是分離出特定的實體並寫入多重副本，然後讀取總數。這種「分片計數器WRT GAE的一個例子：這些網絡研討會http://code.google.com/appengine/articles/sharding_counters.html