Kyoto Tycoon MemcacheDB Express Test
Recently, purely by chance, the product from FAL Labs - Kyoto Tycoon , an easy data server, caught my eye. This product is based on QDBM (Quick Database Manager) - a key-value data storage. I was hooked by the fact that you can communicate with this “Magnate from Kyoto” using the memcached-like protocol.
Since I have been using MemcacheDB for some time, I wanted to compare their characteristics (the communication protocol is one, and there and there the NoSQL-key-value storage). Recently turned up an opportunity - exported a certain amount of data from one self-storage to MemcacheDB. For testing, it remains only to deploy Kyoto Tycoon on the same server.
Here's what I got:
The server on which it was tested - Opteron-2218, 2.6GHz, 8G OP, HDD 73G + 143G sas .
On a 73-gig disk there was a file with imported data, and on a 143-gig base, MemcacheDB and Kyoto Tycoon.
Initial data - 10226086 records, total volume (key + value) 1.4G.
Data servers are started by commands:
$ ktserver -port 11114 -tout 10 -log /var/db_tests/kyoto/ktserver.log -ls -dmn -pid /var/db_tests/kyoto/ktserver.pid -plsv /usr/local/libexec/ktplugservmemc.c.so -plex port = 11115 '/var/db_tests/kyoto/data.kch#opts=l#bnum=20000000#msiz=2g#dfunit=8'
$ memcachedb -p11117 -d -r -u sen -H / var / db_tests / mcdb / db / -N -v -P /var/db_tests/mcdb/mcdb_tests.pid
')
Results :
1. Import data:
- Kyoto Tycoon - 18 min. 52 sec.
- MemcacheDB - 32 min 39 sec
2. Data reading (according to the list of keys, data from the corresponding database was selected from the log, checksums were considered for verification):
- Kyoto Tycoon - 9 min. 46 sec. (restarted the demon to reset its cache, the result deteriorated by 4 seconds)
- MemcacheDB - 19 min 35 sec
3. “Races” (simultaneously launched both data import scripts):
- Kyoto Tycoon - 1 hour.
- MemcacheDB - 1 hour 38 min.
By the time the “Japanese” finish, a third of the total number of entries was loaded into MemcacheDB.
In such a big time of the general “race”, apparently, the increased daily load on the server was to blame. Unfortunately, I did not have an absolutely clean server. But the rest of the tests, except for this one, I started in more free hours and twice, in order to at least a little smooth out the extraneous influences on the process.
And a couple of characteristics :
1. Size of data files:
- Kyoto Tycoon - 2.15G (the next day it “shrunk” to 1.87G without loss of data, apparently freed empty blocks).
- MemcacheDB - 4.56G
2. The size of the occupied memory:
- Kyoto Tycoon - 2.45G. Honestly took how much he was allowed, plus the code and personal needs.
- MemcacheDB - 208Mb.
With this triple of tests, I decided to finish the comparison of the two products and tormented Kyoto Tycoon a little more by changing the settings. Since the data storage scheme used is a hash (a variant with a binary tree is also possible), the description states that the performance is affected by the base size of the hash table and it is recommended to set it approximately 2 times more than the number of records stored. Since in my task the number of records is constantly growing, it is important how much loss in speed is if this number significantly exceeds the specified size of the base hash.
Kyoto Tycoon test results with different parameters (I will only indicate what changed in the above command):
1. bnum = 5000000 (reduced 4 times, 2 times less than the number of records) - 17 min 28 sec
2. bnum = 2000000 - 17 minutes 45 seconds
3. bnum = 5000000 # msiz = 1g (it halves the size of the captured RAM) - 18 min 23 sec
4. bnum = 5000000 # msiz = 500m (another halve) - 19 min 15 sec.
5. no parameters for the data file (the option when the user does not bother with tuning has launched the server by copying the command from the manual):
- data import - 22 min. 4 sec.
- data reading - 11 min. 47 sec.
I drove this package of tests once. Differences in the results are small, within the limits of errors. Perhaps a little knocked out the result in the absence of the parameters of the data file (set by default). Apparently the default settings are quite modest - the server in memory takes only about 400 megabytes.
I didn’t bother with restrictions anymore. There will be time to approve, I will play with the settings, I will see at what stage the vault will start to choke. For myself, I made a conclusion - my Kyoto Tycoon load holds better than MemcacheDB. Maybe in the next project I will use it.
In addition, Kyoto Tycoon can be used as a clean cache memory, like Memcached. The developers claim that in some cases he even wins, but there are no comparative tests, it would be good to drive-check.
What particularly liked in the description is “improved robustness: the database file is not corrupted even under catastrophic situation” - the developers are unlikely to say this unfoundedly, for sure there will be someone who wants to check.
Ps. In fact, I had a small superficial comparison of MemcacheDB and Kyoto Tycoon, and a bit more detailed testing - Kyoto Tycoon. In any case, I did not attract the results for the ears, I worked with the real data of one of the projects I supported.
Pps. In addition to Kyoto Tycoon, FAL Labs has some more interesting projects. For example, Estraier is a personal full-text search engine, Hyper Estraier is a search engine for the community (what the difference is, I did not understand), Tokyo Promenade is an easy CMS. It would be interesting to make out how good these products are.
UPDT . Analyzing the results of the last test, I discovered that after starting the Kyoto Tycoon server, it is advisable to wait 5-10 seconds before sending him data to save. During the test, when I restarted the server with new parameters and immediately started sending data to it - about 16 thousand first records were lost. Those. for the first 2 seconds, the data loader banged his head against the wall. There was no loss when working with an already running server. Such a delay is normal - the layout of data fields, preparation for work.
UPDT2 . Since the default cache size for MemcacheDB is 64 Mb, I made a test with msiz = 64m - I equalized the cache sizes.
Result:
- record - 25 min 43 sec
- reading - 12 min 26 sec
Those. vseravno speed higher. But he ate RAM with 400 Mb - two times more than MemcacheDB.
Therefore, in terms of RAM, there is a loss, in terms of speed and size of the database on the disk, the gain (in terms of the size of the database is about 2.5 times).
Surely the gain in speed, including due to the more compact storage - less disk operations.
UPDT3 (dated 03.03.2011) . Delighted by the noticeably smaller database file size obtained with the above tests, put Kyoto Tycoon on another project, where BerkeleyDB (with MemcacheDB in the frontend) reached a size of 32 Gig. Now the Kyoto Tycoon base file “weighs” 30 Gig. Saved only a couple of gigabytes, the difference is no longer at times. Savings are highly dependent on the type of data. The tests used text data, which is well compressed, and in the new project - blocks of binary data. About the speed of work in this case I can not say anything. When the database is filled, the data is processed, which takes more time than the actual work of the database
.
Since I have been using MemcacheDB for some time, I wanted to compare their characteristics (the communication protocol is one, and there and there the NoSQL-key-value storage). Recently turned up an opportunity - exported a certain amount of data from one self-storage to MemcacheDB. For testing, it remains only to deploy Kyoto Tycoon on the same server.
Here's what I got:
The server on which it was tested - Opteron-2218, 2.6GHz, 8G OP, HDD 73G + 143G sas .
On a 73-gig disk there was a file with imported data, and on a 143-gig base, MemcacheDB and Kyoto Tycoon.
Initial data - 10226086 records, total volume (key + value) 1.4G.
Data servers are started by commands:
$ ktserver -port 11114 -tout 10 -log /var/db_tests/kyoto/ktserver.log -ls -dmn -pid /var/db_tests/kyoto/ktserver.pid -plsv /usr/local/libexec/ktplugservmemc.c.so -plex port = 11115 '/var/db_tests/kyoto/data.kch#opts=l#bnum=20000000#msiz=2g#dfunit=8'
$ memcachedb -p11117 -d -r -u sen -H / var / db_tests / mcdb / db / -N -v -P /var/db_tests/mcdb/mcdb_tests.pid
')
Results :
1. Import data:
- Kyoto Tycoon - 18 min. 52 sec.
- MemcacheDB - 32 min 39 sec
2. Data reading (according to the list of keys, data from the corresponding database was selected from the log, checksums were considered for verification):
- Kyoto Tycoon - 9 min. 46 sec. (restarted the demon to reset its cache, the result deteriorated by 4 seconds)
- MemcacheDB - 19 min 35 sec
3. “Races” (simultaneously launched both data import scripts):
- Kyoto Tycoon - 1 hour.
- MemcacheDB - 1 hour 38 min.
By the time the “Japanese” finish, a third of the total number of entries was loaded into MemcacheDB.
In such a big time of the general “race”, apparently, the increased daily load on the server was to blame. Unfortunately, I did not have an absolutely clean server. But the rest of the tests, except for this one, I started in more free hours and twice, in order to at least a little smooth out the extraneous influences on the process.
And a couple of characteristics :
1. Size of data files:
- Kyoto Tycoon - 2.15G (the next day it “shrunk” to 1.87G without loss of data, apparently freed empty blocks).
- MemcacheDB - 4.56G
2. The size of the occupied memory:
- Kyoto Tycoon - 2.45G. Honestly took how much he was allowed, plus the code and personal needs.
- MemcacheDB - 208Mb.
With this triple of tests, I decided to finish the comparison of the two products and tormented Kyoto Tycoon a little more by changing the settings. Since the data storage scheme used is a hash (a variant with a binary tree is also possible), the description states that the performance is affected by the base size of the hash table and it is recommended to set it approximately 2 times more than the number of records stored. Since in my task the number of records is constantly growing, it is important how much loss in speed is if this number significantly exceeds the specified size of the base hash.
Kyoto Tycoon test results with different parameters (I will only indicate what changed in the above command):
1. bnum = 5000000 (reduced 4 times, 2 times less than the number of records) - 17 min 28 sec
2. bnum = 2000000 - 17 minutes 45 seconds
3. bnum = 5000000 # msiz = 1g (it halves the size of the captured RAM) - 18 min 23 sec
4. bnum = 5000000 # msiz = 500m (another halve) - 19 min 15 sec.
5. no parameters for the data file (the option when the user does not bother with tuning has launched the server by copying the command from the manual):
- data import - 22 min. 4 sec.
- data reading - 11 min. 47 sec.
I drove this package of tests once. Differences in the results are small, within the limits of errors. Perhaps a little knocked out the result in the absence of the parameters of the data file (set by default). Apparently the default settings are quite modest - the server in memory takes only about 400 megabytes.
I didn’t bother with restrictions anymore. There will be time to approve, I will play with the settings, I will see at what stage the vault will start to choke. For myself, I made a conclusion - my Kyoto Tycoon load holds better than MemcacheDB. Maybe in the next project I will use it.
In addition, Kyoto Tycoon can be used as a clean cache memory, like Memcached. The developers claim that in some cases he even wins, but there are no comparative tests, it would be good to drive-check.
What particularly liked in the description is “improved robustness: the database file is not corrupted even under catastrophic situation” - the developers are unlikely to say this unfoundedly, for sure there will be someone who wants to check.
Ps. In fact, I had a small superficial comparison of MemcacheDB and Kyoto Tycoon, and a bit more detailed testing - Kyoto Tycoon. In any case, I did not attract the results for the ears, I worked with the real data of one of the projects I supported.
Pps. In addition to Kyoto Tycoon, FAL Labs has some more interesting projects. For example, Estraier is a personal full-text search engine, Hyper Estraier is a search engine for the community (what the difference is, I did not understand), Tokyo Promenade is an easy CMS. It would be interesting to make out how good these products are.
UPDT . Analyzing the results of the last test, I discovered that after starting the Kyoto Tycoon server, it is advisable to wait 5-10 seconds before sending him data to save. During the test, when I restarted the server with new parameters and immediately started sending data to it - about 16 thousand first records were lost. Those. for the first 2 seconds, the data loader banged his head against the wall. There was no loss when working with an already running server. Such a delay is normal - the layout of data fields, preparation for work.
UPDT2 . Since the default cache size for MemcacheDB is 64 Mb, I made a test with msiz = 64m - I equalized the cache sizes.
Result:
- record - 25 min 43 sec
- reading - 12 min 26 sec
Those. vseravno speed higher. But he ate RAM with 400 Mb - two times more than MemcacheDB.
Therefore, in terms of RAM, there is a loss, in terms of speed and size of the database on the disk, the gain (in terms of the size of the database is about 2.5 times).
Surely the gain in speed, including due to the more compact storage - less disk operations.
UPDT3 (dated 03.03.2011) . Delighted by the noticeably smaller database file size obtained with the above tests, put Kyoto Tycoon on another project, where BerkeleyDB (with MemcacheDB in the frontend) reached a size of 32 Gig. Now the Kyoto Tycoon base file “weighs” 30 Gig. Saved only a couple of gigabytes, the difference is no longer at times. Savings are highly dependent on the type of data. The tests used text data, which is well compressed, and in the new project - blocks of binary data. About the speed of work in this case I can not say anything. When the database is filled, the data is processed, which takes more time than the actual work of the database
.
Source: https://habr.com/ru/post/112253/
All Articles