tyzhnenko
@tyzhnenko
System Administrator, DevOps, QA Engineer

Как поделить большую таблицу личных сообщений?

Есть:


Есть таблица личных сообщений, кол-во записей приближается к 100М :( и скорость работы с этой таблицей все уменьшается и уменьшается. В таблицу часто пишут и часто читают.

Messages:

msg_id — auto_increment

from_id — ID пользователя отправителя

to_id — ID пользователя получателя

subj — тема

date — время создания

status — новое, прочитанное, отвеченное



Вопрос:


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


Про партиции думали, отказались из-за того что восстановление из бекапа всей таблице занимает уйму времени. Да и создание партиций на такой таблице занимает кучу времени.


Спасибо за помощь. Отвечу на любые дополнительные вопросы :) Ну и напишу статью если будет интересно и актуально по такому вопросу.

UPDATE:


Всем спасибо. Пока больше всего нравятся следующие идеи.
  • Сделать архивные таблицы и сделать оглавление к ним
  • А так же разделить таблицу на несколько, оставив в основной только самые необходимые поля



У кого будут идеи как это можно улучшить или сделать совсем иначе?..

Думал в сторону шардинга, никак ума не приложу как это можно сделать с сообщениями. Когда один объект принадлежит больше чем одному пользователю :(

UPDATE2:


К первому update'у добавления
  • Все это добро перенести на InnoDB
  • Рассмотреть возможность перехода на uuid
  • Вопрос задан
  • 4222 просмотра
Пригласить эксперта
Ответы на вопрос 6
jarvis
@jarvis
Ого, ну вы и затянули с масштабированием! Поделюсь ссылкой на презентацию архитектуры Pinterest, в ней они рассказывают как преодолели эту проблему и делятся примерами кода. Возможно поможет.
Ответ написан
Praeses
@Praeses
Автоматическая (пользовательский клик) архивация в таблицу arch_msg по дате? С теми же полями и записью даты архивации?
Ответ написан
sl_bug
@sl_bug
Насчет шардинга советую посмотреть видео univertv.ru/video/informatika/programmirovanie/ruby_on_rails_moscow/rails_do_scale/ там рельсы, но и шардинг затрагивается неплохо.
Ответ написан
Комментировать
@bugman
Надо топать от того, как крутятся селекты по этой таблице. Исходя из предположения что чаще всего клиенту нужно показать все его сообщения, логично сделать хеш-партицирование по идентификатору получателя. Число партиций подобрать опытным путем. Если мускуль поддерживает двойное партицирование, второй уровень партиций можно нарезать по датам. Самые дальние партиции дропать или перекладывать в архив.
Ответ написан
@edogs
Почему-то есть ощущение, что у Вас нет индексов на таблице.

100Мб при том что 99.99% выборок у Вас (если админы не мониторят личку по ключевикам) то выборка по from_id to_id, при наличии индексов на этих полях — все должно летать на 100мб-тах то всего, даже при условии что у Вас есть юзеры по 10% лички генерящие.

В крайнем случае можно попилить таблицу на 2 части. В одну сгрузить auto_id, from_id to_id, в другую auto_id и все остальное.
Ответ написан
@TimTowdy
Реальные примеры медленных запросов, их explain, какой тип таблицы (innodb/myisam), какие индексы, как меняется производительность под нагрузкой, пробовали ли профилирование запросов?
Удивляют здешние телепаты, которые дают советы, не зная условий.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы