Comparison of data processing speed (ETS, DETS, Memcached, MongoDb) in Erlang (spherical in vacuum)

Good day, dear% habrauser%!

Below is a small set of tests showing statistics on insertion / reading in / from a table / collection. It is clear that no test will show the real picture that will occur in your application. Still, out of sheer curiosity, I decided to take some measurements. Results and conclusions to which I came under the cut.

What was tested:
OS Name: Windows 7 Professional
OS Architecture: AMD64
Processor Name: Intel Core (TM) i5-3340 CPU @ 3.10GHz
Manufacturer: GenuineIntel
Processor Architecture: AMD64 / EM64T
Physical nuclei: 2
Logic Processors: 2
Total RAM: 8139 MB (7.95 GB)
')
For mongo, the latest version of the official driver is used.
For mc used the one that pulled the load. I used it with 10 different clients, some simply did not start, some tried to work asynchronously and fell.

Mongo version: 2.6.3
Version mc: 1.4.4-14-g9c660c0 (the last one that could be found compiled for Windows)
Erlang Version: 5.10.4 / OTP R16B03

A small remark before the start.

I foresee a question, like: “What does mongo have to do with this, how can you compare the vault in memory with the vault on disk ?!”. The question is reasonable. The answer is simple: I was curious. And so I made a comparison of those repositories that are popular and for which there are drivers in Erlang.
I remind you that all tests can be classified as spherical in a vacuum.

So let's get started.

Insert

The first thing I decided to check is the rate at which records are inserted and the memory consumed for this, the result was expected:

Native Ets-tables gave odds to everyone else ahead of the nearest competitor, dets, more than 10 times. But by the way, this is logical, since ets works in memory and dets on the disk. Mc also works in memory, but apparently. because of the driver (googling found results of about twice the speed of work), almost 70 times behind, monga was a little faster.

During the operation of inserting 10kk records, Mongod used 2.7 GB of RAM, ets took 2.87 GB, and Mc needed 1.6.

Sample:

There is no revelation here either. Ets were the fastest, followed by dets, then Mc and mongo, but then you should look at the last result. When working with a large number of records, Dets becomes inefficient, and the greater the number of records, the lower the efficiency, here Mc bypasses it. For mongo, an index was made across the sample field.

And finally, the number of records that can be processed in one second:

A little bit of conclusions

Minute cap: for caching data you need to use the built-in tools.
And, it would seem, really, what prevents to use ets-tables? The blessing can be kept in them any terms. The main disadvantage is that the data is stored in memory, and if the process that created the table drops, the table will disappear along with it, pulling along the processes that are being addressed to it at that moment. Yes, the process will be restarted by the supervisor, but the data is all that, bye-bye. Ok, let's use dets, everything is stored on disk and nothing is lost. Yes, but, oh, this is a “but”, the time of reopening and checking the table for damages with a large file size is very important, whether your processes will wait. So what remains is Mc, which, by the way, can also fall for some reason, or Monga, or, or ...
Yes, the harsh reality is that everything can fall, but, let's say Mc or Mongo have the opportunity to deploy clusters, and if one machine crashes, you can always turn to another. But they are the slowest tested systems. So you have to choose what to sacrifice, either with performance or data.
Although you can not choose or donate, for myself I came to the following conclusions:
1) In ets you need to store a “hot” data cache, which is constantly required and the loss of which does not promise big problems. And the documentation tells us that the dets of the table can be opened and used in memory, and when closed they are dumped to disk. But, as can be seen from the tests, dets are effective with a small amount of data, otherwise the time to work with the disk becomes too long.
2) All data that is critical for you, you need to save in a reliable storage, it does not matter, sql / nosql somewhere, where you will be calm for them.
3) We need a module similar to Mc, but on ets tables, which will allow the necessary data to be written to the hot cache so that they are immediately available, and in synchronous / asynchronous mode can transfer them to other storages

The conclusions turned out to be captain, but, probably, all the conclusions from some measurements are approximately the same and somewhere, once, have already been heard.

Thank you for attention.