Разделение MySQL/шардинг/разделение – какой путь выбрать?
https://stackoverflow.com/questions/45879
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
У нас есть база данных InnoDB размером около 70 ГБ, и мы ожидаем, что в ближайшие 2–3 года она вырастет до нескольких сотен ГБ.Около 60% данных принадлежат одной таблице.В настоящее время база данных работает достаточно хорошо, поскольку у нас есть сервер с 64 ГБ оперативной памяти, поэтому почти вся база данных умещается в памяти, но мы беспокоимся о будущем, когда объем данных будет значительно больше.Сейчас мы рассматриваем какой-то способ разделения таблиц (особенно ту, на которую приходится большая часть данных), и мне интересно, как лучше всего это сделать.
Варианты, о которых я сейчас знаю,
- Использование секционирования MySQL, которое поставляется с версией 5.1.
- Использование какой-либо сторонней библиотеки, которая инкапсулирует разделение данных (например, сегменты спящего режима)
- Реализуем это сами внутри нашего приложения
Наше приложение построено на J2EE и EJB 2.1 (надеюсь, когда-нибудь мы перейдем на EJB 3).
Что ты предлагаешь?
РЕДАКТИРОВАТЬ (11 февраля 2011 г.):
Просто обновление:На данный момент размер базы данных составляет 380 ГБ, размер данных нашей «большой» таблицы — 220 ГБ, а размер ее индекса — 36 ГБ.Таким образом, хотя вся таблица больше не помещается в памяти, индекс помещается.
Система по-прежнему работает нормально (на том же оборудовании), и мы все еще думаем о разделении данных.
РЕДАКТИРОВАТЬ (04.06.2014):Еще одно обновление:Размер всей базы данных — 1,5 ТБ, размер нашей «большой» таблицы — 1,1 ТБ.Мы обновили наш сервер до 4-процессорного компьютера (Intel Xeon E7450) с 128 ГБ оперативной памяти.Система по-прежнему работает нормально.Далее мы планируем разместить нашу большую таблицу на отдельном сервере базы данных (мы уже внесли необходимые изменения в наше программное обеспечение) и одновременно обновиться до нового оборудования с 256 ГБ оперативной памяти.
Эта установка рассчитана на два года.Тогда нам придется либо наконец начать внедрять решение по шардингу, либо просто покупать серверы с 1 ТБ оперативной памяти, что должно продержаться какое-то время.
РЕДАКТИРОВАТЬ (18 января 2016 г.):
С тех пор мы поместили нашу большую таблицу в собственную базу данных на отдельном сервере.На данный момент размер этой базы данных составляет около 1,9 ТБ, размер другой базы данных (со всеми таблицами, кроме «большой») — 1,1 ТБ.
Текущая настройка оборудования:
- HP ProLiant DL 580
- 4 процессора Intel(R) Xeon(R) E7-4830
- 256 ГБ ОЗУ
Производительность в этой настройке хорошая.
Решение
Если вы думаете, что будете привязаны к вводу-выводу/памяти, я не думаю, что секционирование будет полезным.Как обычно, сначала сравнительный анализ поможет вам определить лучшее направление.Если у вас нет запасных серверов с 64 ГБ памяти, вы всегда можете попросить у своего поставщика «демонстрационный модуль».
Я бы склонялся к сегментированию, если вы не ожидаете агрегированного отчета по одному запросу.Я предполагаю, что вы разделите всю базу данных, а не только большую таблицу:лучше всего держать целые сущности вместе.Ну, во всяком случае, если ваша модель хорошо разделяется.
Другие советы
Вы обязательно начнете сталкиваться с проблемами с этой таблицей размером 42 ГБ, как только она перестанет помещаться в памяти.Фактически, как только он перестанет помещаться в памяти, производительность упадет чрезвычайно быстро.Один из способов тестирования — разместить эту таблицу на другой машине с меньшим объемом оперативной памяти и посмотреть, насколько плохо она работает.
Прежде всего, разделение таблиц не имеет большого значения, если только вы не переместите некоторые таблицы в отдельный физический том.
Это неверно.Разделение (либо с помощью функции MySQL 5.1, либо с использованием таблиц MERGE) может обеспечить значительный выигрыш в производительности, даже если таблицы находятся на одном диске.
В качестве примера предположим, что вы выполняете запросы SELECT к своей большой таблице, используя диапазон дат.Если таблица целая, запрос будет вынужден сканировать всю таблицу (и при таком размере даже использование индексов может быть медленным).Преимущество секционирования заключается в том, что ваши запросы будут выполняться только в тех разделах, где это абсолютно необходимо.Если размер каждого раздела составляет 1 ГБ, а вашему запросу для выполнения требуется доступ только к 5 разделам, MySQL намного проще справиться с объединенной таблицей размером 5 ГБ, чем с чудовищной версией на 42 ГБ.
Вам нужно спросить себя, как вы запрашиваете данные.Если есть вероятность, что вашим запросам потребуется доступ только к определенным фрагментам данных (т.диапазон дат или диапазон идентификаторов), какое-либо секционирование окажется полезным.
Я слышал, что с секционированием MySQL 5.1 все еще есть некоторые ошибки, особенно связанные с выбором MySQL правильного ключа.Таблицы MERGE могут обеспечивать ту же функциональность, хотя требуют немного больше накладных расходов.
Надеюсь, это поможет... удачи!
Это отличный пример того, что может сделать секционирование MySql в реальном примере огромных потоков данных:
Надеюсь, это будет полезно для вашего случая.
Некоторое время назад на мероприятии Microsoft ArcReady я увидел презентацию о шаблонах масштабирования, которые могут быть вам полезны.Ты можешь просмотреть слайды для этого онлайн.
Я бы выбрал MariaDB InnoDB + Partitions (по ключу или по дате, в зависимости от ваших запросов).
Я сделал это, и теперь у меня больше нет проблем с базой данных.
MySQL можно заменить на MariaDB за считанные секунды... все файлы базы данных останутся прежними.
Прежде всего, разделение таблиц не имеет большого значения, если только вы не переместите некоторые таблицы в отдельный физический том.
Во-вторых, вы не обязательно хотите переместить таблицу с наибольшим физическим размером.У вас может быть таблица гораздо меньшего размера, которая вызывает больше активности, в то время как ваша большая таблица остается достаточно постоянной или только добавляет данные.
Что бы вы ни делали, не реализуйте это сами.Позвольте системе базы данных справиться с этим.
Что делает большой стол.
Если вы собираетесь разделить его, у вас есть несколько вариантов:
- Разделите его, используя систему базы данных (мало что об этом знаю)
- Разделите его по строкам.
- разбить по столбцам.
Разделение его по строкам будет возможно только в том случае, если ваши данные можно легко разделить на фрагменты.напримерЧто-то вроде Базовый лагерь имеет несколько учетных записей, которые полностью разделены.Вы можете хранить 50% учетных записей в одной таблице и 50% в другой таблице на другом компьютере.
Разделение по столбцам удобно в ситуациях, когда размер строки содержит большие текстовые поля или BLOBS.Если у вас есть таблица с (например) изображением пользователя и огромным блоком текста, вы можете перенести изображение в совершенно другую таблицу.(на другой машине)
Здесь вы нарушаете нормализацию, но я не думаю, что это вызовет слишком много проблем.
Как обычно, сначала сравнительный анализ поможет вам определить лучшее направление.
Так мне говорит большинство людей, поэтому я думаю, что мне, наконец, придется принять эту таблетку...
Вероятно, в конечном итоге вам захочется разделить эту большую таблицу.Вы, вероятно, захотите разместить его на отдельном жестком диске, прежде чем думать о втором сервере.Сделать это с помощью MySQL — наиболее удобный вариант.Если он способен, то действуйте.
НО
На самом деле все зависит от того, как используется ваша база данных.Статистика.
