MySQL Partitioning / Sharding / Splitting - какой путь?

Question

У нас есть база данных InnoDB, которая составляет около 70 ГБ, и мы ожидаем, что она увеличится до нескольких сотен ГБ в ближайшие 2–3 года. Около 60% данных принадлежат одной таблице. В настоящее время база данных работает достаточно хорошо, так как у нас есть сервер с 64 ГБ ОЗУ, поэтому почти вся база данных помещается в память, но нас беспокоит будущее, когда объем данных будет значительно больше. Прямо сейчас мы рассматриваем какой-то способ разделения таблиц (особенно тот, на который приходится большая часть данных), и сейчас я задаюсь вопросом, как лучше всего это сделать.

Варианты, которые мне известны в настоящее время:

• Использование MySQL Partitioning с версией 5.1
• Использование какой-либо сторонней библиотеки, которая инкапсулирует разделение данных (например, осколки гибернации)
• Реализация самостоятельно в нашем приложении

Наше приложение построено на J2EE и EJB 2.1 (надеюсь, мы когда-нибудь перейдем на EJB 3).

Что бы вы предложили?

РЕДАКТИРОВАТЬ (2011-02-11):
Просто обновление: в настоящее время размер базы данных составляет 380 ГБ, размер данных нашей «большой» таблицы составляет 220 ГБ, а размер ее индекса - 36 ГБ. Таким образом, хотя вся таблица больше не помещается в памяти, индекс делает это.
Система все еще работает нормально (все еще на том же оборудовании), и мы все еще думаем о разделении данных.

РЕДАКТИРОВАТЬ (2014-06-04): Еще одно обновление: размер всей базы данных составляет 1,5 ТБ, размер нашей «большой» таблицы - 1,1 ТБ. Мы обновили наш сервер до 4-процессорного компьютера (Intel Xeon E7450) с 128 ГБ ОЗУ. Система все еще работает нормально. Далее мы планируем разместить нашу большую таблицу на отдельном сервере базы данных (мы уже внесли необходимые изменения в наше программное обеспечение), одновременно обновляя оборудование до 256 ГБ ОЗУ.

Эта установка должна длиться два года. Тогда нам придется либо наконец-то начать реализацию решения шардинга, либо просто купить серверы с 1 ТБ ОЗУ, что должно поддерживать нас в течение некоторого времени.

РЕДАКТИРОВАТЬ (2016-01-18):

С тех пор мы поместили нашу большую таблицу в ее собственную базу данных на отдельном сервере. В настоящее время размер этой базы данных составляет около 1,9 ТБ, а размер другой базы данных (со всеми таблицами, кроме «большой») составляет 1,1 ТБ.

Текущая настройка оборудования:

• HP ProLiant DL 580
• 4 x Intel (R) Xeon (R) CPU E7- 4830
• 256 ГБ ОЗУ

При такой настройке производительность в порядке.

Answer 1

Вы обязательно начнете сталкиваться с проблемами в этой таблице 42 ГБ, как только она больше не помещается в памяти. Фактически, как только он больше не помещается в память, производительность очень быстро снижается. Один из способов проверить это - поместить эту таблицу на другую машину с меньшим объемом ОЗУ и посмотреть, насколько плохо она работает.

Прежде всего, разделение таблиц не имеет большого значения, если вы не переместите некоторые таблицы в отдельный физический том.

Это неверно. Разбиение на части (либо с помощью функции в MySQL 5.1, либо с помощью таблиц MERGE) может обеспечить существенное повышение производительности, даже если таблицы находятся на одном диске.

В качестве примера предположим, что вы выполняете запросы SELECT для большой таблицы, используя диапазон дат. Если таблица целая, запрос будет вынужден сканировать всю таблицу (и при таком размере даже использование индексов может быть медленным). Преимущество секционирования состоит в том, что ваши запросы будут выполняться только на тех секциях, где это абсолютно необходимо. Если каждый раздел имеет размер 1 ГБ, а для выполнения запроса требуется только доступ к 5 разделам, объединенная таблица 5 ГБ намного проще для MySQL, чем версия с монстром 42 ГБ.

