Как «облегчить» таблицу в БД, но сохранить функционал?

Question

[Александр]

Здравствуйте, уважаемые программисты. Всех с новым годом! Назрел вопрос.
Есть таблица в БД с данными о голосованиях пользователей за комментарии/новости.

CREATE TABLE IF NOT EXISTS `votes` (
`id` int(11) NOT NULL,
  `id_com` int(11) NOT NULL,
  `news_id` int(11) NOT NULL,
  `user_id` int(11) NOT NULL,
  `toUserID` int(11) NOT NULL,
  `votes` varchar(1) NOT NULL,
  `dateAdd` datetime NOT NULL
) ENGINE=MyISAM AUTO_INCREMENT=671826 DEFAULT CHARSET=utf8;

Где
id_com - идентификатор комментария/новости, за который проголосовали;
news_id - идентификатор новости, в которой произошло событие;
user_id - идентификатор пользователя, который проголосовал;
toUserID - идентификатор автора комментария/новости, за который проголосовали;
votes - сам голос ( 0 - отрицательно, 1 - положительно);
dateAdd - дата события;

Суть в том, что таблица эта только наполняется и не чистится никогда и сейчас она уже хранит более 400 000 записей. Не чистится она потому, что реализован функционал, который позволяет навести на цифру с голосами и получить список пользователей, которые проголосовали. Т.е если её почистить, то этот функционал работать не будет, со старыми записями. А дальше, собственно, встает задача из названия топика. За ранее спасибо, рассмотрю любые идеи.

Answer 1

[Denis]

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

Comments

[Александр]

зачем нужен id новости, по id комментария обычно можно понять к какой новости он относится

Тогда будет лишний запрос на получение id новости... А тут уже все в наличии, так сказать ))

[Denis]

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

Answer 2

[Владимир Коротенко]

1. Агрегируйте данные и выводите их из "горячей таблицы"
2. Добавьте отдельный контроллер на детализацию.
3. Парционируйте таблицу по дате, логика будет сложнее, но в первую очередь в запрос будут попадать новые оценки
4. Какие индексы висят на таблице? Если нет то создайте для всех идентификаторов по которым происходят выборки
5. меня смущает поле votes почему оно varchar ? Используйте SET или CHAR

Comments

[Александр]

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

[Владимир Коротенко]

Александр, Вы сами ответили на свой вопрос. Мой ответ нацелен на уменьшение насилия сервера при выводе всех данных.
У вас чуть чуть усложняется структура, но вы делаете один простой запрос вместо 1 очень тяжелого.
А если человеку нужна статистика, то он заходит и смотрит, в том числе по пайджинации.

В итоге у вас висит 1 таблица с актуальными данными и несколько таблиц исторических, и 1 служебная где хранится агрегированная статистика пусть по месяцам.

В крайнем случае удаляйте давнишние данные и сохраняйте только метаданные.

[Владимир Коротенко]

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

Данные для аналитики обычно всегда большие, но никто их не стирает.

А вот "горячие" данные предпочитают оптимизировать. Впрочем это мое имхо. Приоритеты расставляет бизнес и мы можем делать только предположения.

[Александр]

Bavashi, да, вопрос поставлен именно так, как он поставлен. Суть - избавиться от лишних данных - которые, по сути, крайне редко используются, а особенно просмотр списка проголосовавших за комментарий, оставленный, допустим, в 2015 году. А может и никто не увидит эту новость никогда и не запросит этот список, но тем не менее, хотелось бы чтобы если это и произойдет, то все отработало как должно. Наверное я сам противоречу задаче и возможности, но возможно я просто чего-то не знаю. Ведь неужели все проекты хранят миллионы записей лайков пожизненно?

[Владимир Коротенко]

Александр, То есть обьем данных не проблема? Важна именно скорость отдельного запроса по статистике?

[Александр]

Владимир Коротенко, Задача именно избавиться от объема. Как я описал выше. Ведь смысл хранить миллион записей лайков, если их, возможно, никто никогда и не просмотрит. Но в отдельных случаях, возможность такая все-таки существует. Вот и думаю. Хранить все записи, ради работы всего функционала или удалять их (старые, раз в год, допустим, старее пару лет, которые)и не заморачиваться. При таком раскладе, пользователь просто увидит сообщение об ошибке получения данных из БД

[Александр]

Bavashi, Железо вроде бы нормальное и пока проблем особо не возникает. Это больше на будущее... Да и в целесообразности вообще хранения этих данных.

[Владимир Коротенко]

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

И выводите сообщение, что допустим данные доступны только за такой то период.

[Владимир Коротенко]

Александр, И немного юмора, фильм попался первым, не принимайте близко к сердцу, я не слишком религиозен.

https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D1%80%D...

А вот тут именно то что хотел процитировать.

Преждевременная оптимизация — корень всех зол. — статья «Structured Programming with go to Statements» в сборнике «Computing Surveys» (Vol. 6, № 4, декабрь 1974, стр. 268).


Premature optimization is the root of all evil.


Преждевременная оптимизация — корень всех (или большинства) проблем в программировании. — лекция «Computer Programming as an Art», напечатанная в сборнике «Communications of the ACM» (Vol. 17, Issue 12, декабрь 1974, стр. 671).


Premature optimization is the root of all evil (or at least most of it) in programming.

Через 15 лет Кнут в своей статье «The Errors of TeX»[1] высказывание об оптимизации упоминает как изречение Энтони Хоара: «But I also knew, and forgot, Hoare’s dictum that premature optimization is the root of all evil in programming». Поэтому эти цитаты могут быть ошибочно приписаны Хоару, а не самому Кнуту. При этом сам Хоар в 2004 году в своём письме Ганцу Генвитцу (англ. Hans Genwitz) с сайта phobia.com предполагает, что это высказывание принадлежит Эдсгеру Дейкстре[2].

Answer 3

[xmoonlight]

Вариант - только один: нормировать эту к днф3, разместив все дублированные данные по разным связанным таблицам.