Comments on: MySQL-Memcached or NOSQL Tokyo Tyrant – part 3 http://www.mysqlperformanceblog.com/2009/10/19/mysql_memcached_tyrant_part3/ Percona's MySQL & InnoDB performance and scalability blog Sat, 11 Feb 2012 16:45:54 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: kristina http://www.mysqlperformanceblog.com/2009/10/19/mysql_memcached_tyrant_part3/comment-page-1/#comment-669940 kristina Wed, 28 Oct 2009 18:15:09 +0000 http://www.mysqlperformanceblog.com/?p=1435#comment-669940 +1 for MongoDB +1 for MongoDB

]]> By: Jayson http://www.mysqlperformanceblog.com/2009/10/19/mysql_memcached_tyrant_part3/comment-page-1/#comment-669923 Jayson Wed, 28 Oct 2009 16:33:42 +0000 http://www.mysqlperformanceblog.com/?p=1435#comment-669923 hi, may be you should try MemcacheDB(http://memcachedb.org/) too, it uses BerkleyDB as persistence db hi, may be you should try MemcacheDB(http://memcachedb.org/) too, it uses BerkleyDB as persistence db

]]> By: Justin Leider http://www.mysqlperformanceblog.com/2009/10/19/mysql_memcached_tyrant_part3/comment-page-1/#comment-669609 Justin Leider Tue, 27 Oct 2009 17:18:58 +0000 http://www.mysqlperformanceblog.com/?p=1435#comment-669609 I second the CouchDB request. I second the CouchDB request.

]]> By: Vladimir Rodionov http://www.mysqlperformanceblog.com/2009/10/19/mysql_memcached_tyrant_part3/comment-page-1/#comment-667439 Vladimir Rodionov Wed, 21 Oct 2009 22:24:34 +0000 http://www.mysqlperformanceblog.com/?p=1435#comment-667439 Voldemort + BDB, please and pure BDB (1 server). Voldemort + BDB, please and pure BDB (1 server).

]]> By: Jim http://www.mysqlperformanceblog.com/2009/10/19/mysql_memcached_tyrant_part3/comment-page-1/#comment-667316 Jim Wed, 21 Oct 2009 15:56:56 +0000 http://www.mysqlperformanceblog.com/?p=1435#comment-667316 Great articles! I appreciate the thoroughness of each experiment and the discussion of methodology and outcomes. Looking forward to the next tests. Great articles! I appreciate the thoroughness of each experiment and the discussion of methodology and outcomes. Looking forward to the next tests.

]]> By: Arin Ben Aharon http://www.mysqlperformanceblog.com/2009/10/19/mysql_memcached_tyrant_part3/comment-page-1/#comment-667212 Arin Ben Aharon Wed, 21 Oct 2009 09:56:06 +0000 http://www.mysqlperformanceblog.com/?p=1435#comment-667212 I think we should examine redis redis is a key value database, however it support persistency and clients (PHP/ Ruby/Perl /Java / Python / tcl ... some of the clients support sharding ( not need to re-implement that) and there is also terracotta ... Best Regards I think we should examine redis
redis is a key value database, however it support persistency and clients (PHP/ Ruby/Perl /Java / Python / tcl …
some of the clients support sharding ( not need to re-implement that)

and there is also terracotta …

Best Regards

]]> By: Nicolas http://www.mysqlperformanceblog.com/2009/10/19/mysql_memcached_tyrant_part3/comment-page-1/#comment-667092 Nicolas Wed, 21 Oct 2009 03:18:27 +0000 http://www.mysqlperformanceblog.com/?p=1435#comment-667092 We tried Tokyo a few months ago to replace some MySQL databases and found that requests block and time out when you do a sync to disk. Normally Tokyo will work in memory and only when you call sync will it flush everything to disk. Response times which are normally around a few milliseconds go up to many seconds while Tokyo is synching. Have you taken sync into account for your benchmarks? We tried Tokyo a few months ago to replace some MySQL databases and found that requests block and time out when you do a sync to disk. Normally Tokyo will work in memory and only when you call sync will it flush everything to disk. Response times which are normally around a few milliseconds go up to many seconds while Tokyo is synching. Have you taken sync into account for your benchmarks?

]]> By: vladimir http://www.mysqlperformanceblog.com/2009/10/19/mysql_memcached_tyrant_part3/comment-page-1/#comment-666986 vladimir Tue, 20 Oct 2009 21:11:04 +0000 http://www.mysqlperformanceblog.com/?p=1435#comment-666986 One more vote for testing Redis One more vote for testing Redis

]]> By: tommy http://www.mysqlperformanceblog.com/2009/10/19/mysql_memcached_tyrant_part3/comment-page-1/#comment-666961 tommy Tue, 20 Oct 2009 20:06:58 +0000 http://www.mysqlperformanceblog.com/?p=1435#comment-666961 would be interested in couchdb and mongodb would be interested in couchdb and mongodb

]]> By: matt http://www.mysqlperformanceblog.com/2009/10/19/mysql_memcached_tyrant_part3/comment-page-1/#comment-666868 matt Tue, 20 Oct 2009 13:35:23 +0000 http://www.mysqlperformanceblog.com/?p=1435#comment-666868 @dormando Not glossing over the scalability difficulties... any project requires you to plan for future growth and come up with a plan. If you do not do this ahead of time the potential for disaster or a painful scale out increases dramatically. The plan to scale out Tyrant or MySQL will hit similar challenges at a certain point. For instance if you did not plan to shard MySQL and now have to that's a big painful task for a large dataset. Similarly for tyrant. I am not aiming this blog post to be an all encompassing Tyrant playbook, there are too many variables out there for that. Instead this is designed to show there are alternatives to MYSQL and some of these can be faster in certain situations. I agree performance is one factor of many when deciding on an architecture, its a big one but only one. If tyrant is not faster then MySQL most people would not even consider it... so hopefully this solicits feedback, get people talking, thinking outside the database, etc. @dormando Not glossing over the scalability difficulties… any project requires you to plan for future growth and come up with a plan. If you do not do this ahead of time the potential for disaster or a painful scale out increases dramatically. The plan to scale out Tyrant or MySQL will hit similar challenges at a certain point. For instance if you did not plan to shard MySQL and now have to that’s a big painful task for a large dataset. Similarly for tyrant. I am not aiming this blog post to be an all encompassing Tyrant playbook, there are too many variables out there for that. Instead this is designed to show there are alternatives to MYSQL and some of these can be faster in certain situations. I agree performance is one factor of many when deciding on an architecture, its a big one but only one. If tyrant is not faster then MySQL most people would not even consider it… so hopefully this solicits feedback, get people talking, thinking outside the database, etc.

]]>