Одна вещь, которую вы должны спросить себя, это то, как вы запрашиваете данные. Если существует вероятность того, что вашим запросам потребуется только доступ к определенным фрагментам данных (то есть диапазону дат или диапазону идентификаторов), какое-то разделение окажется полезным.

Я слышал, что в разделах MySQL 5.1 все еще есть ошибки, особенно связанные с тем, что MySQL выбирает правильный ключ. Таблицы MERGE могут предоставлять ту же функциональность, хотя они требуют немного больше накладных расходов.

Надеюсь, это поможет ... удачи!

Answer 2

Если вы думаете, что будете ограничены вводом-выводом / памятью, я не думаю, что разбиение будет полезным. Как обычно, первый бенчмаркинг поможет вам определить наилучшее направление. Если у вас нет запасных серверов с 64 ГБ памяти, вы всегда можете попросить у своего поставщика «демонстрационный блок».

Я бы склонялся к шардингу, если вы не ожидаете составления отчетов по 1 запросу. Я предполагаю, что вы осколите всю базу данных, а не только большую таблицу: лучше хранить целые сущности вместе. Хорошо, если ваша модель хорошо расколется, в любом случае.

Answer 3

Это отличный пример того, что может сделать раздел 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 4

Я бы выбрал разделы MariaDB InnoDB + (по ключу или по дате, в зависимости от ваших запросов).

Я сделал это, и теперь у меня больше нет проблем с базой данных.

MySQL можно заменить на MariaDB за считанные секунды ... все файлы базы данных остаются прежними.

Answer 5

Некоторое время назад на мероприятии Microsoft ArcReady я увидел презентацию по шаблонам масштабирования, которая может оказаться полезной для вас. Вы можете просмотреть слайды для этого онлайн.

Answer 6

Возможно, вы захотите разделить эту большую таблицу в конце концов. Возможно, вы захотите поместить его на отдельный жесткий диск, прежде чем подумать о втором сервере. Делать это с MySQL - самый удобный вариант. Если он способен, то иди на это.

НО

Все зависит от того, как ваша база данных используется, на самом деле. Статистика.

Answer 7

Как обычно, первый тест поможет вам определить наилучшее направление.

Это то, что большинство людей говорят мне, поэтому я думаю, что мне, наконец, придется принять эту таблетку ...

Answer 8

Что делает большой стол.

Если вы собираетесь разделить его, у вас есть несколько вариантов:
- Разделить его с помощью системы баз данных (не знаю много об этом)
- Разделить его на ряд.
- разделить его на столбцы.

Разделение на строки возможно только в том случае, если ваши данные можно легко разделить на куски. например Что-то вроде Basecamp имеет несколько учетных записей, которые полностью разделены. Вы можете хранить 50% учетных записей в одной таблице и 50% в другой таблице на другом компьютере.

Разделение по столбцам подходит для ситуаций, когда размер строки содержит большие текстовые поля или BLOBS. Если у вас есть таблица с (например) пользовательским изображением и огромным блоком текста, вы можете преобразовать изображение в совершенно другую таблицу. (на другой машине)

Вы нарушаете нормализацию здесь, но я не думаю, что это вызовет слишком много проблем.

Answer 9

Прежде всего, разделение таблиц не имеет большого значения, если вы не переместите некоторые таблицы в отдельный физический том.

Во-вторых, это не обязательно таблица с самым большим физическим размером, которую вы хотите переместить. У вас может быть намного меньшая таблица, которая получает больше активности, в то время как ваша большая таблица остается довольно постоянной или добавляет данные.

Что бы вы ни делали, не выполняйте это сами. Пусть система баз данных справится с этим.