What is the best way to transfer and store views and likes in PHP?

Question

PHP

I would like to learn from experienced developers methods of storing and transferring data, for example, about views and likes.
There is PHP 7+Nginx+MySQL .
The most obvious thing for me is to simply create a separate table for views, for example, and likes, where each user's view and like was recorded with reference to a news / post, and so on. , and then, based on the viewed posts, for example, only those that had not yet been viewed were displayed in the feed. Well, each post output would request all the likes associated with it.
The method seems clumsy to me and not fast at all :)
But I want to do it wisely in order to somehow optimize the method of transmission and storage without heavily loading the server and database.
What options are there for today, so that it is possible to approach the transfer and storage of this kind of data in a different way, where, in fact, small information takes up a bunch of lines and causes a bunch of small requests.
Perhaps there are solutions through NGINX or PHP for this?! In general, I wonder who and how implements this in their projects or maybe knows an implementation example :)

Answer 1

Posts like and look uneven: fresh posts are seething, old-forgotten ones hang statically.
Therefore, for a boiling core, you can keep the data in the RAM, say, in Redis - write there, read from there. If the post key is not in Redis, then remove it from the database. Periodically copy all data from Redis to the database and remove from Redis data on posts that are no longer updated.
Part of the load can be transferred to the client. When downloading from the server, distribute the same data about fresh posts to everyone (their id without content, if long). Further, as you watch, the likes / views counters are updated on the client, synchronizing likes with the server not so often. And the script on the client then decides which posts to load and show, taking into account local views.
Another thought:nginx knows Lua . It is possible to entrust operations with likes/views to a solo nginx without PHP. However, there is a question with authorization.

Answer 2

And I would cache views and likes and update the cache with each new like. It is better to store this amount of data in a click house. Keep the cache in memory, maintain the cache in the table, updating it periodically. As a replacement for a radish if it suddenly clears or collapses. And details in kh. Otherwise, your database will start to slow down after tens of millions of records. Redis is not designed to store persistent data

Answer 3

Good afternoon! I will try to offer a solution, as I would do.
Firstly, I would not write in pure PHP, but would use a framework, the same Laravel, it has the functionality that you need, and it will help you organize everything correctly and work with the cache conveniently. But if you want without frameworks and you don’t plan a direct highload, then I would do something like this:
To store likes, you basically wrote an option, for new posts, store in radish / memcache, but anywhere, you can also directly in the database, if If you don't get huge traffic then you won't have any problems.
As for the organization of tables - as an option, here you have a user, he has an ID. Create a table, in it user_id, liked_post_id. This is, for example, if you need to separately display liked posts of a specific user, well, this will help if you need to display already liked posts in the feed. (The main thing is not to shit-code, that is, you don’t need to make a separate query to the database for each post in the cycle. First, get all the user’s liked posts into an array, and when displaying posts in the cycle, just search for the desired post through array_search)
If you don’t need to display likes of a particular user, and you only need to display the total number of post likes, then the easiest option is to have a table with posts, add likes_count there, something like this. And for each click on the like of this post, you update the value.
Regarding views, the logic is about the same, if you need to count views only from the "detailed page of the post", then when you go to the post page, increase the value of views_count in the database for this post.
If you need to catch views in the list, then there is a JS library that can do this, most likely not even one, unfortunately I don’t remember what it’s called, but you can look like this - “js div in the scope”. Accordingly, when the JS library event fires, do ajax to the php file, into which you pass the post ID, and then everything is as written above.
As for performance - do not listen to beginners, if you do NOT have a fierce highload, then everything will fly for you. MySql is a very fast DB and a few light queries won't be a problem.
In the feed, display not all posts at once, use LIMIT offset, and output through a page or an endless scroll, which is basically the same thing, only in the case of an endless scroll, you ajax load the data and insert it into the DOM.
If you have a large amount of data and there will be brakes, then there are a bunch of articles with solutions to such problems.
One of them is https://habr.com/en/post/217521/
In any case, good luck and success!

Answer 4

The main problem is how will your system determine what has been viewed? Every time iterate over hundreds and thousands of records in the database? Brad, the database will crash. Here you need to think a lot. Well, or get a job as a programmer at Pikabu and peep how they do it))

Answer 5

A table for likes, views, voting is normal, you are not Google or Facebook
Voting with an assessment
Views
Likes
When voting, count as 1 request the number, and update news, photos, videos, etc. Counter.