Как лучше всего передавать и хранить, просмотры и лайки на PHP?

Question

[Сергей]

Хочется узнать у опытных разработчиков методы хранения и передачи данных например о просмотрах и лайках.
Есть PHP 7+Nginx+MySQL.
Самое очевидное для меня - это просто завести отдельную таблицу под просмотры например и лайки, где каждый просмотр пользователя и лайк фиксировался с привязкой к новости\посту и тд. , а потом на основе просмотренных постов например выдавались в ленте только те, которые не были еще просмотренными. Ну и каждый вывод поста бы запрашивал все лайки с ним связанные.
Способ мне кажется топорным и вообще не быстрым :)
А хочется сделать по уму, чтобы как то оптимизировать способ передачи и хранения, не нагружая сильно сервер и базу.

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

Возможно есть пути решения через NGINX или PHP, для этого?! Вообщем интересно кто и как реализует подобное в своих проектах или может знает пример реализации :)

Comments

[Дмитрий]

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

[Сергей]

Дмитрий, ну я же написал связку имеющеюся и там есть mysql :)
Все хранится там, вопрос именно стоит какие практики есть по структуре хранения и записи их в базу, чтобы снизить кол-во нагрузки на сервер и базу.

[Дмитрий]

Сергей, примерно такой, просмотры можно хранить в записи поста или новости, просто инкрементить счётчик
update news set views = views + 1 where id = 1
А лайки в отдельной таблице
id | user_id | news_id(возможно даже тут будет поле type где будет записан тип , новость или пост или ещё чего), sub_id (ид объекта)

insert into (user_id, type, sub_id) values (1, 1, 1)

Выборка

select * from news join likes on news.id = likes.sub_id where cat = 1 limit 10, 10

[Developer]

Архитектура зависит от нагрузки

[Сергей]

Дмитрий, я же этот способ описал в вопросе))) естественно это самый простой путь. Только мне кажется есть практики показывающие лучшую производительность. Поэтому хочется узнать, кто как делает.
Возможно при помощи каких то демонов можно писать и выдавать инфу о просмотрах \лайках минуя кучи запросов напрямую в бд.
Возможно еще есть какие то решения. Вот это и интересно по сути, кто как реализует подобное :)

[Сергей]

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

[Дмитрий]

Сергей, ну как написали выше, зависит от нагрузки, может там кэш какой либо, или ещё чего. Сделайте сначала обычно

[Сергей]

Дмитрий, обычно я уже делал спасибо) интересны другие решения)

Answer 1

[Сергей Соколов]

Посты лайкаются и смотрятся неравномерно: бурлят свежие посты, статично висят старые-забытые.
Поэтому для кипящего ядра можно держать данные в оперативке, скажем, в Redis – туда писать, оттуда читать. Если ключа поста нет в Redis, то вынимать из БД. Периодически из Redis'а копировать в БД все данные и убирать из Redis данные по постам, которые перестали обновляться.

Часть нагрузки можно передать на клиент. При загрузке с сервера всем раздавать одинаковые данные о свежих постах (их id без содержания, если длинные). Далее по мере просмотра счётчики лайков/просмотров обновлять на клиенте, синхронизируя лайки с сервером не так часто. И скрипт на клиенте решает дальше, какие посты подгружать и показывать, учитывая локальные просмотры.

Ещё мысль: nginx умеет Lua. Можно операции с лайками/просмотрами поручить сольному nginx без PHP. Правда, возникает вопрос с авторизацией.

Comments

[Сергей]

Спасибо за вариант решения!
Получается Вы предлагаете в Redis хранить ID поста как ключ, а в значения писать список ID пользователей поставивших лайк и просмотревших пост. Если я правильно описал решение, то у меня вопрос - сможет ли Redis держать большое значение в одном ключе, учитывая что лайков и просмотров будет много?

[Сергей Соколов]

Сергей, в Redis FAQ есть ответ на ваш вопрос: до 2³² ключей, в каждом до 2³² значений. Ограничение, с которым быстрее столкнётесь это объём памяти.

Answer 2

[Дмитрий Чижов]

А я бы кешировал просмотры и лайки и обновлял кеш при каждом новом лайке. Хранить такое количество данных лучше в click house. В памяти хранить кеш, поддерживать кеш в таблице, периодически обновляя. Как замена редису если вдруг тот очистится или рухнет. А подробности в кх. Иначе у вас база тормозить начнет через десяток миллионов записей. Редис не предназначен для хранения постоянных данных

Comments

[Сергей]

Спасибо за вариант решения! ни разу еще не связывался с Redis однако читая вчера статьи типа Redis vs Memcached часто видел утверждения что Redis может использоваться для постоянного хранения данных)
Видимо фанаты Redis немного привирают :)

[Дмитрий Чижов]

Сергей, вообще то может и используется. может и предназначен разные понятия. Микроскоп тоже не предназначен для забивания гвоздей, однако он может это делать (наверное). Я бы не стал доверять на 100% сервису, который хранит данные в памяти. В зависимости от вашей нагрузки, можно в этой схеме отказаться от редиса, или даже от кх заменив их мускулем, пока нет потребности в большем. Есть у людей привычка собирать истребитель что бы съездить за хлебом =)

