I will describe the essence of the system:

a user visits the site (no registration) and spends time on it, leaving TEMPORARY records for 10 minutes, which other users can view and edit (or more precisely supplement the content of the post).

  • Problem one: where to save posts and additions to them?
    It seems to me that it is not necessary to use the base here because of the speed (active recording / deletion / deletion of records after a short time), but will be limited to using the cache (memcached).

  • Problem two comes up from the previous one: how to identify user records? (Temporary posts grouped by users are displayed on the main page (of course, not quite on the main page, because many posts are a big page)).

We will not go deep into various methods of identification, and we will take simple ip. IP also save to cache? I am not familiar with memcached, but I will study it as I write, so I will ask in advance:

How to create an array in memcached, where each record stores in it a different amount of time?

I will schematically describe the structure of such an array in "C ++":

struct el { ip, //идентификатор пользователя, заодно и связка с постами. time // время хранения } list<el> users; //сохраняет всех пользователей, которые на сайте list.push_back( aпи и время ); //когда появляется новый пользователь, то добавим в базу в кеше. После истечения time, запись с users автоматически удалится.

Random entries associated with identifiers that are randomly obtained from this array will be displayed on the main page. How to get them randomly from an array in a cache?
Thanks for answers.

  • You have not yet implemented your idea, but are already abandoning the database. Did you measure performance? Not? Then produce, and then decide. If you don’t want to use relational databases, try NoSQL, mongodb all there, or key-value repositories like redis - nolka
  • @rikal, you really think that you need to make samples, but no memcached can support this. I can suggest that you simply create tables in memory when you start the server, there should be no problems with storage and fast delivery of data. - etki
  • @nolka, look at my comment on the answer @Manitikyl. It is already obvious that the load will be huge. - rikal
  • @Etki, but this is interesting. It turns out as if ordinary tables mysql (or other base), which are created using ENGINE = MEMORY? And they can work until the server restarts mysql. The truth is again the problem with deleting the record and the links to the record over time. - rikal

1 answer 1

MySQL was created in order to actively use data and work with them, and not just look. One or two questionnaires plus will not solve anything (even 10). And through time. memory you can and lose.

  • @Manitikyl, alright. Let's go from using the base. Each user of the site can view any records of other users (access to the database). Each user can save the values ​​in the database, but it also needs another cron to delete the record from the database after 10 minutes. In addition, additions to the post are made by other users, and this is also an entry into the database and extracts from it. After 10 minutes you will need to remove all links to the main post. Total use base is expensive. - rikal
  • @rikal, while ten thousand people do not use the base, it fits into standard use. - etki
  • @Etki, I liked the idea of ​​a memory table. As I understand it, with active extraction / removal / addition (per 10 thousand people) there should be no problems? Then why, for example, does VC use memcached if it were possible to store frequently used data in a memory table? - rikal
  • @rikal, memesh is for cache. Those. there is some kind of permanent storage, every time it is expensive to pull it, so the results of calls to it are cached for some time. Memcached is much simpler (and therefore more reliable and faster) than relational databases, and even simpler than other relatively simple nosql databases like redis. It is easier due to the fact that it can only get the value by key and save the value by key. This is just enough for the cache, but something more to do with this is problematic. - MrClon
  • @rikal, and the memory table is a complete (although it seems there are some limitations, but these are the details) the table in the relational database, with all the nishtyak. But, I think, it will be significantly slower than less-featured solutions that store data in memory. In general, a lot of in-memory databases have been divorced, so if you want to be confused about performance and there is no need for complex samples and reliable storage, you should look in the direction of such databases. On the other hand, SQL is familiar, understandable and reliable (in the sense of mysql it will not be bent for sure in a year, because the investment has run out). - MrClon