Лайки как на тостере в БД?

Question

[РежимБога]

Хранятся в БД лайки к ответам в виде:
otvet_id | user_id

Дальше понятно юзер лайкает проверяем если есть соотношение - убираем лайк, если нет - ставим лайк.
Мыль 1: размер таблицы соответствий. Вот картинка с одного форума:

Всего в разделе 500 тыс. сообщений, пусть по 2 лайка в среднем к каждому - уже миллион строк соответствий. Это только один раздел, а разделов там много.

Мысль 2: Вот эта надпись "Вам нравится" т.е. мы уже проверили что лайк юзера тут стоит. Но одно дело дергать миллионную таблицу когда нажали на кнопку лайка, а второе просто при каждом отображении страницы зарегистрированному юзеру. БД не сойдёт с ума?

Мысль 3. И ведь не закешируешь страницу из-за этих лайков )) Ну либо запретить лайкать старые посты и закешировать?

Answer 1

[Komly]

Решается довольно просто у каждого ответа есть счетчик лайков который апдейтится либо при каждом новом лайке, либо в фоне каким-нибудь кроном.
Получается не сильно консистентно, но ждя форума это и не очень критично.

Comments

[lega]

тогда один пользователь сможет лайкать по 10-100 раз один пост...

[РежимБога]

Ахах да вам там налайкают так )))

[Komly]

lega: таблица с лайками никуда не девается, только добавляется ещё одно поле с счетчиком. Так нипример сделано в wordpress, на каждой записи есть дополнительное поле comment_count

[РежимБога]

Komly: тогда вы не сможете вывести "Вам нравится" т.е. что лайк у этого юзера уже стоит, он не видит, лайкает и в результате снимает свой лайк а не ставит его

[Komly]

РежимБога: почему? Дополнительным запросом можно взять лайки пользователя к этим темам и отобразить лайкал он или нет.

[РежимБога]

Komly: Так это и есть вариант который я изначально описал тогда поле с лайками лишнее раз мы всё равно запрос делаем ))

Answer 2

[VisualIdeas]

Незнаю, я бы просто хранил в таблице с лайками ещё и дату лайка и через месяц скидывал старые лайки а к записи просто счетчик для быстрого вывода. Если надо выводить список лайкнувших то выводите "Лайкнул Алекс, Макс и Федор и ещё 100500 человек"

Comments

[РежимБога]

Спасибо, не список лайкнувших не нужен

Answer 3

[D']

В чем проблема? Бд УЖЕ тормазит? Запросы выполняется дольше 1сек?
2-3-4, да даже 10 миллионов записей - ничто, если выборка по индексам идет.

Сделайте, проверьте, посмотрите что конкретно тормазит. Там больше будет PHP тормазит, чем БД с выборкой по индексам.

Comments

[РежимБога]

Нет не тормозит просто интересно нормально ли держать таблицу на 10 миллионов записей и лазить туда каждую секунду?

[D']

РежимБога: когда начнет тормазить, тогда можно будет думать об оптимизации. Добавить кеширование не проблема.

[Adamos]

РежимБога: Вы забываете, что у вас не будет РАЗНЫХ запросов к этой таблице каждую секунду. Посетители в основном шарятся по последним темам, запросы будут одни и те же, и результаты база будет выдавать из своего кэша. Если у вас движок форума не сделает кэш самостоятельно и вообще будет дергать базу.

[AlikDex]

РежимБога: храните историю лайков за месяц, остальное удаляйте. Смыслы держать особого нету. Врятли там будет 1 миллион в таком случае. Лайкают не особо на самом деле.
Могу поделится статистикой небольшой. Есть статейник, на нем порядка 4к в сутки посетителей. За месяц набралось всего 36тысяч лайков. Хотя когда прикручивал эти лайки, тоже парился насчет "их же будет много, как их хранить, и скорость выборки". Оказалось сущий пустяк.

[РежимБога]

AlikDex: Благодарю, за статьи зарегистрированные тоже голосуют? Я бы к ним вообще просто лайки прикрутил без соответствия с юзером, накручивать всё равно особо нет смысла.

[РежимБога]

Adamos: Да спасибо, я довольно плохо знаком с алгоритмом кеширования запросов в БД

[AlikDex]

РежимБога: все подряд. Для нерегестрированных 10 минутный лимит для повторного лайка. И тут вы правы насчет накрутки. Смысла нет.

[Freeman]

РежимБога: Чувак, СУБД -- это не массив! Запомни на всю жизнь.

[РежимБога]

Vapaamies: А кто тут сказал что СУБД это массив?

Answer 4

[lega]

Всего в разделе 500 тыс. сообщений, пусть по 2 лайка в среднем к каждому

1 и 2) Если лайков мало (10, 100), то можно список пользователей кто лайкнул хранить в самом сообщении. Таким образом не будет доп. таблицы и доп запросов.

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

Comments

[РежимБога]

Да думал про сообщение, но там место они жрут сильно а учитывая что форум и так места много пожирает это нежелательно

[lega]

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

если использовать новую mongodb, то там как раз есть сжатие и массивы в документе из коробки.

> 500 тыс. сообщений
даже если на каждое сообщение будет тратиться по 1кб - то это будет всего 0,5Гб - курам на смех.

Answer 5

[Александр Таратин]

Возьмите postgresql
У каждого сообщения храните поле с массивом id всех лайкнувших
www.postgresql.org/docs/9.1/static/arrays.html
и поле со счетчиком лайков.

Чтобы не дать лайкнуть несколько раз проверяйте нахождение id пользователя в том массиве.
https://stackoverflow.com/questions/11231544/check...
Добавлять пользователей в массив тоже просто stackoverflow.com/a/11008296

Comments

[РежимБога]

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

Answer 6

[Валентин]

1. Кеширование на стороне PHP
2. Грамотные индексы
3. Партиционирование
4. Тюнинг мускуя