[Сергей]

Дмитрий Чижов, тут больше вопрос, для изучения вариантов решения. Так сказать посмотреть как подобное решают разные разработчики. Естественно городить что-то огромное ради небольшой посещаемости это глупо.
Тут больше хочется увидеть различные варианты решения и понять какие решения применяются для каких нагрузок, т.е. выстроить таблицу в голове от самых простых решений до решений рассчитанных на highload проекты :)

[Сергей]

Дмитрий Чижов, спасибо кстати за подсказку про click house. Видел как то в новостной ленте давно об этом продукте яндекса, но не вникал. Сейчас почитал оказывается действительно мощная система БД, учитывая что подобное работает в продуктах яндекса таких как метрика, где объем данных и кол-во запросов просто зашкаливает :)

[Дмитрий Чижов]

Сергей, насколько я помню, она создавалась именно для метрики. что бы хранить много и быстро оперировать. Умеет собираться в кластер и масштабироваться. Ребята с яндекса на devconf как то давно рассказывали что она собирает запросы sql и распределяет между серверами как то хитро. отсюда скорость выборки. И заверяли что положить кх запросами нереально при правильной настройке.
Штука то мощная. Только это не БД, это хранилище данных. там вроде как нет даже метода удаления данных, что говорит о предназначении. Да и использовать только в большом продакшне оправдано.

Answer 3

[IgorAlentyev]

Добрый день! Попробую предложить решение, как бы я сделал.
Во первых, я бы не писал на чистом PHP, а использовал бы фреймворк, тот же Laravel, там есть функционал который вам нужен, и он поможет грамотно организовать всё и удобно работать с кешем. Но если хочется без фреймворков и у вас не планируется прям highload, то я бы делал как то так:
Для хранения лайков вам в принципе написали вариант, для новых постов храните в редисе/мемкеше, да где угодно, можно и прямо в базе, если у вас не будет огромной посещаемости, то и проблем не будет.

Что касается организации таблиц - как вариант, вот у вас есть пользователь, у него есть ID. Создаете таблицу, в неё user_id, liked_post_id. Это, если вам например нужно будет отдельно выводить лайкнутые посты конкретного юзера, ну и это поможет, если вам нужно отображать в ленте уже лайкнутые посты. (Главное не говнокодить, то есть не нужно на каждый пост в цикле делать отдельный запрос в БД. Получите сначала все лайкнутые посты пользователеля в массив, и при выводе в цикле постов, через array_search просто ищите нужный пост)

Если вам не нужно выводить лайкнутые конкретного пользователя, а нужно только выводить общее количество лайков поста, то самый простой вариант - у вас есть таблица с постами, добавляете туда likes_count, как то так. И на каждое нажатие лайка этого поста обновляете значение.

По поводу просмотров - логика примерно такая же, если вам нужно считать просмотры только с "детальной страницы поста", то при заходе на страницу поста увеличиваете значение views_count в БД у этого поста.
Если вам нужно отлавливать просмотры в списке, то есть JS библиотека, которая это умеет, скорее всего даже не одна, к сожалению я не помню как называется, но можно посерчить так - "js div в области видимости". Соответственно когда сработает событие JS библиотеки, делаете ajax на пхп файл, в который передаете ID поста, ну а дальше всё как выше написал.

Что касается производительности - не слушайте новичков, если у вас НЕ лютый highload, то всё у вас будет летать. MySql - очень быстрая БД, и несколько легких запросов не будут проблемой.

В ленте выводите не все посты сразу, используйте LIMIT offset, и выводите через постраничку или бесконечный скролл, что в принципе одно и то же, только в случае с бесконечным скроллом, вы ajax-ом подгружаете данные и вставляете в DOM.

Если у вас большое количество данных и будут тормоза, то есть куча статей с решениями таких проблем.
Одна из них - https://habr.com/ru/post/217521/

В любом случае, удачи и успеха!

Answer 4

[Антон Р.]

Главная проблема в том как твоя система будет определять просмотренные? Каждый раз перебор по сотням и тысячам записей в базе? Бред, БД упадет. Здесь надо сильно подумать. Ну или устроиться программером на Пикабу и подсмотреть как у них сделано ))

Comments

[Сергей]

вот и я думаю бред)) поэтому решил просто спросить у более опытных кто уже связывался с такими задачами и кому не жалко поделится своими знаниями)

[Антон Р.]

Сергей, подумай как отсекать не нужные проверки. Для примера, у тебя блог в 10 000 постов, на странице выводится по 10 постов, для проверки на просмотренные тебе не нужно проходить все 10 000 постов так как юзер врятле глубже 100-200 постов пройдет, поэтому проверяй только "свежак" - последнюю сотню или две. Это я абстрактно накидал идею.

Answer 5

[Александр N++]

Таблица для лайков, просмотров, голосования - это нормально нормально, вы не Гугл и не фейсбук
Голосование с оценкой
UIID, USER_ID, VOTE, POST_ID
Просмотры
UIID, USER_ID, POST_ID
Лайки
UIID, USER_ID, POST_ID

При голосование считаете 1 запросом количество, и обновление у новости, фото, видео итд. Счетчик.

Comments

[Сергей]

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