Storing logs of users?

good old text files, + logrotate, no? Layer in the form of a database only the extra overhead will create.

will be faster to store in memcache/hkese or something and packs to upload to the database / files

Safer to store classic logs any failures in the system of statistics will not lead to data loss. However, this applies to systems where statistics are not needed immediately, and where data from the HTTP request is sufficient — do not need data from session or database, etc.
For example, using nginx you can fine-tune what and how to log, and the logs can be downloaded for example one in PostgreSQL copy command

If you do not need to frequently read the logs of the text files is the best solution.

Will be faster to write to the DB, stored in separate files and then write to the database when the server is not loaded.
In my opinion — if there is at least a minimal probability that your service will be of interest to a LARGE number of users at the architectural level, make a decision that these LOGS were on a separate server(servers)...

The question is ambiguous. Better test both.
\r
Now you know that if large enough blocks and enough parallel scripts will write to a file, messages can get mixed up?
here arises the need to synchronize access to a file, so there is a bottleneck where all parallel processes are blocked.
Whereas in the database there are already some interesting and freely available engines such as INSERT IGNORE, which returns the result "instantly".
Prepared statements and connection pooling also will be not superfluous.
\r
Then there is the view that really loaded the project logs the actions of users do not need. Except during debugging.

Scribe (http://github.com/facebook/scribe) is quite flexible, fast, simple, aggregation from multiple servers if required, possible integration with hadoop