MySQL分區/分片/分割 - 哪條路要走？

Question

我們有一個大約70GB的InnoDB數據庫，我們預計它在未來的2到3年內會增長到幾百GB。大約60％的數據屬於單個表格。目前數據庫運行良好，因爲我們有一個64 GB RAM的服務器，所以幾乎整個數據庫都可以存儲到內存中，但是當數據量會大得多時，我們擔心未來。現在我們正在考慮某種方式來分割表格（特別是佔數據最大部分的表格），現在我想知道，最好的方法是什麼。

選項我目前知道的是

• 使用自帶的版本5.1
• 使用某種類型的第三方庫的封裝了數據的分區（如Hibernate碎片）
MySQL分區
• 自己實現它我們的應用程序內

我們的應用是建立在J2EE和EJB 2.1（希望我們切換到EJB 3的某一天）。

你會建議什麼？

編輯（2011-02-11）：
只是一個更新：目前數據庫的大小是380 GB，我們的「大」表的數據大小是220 GB，其索引的大小是36 GB 。因此，儘管整個表格不再適合記憶，但索引確實如此。
系統仍然運行良好（仍然在同一個硬件上），我們仍在考慮對數據進行分區。

編輯（2014-06-04）： 另一個更新：整個數據庫的大小是1.5TB，我們的「大」表的大小是1.1TB。我們將服務器升級到具有128 GB RAM的4處理器機器（Intel Xeon E7450）。 該系統仍然運行良好。 我們接下來要做的是將我們的大表放在一個單獨的數據庫服務器上（我們已經對我們的軟件進行了必要的更改），同時升級到具有256 GB RAM的新硬件。

此設置應該持續兩年。然後，我們要麼終於開始實施分片解決方案，要麼只購買帶有1TB內存的服務器，這應該讓我們保持一段時間。

EDIT（2016年1月18日）：

我們自把我們的大表在它自己的數據庫的單獨服務器上。目前該數據庫的大小約爲1.9TB，其他數據庫的大小（除「大」之外的所有表）爲1.1TB。

當前硬件設置：

• 的HP ProLiant DL 580
• 4×英特爾（R）至強（R）CPU E7-4830
• 256 GB RAM

性能優良用這個設置。

Answer 1

如果你認爲你將要IO /內存綁定，我不認爲分區會有幫助。像往常一樣，首先進行基準測試將幫助您找出最佳方向。如果您沒有配備64GB內存的備用服務器，您可以隨時向供應商索取「演示單元」。

如果您不期望1個查詢彙總報告，我會傾向於分片。我假設你會分解整個數據庫，而不僅僅是你的大桌子：最好把整個實體放在一起。好吧，無論如何，如果你的模型分裂的很好。

Answer 2

首先，除非您還將某些表格移動到單獨的物理捲上，否則分割表格並不重要。其次，它不一定是你想移動的物理尺寸最大的表格。你可能有一個小得多的表獲得更多的活動，而你的大表仍然是相當穩定的，或者只是附加數據。

不管你做什麼，都不要自己去實現。讓數據庫系統處理它。

Answer 3

回到Microsoft ArcReady事件，我看到了一個關於縮放模式的演示文稿，可能對您有用。你可以在線上view the slides。

Answer 4

大表做什麼。

如果你要拆呢，你有幾種選擇：
- 由行分割它 - 使用的數據庫系統（不知道很多有關）
拆分它。
- 按列分割。

只有在您的數據可以很容易地分成塊的情況下，才能將它按行拆分。例如像Basecamp這樣的東西有多個完全分開的賬戶。您可以在一個表中保留50％的帳戶，在另一臺機器上保留50％的帳戶。

按列拆分適用於行大小包含大型文本字段或BLOBS的情況。如果你有一個帶有（例如）用戶圖像和大塊文本的表格，你可以將圖像放入一個完全不同的表格。 （在不同的機器上）

你在這裏打破標準化，但我不認爲這會造成太多問題。

Answer 5

像往常一樣，基準首先會幫助您找出最佳方向。

這就是大多數人告訴我，所以我認爲我將最終不得不採取丸...

Answer 6

你可能會想最終拆分大表。在考慮第二臺服務器之前，您可能需要將其放在單獨的硬盤上。用MySQL來做是最方便的選擇。如果它有能力，那就去做吧。

但是

一切都取決於您的數據庫是如何使用，真的。統計。

Answer 7

一旦它不再適合內存，您肯定會開始在42 GB表中遇到問題。事實上，一旦它不再適應內存，性能將會非常快地降低。測試的一種方法是將該表放在另一臺RAM較少的計算機上，並查看其執行效果差。

首先，除非您還將某些表格移動到單獨的物理捲上，否則分開表格並不重要。

這是不正確的。分區（通過MySQL 5.1中的功能，或者使用MERGE表格的功能）可以提供顯着的性能優勢，即使這些表位於同一個驅動器上。

舉一個例子，假設您使用日期範圍在大表上運行SELECT查詢。如果表是完整的，則查詢將被強制掃描整個表（並且在該大小下，即使使用索引也可能很慢）。分區的優勢在於您的查詢只能在絕對有必要的分區上運行。如果每個分區的大小爲1 GB，並且查詢只需要訪問5個分區以實現自身功能，那麼組合的5 GB表比MySQL更容易處理，而不是42 GB的怪獸版本。

你需要問自己的一件事是你如何查詢數據。如果您的查詢有可能只需訪問某些數據塊（即日期範圍或ID範圍），則某種分區將證明是有益的。

我聽說MySQL 5.1分區還存在一些問題，特別是與MySQL選擇正確密鑰有關的問題。 MERGE表可以提供相同的功能，但它們需要稍微更多的開銷。

希望能幫助你...祝你好運！

Answer 8

這是一個什麼能MySQL分區中的海量數據的真實生活中的例子做一個很好的例子流：

http://web.archive.org/web/20101125025320/http://www.tritux.com/blog/2010/11/19/partitioning-mysql-database-with-high-load-solutions/11/1

希望它成爲你的情況有幫助。

Answer 9

我會去MariaDB InnoDB +分區（按鍵或按日期，具體取決於您的查詢）。

我做了這個，現在我沒有任何數據庫問題了。

MySQL可以在幾秒鐘內被MariaDB替換...所有的數據庫文件保持不變。