Какое оптимальное количество партиций для большой таблицы в MySQL?

Question

[meta4]

У меня есть таблица, в которой потенциально будет достатчно много данных (~10^8 строк) — что-то типа лога. У таблицы есть «группирующие» поле, на основе которого и делаются выборки. Хочу использовать стандартное MySQL партиционирование с использованием hash(группирующего поля). Соответственно возникает вопрос: какое количество партиций стоит выбрать? MySQL позволяет до 1024 партиций. Правда ли что чем больше партиций тем, по идее, выше производительность но больше занимает места? Или как-то иначе?


И вообще, до меня доходили слухи о проблемах в MySQL-ном встроенном партиционировании (внезапном «схлоповании» партиций при неизвестных обстоятельствах), есть у кого-нибудь негативный опыт использование встроенного механизма партиционирования MySQL?

Answer 1

[ztxn]

>>Правда ли что чем больше партиций тем, по идее, выше производительность но больше занимает места?

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

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

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

>> У таблицы есть «группирующие» поле
Не совсем понятно что вы имеете тут в виду. Если вы группируетесь по полю, которое является ключом секционирования, вероятнее всего вам придется сканировать весь набор записей, все секции, и первый, описанный мною случай, выигрыша в производительности тогда, определенно, не про вас. Я очень сомневаюсь что MySql способен, как оракл, параллелить выполнение стейтмента, потому и второй описанный случай выигрыша, тоже врядли о вас.

Comments

[ztxn]

Да, еще вспомнил случай, когда может быть получен выигрыш в производительности. За счет уменьшения глубины B-дерева локальных индексов, может быть получен ощутимый прирост на мелких, но частых запросах.

[Иван Иванов]

ztxn: Не подскажите, как раскидать секции по дискам? Через симлинки, как тут написано www.sql.ru/forum/1239183/particionirovanie-partiti... ?

Answer 2

[ivnik]

Из проблем с которыми сталкивались — проблема с уникальными индексами: «every unique key on the table must use every column in the table's partitioning expression».
Могу ошибаться за давностью, но вроде бы mysql на каждую партицию открывает файл, т.е. нужно увеличивать лимит на количество открытых файлов (ulimit).

Comments

[meta4]

>every unique key on the table must use every column in the table's partitioning expression
Ну, уникальных индексов у меня (кроме PK) нет, так что это не проблема
>т.е. нужно увеличивать лимит на количество открытых файлов
Точно, спасибо что напомнили про ulimit