MySQL Partitioning/Sharding/Splitting - в каком направлении?

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

Параметры, о которых я сейчас знаю,

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

Наше приложение построено на J2EE и EJB 2.1 (мы надеемся, что однажды перейдем на EJB 3).

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

EDIT (2011-02-11):
Просто обновление: в настоящее время размер базы данных составляет 380 ГБ, размер данных нашей "большой" таблицы составляет 220 ГБ, а размер его индекса - 36 ГБ. Таким образом, пока вся таблица больше не вписывается в память, индекс делает.
Система все еще работает нормально (все еще на одном оборудовании), и мы все еще думаем о разделении данных.

EDIT (2014-06-04): Еще одно обновление: размер всей базы данных составляет 1,5 ТБ, размер нашей "большой" таблицы - 1,1 ТБ. Мы обновили наш сервер до 4-процессорной машины (Intel Xeon E7450) с 128 ГБ оперативной памяти. Система все еще работает нормально. То, что мы планируем сделать дальше, - это разместить нашу большую таблицу на отдельном сервере базы данных (мы уже внесли необходимые изменения в наше программное обеспечение), одновременно обновляя новое оборудование с 256 ГБ оперативной памяти.

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

EDIT (2016-01-18):

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

Текущая настройка аппаратного обеспечения:

HP ProLiant DL 580
4 x Intel (R) Xeon (R) CPU E7- 4830
256 ГБ оперативной памяти

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

Ответ 1

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

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

Ответ 2

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

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

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

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

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

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

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

Ответ 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

Надеясь, что это будет полезно для вашего дела.

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

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

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

Ответ 7

Что делает большая таблица.

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

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

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

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

Ответ 8

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

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

Ответ 9

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

НО

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