Почему НЕ раздел?

Когда не нужно разделить базу данных? (думая о разделении MySQL )

В моем случае

Я начну с пары миллионов строк, оттуда они должны расти.
Первичный ключ в символьном поле, который служит наиболее частым ограничением запросов (и частые поиски - по крайней мере, несколько в секунду).
Первичный ключ будет хеширован, чтобы служить ключом раздела
Обновления будут внесены в каждую строку, которая используется в частых запросах, упомянутых выше.
Менее частые поиски (по столбцам даты или другим) должны будут попасть на все разделы

Даже для последнего пункта, поиск не выполняется параллельно, так что во всех случаях это победа ? Каковы недостатки разделения? Почему это не то, что ВСЕ используют по умолчанию, по крайней мере, когда вы просматриваете более миллиона записей?

ОБНОВЛЕНИЕ - я выбрал ответ zgguy, но учтите, что я добавил свой собственный ответ с результатами своего собственного исследования, включая ссылку на действительно хороший ответ на похожий вопрос, который был очень полезен для меня.

mysql database-design partitioning

— Челл
источник

Ответы:

Не существует серебряной пули для проблем с производительностью, и разделение тоже не одно.

Каждый раздел по сути является таблицей для себя. Следовательно, запросы, написанные таким образом, чтобы база данных могла искать строки только в одном разделе, становятся быстрее. Разница может быть огромной для запросов, которые должны сканировать всю большую таблицу, но могут ограничиваться сканированием только одного раздела в многораздельной таблице. Для поиска уникальных ключей разница намного меньше.

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

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

— zgguy
источник

Таким образом, поиск уникальных / первичных ключей не приведет к значительному улучшению (если вообще будет?), Потому что индекс PK быстрее? Это по всем направлениям - бывают случаи, когда индекс PK медленнее? Что делать, если поиск перекошен на более недавно добавленные PK? Будет ли полезным раздел, основанный на PK (я думаю, что алгоритм ключа раздела должен быть модульным или похожим, а не хэш, верно?), Который заставляет большую часть активности воздействовать только на один раздел?

— Челл

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

— zgguy

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

— Челл

Я также пытаюсь понять ваш комментарий о запросах, которые затрагивают многие разделы (которые работают медленнее). Если запросы относятся к PK, который также используется (хэшируется) в качестве ключа раздела, разве БД не сразу узнает, на какой раздел перейти, основываясь на хэше поиска? Спасибо за помощь!

— Челл

Извините, в последнее время не удалось посетить обмен стека. Ответ, с которым вы связаны, великолепен. Я считаю, что это отвечает на оба ваших вопроса.

— zgguy

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

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

Я также видел упоминание о том, что MySQL никогда ничего не делает параллельно (было бы неплохо увидеть некоторые ссылки или более подробное объяснение этого).

Не видел, чтобы кто-нибудь говорил о том, добавляет ли деятельность по записи разные соображения.

— Челл
источник

Я не думаю, что пишет изменить ваш ответ. Вы упомянули 2 из 4 случаев использования, которые я нашел. До сих пор нет параллелизма даже в 8.0.

— Рик Джеймс

Самое первое, что приходит на ум - это обрезка разделов ; если это не то, что ваши запросы могут использовать.

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

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

— mysql_user
источник

Более новые версии имеют синтаксис для явного ограничения запроса разделом. Я не могу придумать вескую причину, чтобы когда-либо использовать такое.

— Рик Джеймс