Какая оптимальная структура для таблицы «лайков»?

Question

[l4m3r]

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

create table `likes` (
  `post_id` int, 
  `user_id` int,   
  foreign key (`post_id`) references `users`(`id`) on delete cascade,
  foreign key (`user_id`) references `posts`(`id`) on delete cascade, 
)  engine=InnoDB, default character set = utf8;

1) Если, чисто теоретически представить, что пользователей миллионы, а постов десятки миллионов, является ли такая структура оптимальной?
2) нужно ли тут поле id, или PK сделать составной (post_id, user_id) или PK вообще не нужен? Это влияет на селект?

Answer 1

[orbit070]

Если, чисто теоретически представить, что пользователей миллионы, а постов десятки миллионов, является ли такая структура оптимальной?

Почти. Нужно применить дублирование и прокинуть в эту таблицу сразу все те поля, которые вам могут пригодиться для отображения, иначе каждый раз придется делать join, чего бы не хотелось при highload. То есть нужно добавить в таблицу сразу поля вроде user_name, post_title, post_body, и т.д(в общем все то, что вы планировали доставать с помощью join).

На счет "пользователей миллионы, а постов десятки миллионов":
Если у вас будет такое количество данных, то вам в любом случае в какой-то момент придется прибегнуть к горизонтальному шардингу, поэтому если считаете что проект реально может дорасти до такого количества данных лучше сразу учесть это и спроектировать базу данных так, чтобы горизонтальный шардинг не стал проблемой.

нужно ли тут поле id, или PK сделать составной (post_id, user_id) или PK вообще не нужен? Это влияет на селект?

Зависит от сценариев использования(подумайте, в каком случае вам нужно будет поле id), но в большинстве случаев оно не нужно и такие поля вводят для душевного спокойствия и гармонии. На селект это не влияет, ведь все равно вы будете делать выборку либо по user_id либо по post_id(опять же, это в большинстве распространенных сценариев, если у вас есть какая-то логика, где нужно будет выбирать из таблицы likes записи по какому-то намеренно введенному идентификтаору, то вводите).

Comments

[l4m3r]

VicTHOR, orbit070 блин, отправил им такой вариант как в посте и отказали. Ответ:
"почитать, а потом подумать что будет с таблицей лайков если будет куча insert/delete (и как сделать лучше)".
У меня даже нет идей по этому поводу.

[orbit070]

l4m3r, highload - понятие растяжимое, где-то большое количество операций чтения, где-то записи/удаления, как в вашем случае.

Я озвучил бы такие мысли для таблицы лайков:

Про много insert/delete возможно имеется в виду что индексы постоянно будут перестраиваться, блокировки там всякие. Чтобы смягчить это, можно например не удалять данные сразу, а помечать их как удаленные, а потом отложено удалять большими кусками все данные, помеченные как удаленные.

Убрать это

foreign key (`post_id`) references `users`(`id`) on delete cascade,
foreign key (`user_id`) references `posts`(`id`) on delete cascade,

PK скорее всего не нужен тут, скорее надо повесить неуникальные индексы на user_id и post_id.

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

Если будет возможность получить обратную связь и узнать что именно хотели от вас услышать, то буду благодарен если напишете, самому интересно.

Answer 2

[alex-1917]

Всплывала похожая проблема, именно с лайками.
Тормоза были из-за корявого кода.
Так как кол-во юзеров было уже под 2млн, постов у каждого от 1к до 30к,лайки соотвественно у каждого поста.
Надо было показывать выборку юзеров с накопленными лайками.
Решили сделать на клиенте)))
Посетитель выбирает массив юзеров, ему быстро отдаем основные данные, а ВЕСЬ МУСОР (лайки,шмайки, баллы) подгружаем отдельным (практически плоским мгновенным запросом) в фоне аяксом.
Нафига тащить сразу ВСЁ?...