Партиционирование в MySQL

Кто-то использовал в своей работе партиционирование таблиц MySQL?
Если да, то стоит ли использовать его для MODX? Например для таблицы контента или для таблицы тв-шек?
Не помешает ли это работе MODX? Чем это может быть чревато?

Пишут, что и не так всё тут гладко: http://habrahabr.ru/post/130999/

Хочется знать, стоит ли использовать данную технологию для оптимизации выборки из огромных баз, например где в modx_site_content по 500 тысяч строк.

Не хотелось бы поломать рабочую базу, хочу потренироваться на ~~кошках~~ тестовой базе.

Как правильнее разбить таблицы MODX на партиции?
Как разбить на партиции существующую наполненную таблицу? (в примерах везде CREATE TABLE)

Василий Столейков

07 января 2016, 18:18

4 170

Поблагодарить автора Отправить деньги

Комментарии: 9

Алексей Карташов

08 января 2016, 07:35

500 тысяч — это совершенно не та цифра, при которой надо задумываться о парцитировании. Конечно, базы, таблицы и нагрузки бывают разные, но на таблице modx_site_content на таких объёмах этого точно не нужно.
Но если у вас огромная посещаемость с просадкой на примитивных запросах, то лучше сервер помощнее докупить — 100% поможет, а времени и нервов сэкономите просто уйму.

Іван Клімчук

08 января 2016, 09:32

Ох, докупать мощности сервера только из-за просадки на паре запросов? Это пушкой по воробьям, достаточно поставить любой кеширующий слой и настроить его. Если выборка не критичная для получения realtime данных (на большинстве сайтов так и есть), то ничего не мешает ее кешировать в тот же редис на 10-20-30 минут и драматически снизить нагрузку в случае большой посещаемости. Поиск тоже делать через специаильный поисковые движки, которые позволяют построить оптимальный индекс, адаптированный именно для поиска по ключевым словам/фразам. Подводя небольшой итог: возможностей для оптимизации – вагон, увеличивать мощности последняя задача, которую следует рассматривать только в комлексе оптимизации архитектуры, а не просто увеличить памяти и ресурсов процессора.

Василий Столейков

08 января 2016, 09:51

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

Іван Клімчук

08 января 2016, 10:01

Ок, понятно, что данные будут считаться и тд. Но вот такой вопрос, есть допустим товар и у него какой-то параметр (например просмотры) равен 20 153. За 5 минут эта цифра увеличится на 113 единиц и станет 20 266. Мне как посетителю не критично знать сколько там конкретно просмотров у этой страницы, примерно 20 тыс и ладно. Поэтому ничего не мешает эту информацию кешировать на N минут. И я уверен, что таких параметров будет большинство. Реальные данные для одного-двух параметров можно оставить и то, если это критически важно, остальное все можно и нужно кешировать, ибо без кеширования это будет создавать бесполезную нагрузку.

Плюс есть такое понятие как отложенные вычисления. Если нужно что-то посчитать, то нет смысла это делать прямо сейчас. Пускай система записывает данные в master, к мастеру можно настроить slave, доступный только для чтения, оптимизированный под выборки, не обремененный блокировками записи. Расчетные показатели могут обсчитываться в фоне крон-скриптами или ругим ПО, например не на PHP, а на Go (что быстрее в разы) и добавляться в базу по мере обработки.

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

Василий Столейков

08 января 2016, 10:08

Спасибо за ценные мысли — обязательно приму на вооружение!!!
Сайт не интернет-магазин, это портал куда ежедневно стекаются сотни заявок на транспортные перевозки, всё работает на Tickets.
Вы мне дали пищу для размышления, буду пробовать…

but1head

08 апреля 2018, 19:55

Т.е. все 500к это ресурсы-тикеты? Серьезно?

Василий Столейков

08 апреля 2018, 23:58

Этот вопрос задавался очень давно, в момент планирования структуры. И да, рассматривался вариант на тикетах. Но в итоге сделал в отдельных 14 таблицах с почти одинаковой структурой, но отделённых по тематике. Это чтобы сократить нагрузку на БД. Так всё сейчас и работает.