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

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

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

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

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

Как правильнее разбить таблицы MODX на партиции?
Как разбить на партиции существующую наполненную таблицу? (в примерах везде CREATE TABLE)
Василий Столейков
Василий Столейков
07 января 2016, 18:18
modx.pro
4 945

Комментарии: 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
            but1head
            08 апреля 2018, 19:55
            Т.е. все 500к это ресурсы-тикеты? Серьезно?
              Василий Столейков
              Василий Столейков
              08 апреля 2018, 23:58
              Этот вопрос задавался очень давно, в момент планирования структуры. И да, рассматривался вариант на тикетах. Но в итоге сделал в отдельных 14 таблицах с почти одинаковой структурой, но отделённых по тематике. Это чтобы сократить нагрузку на БД. Так всё сейчас и работает.
    Александр Лыженков
    Александр Лыженков
    08 апреля 2018, 15:24
    Очень подробно партицирование данных на примере БД Mysql (MariaDB) рассмотрен в статье Как обрабатывать статистику за длительный период
    рекомендую
    Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
    9