I have done two or three gigs lately with a very random distribution of data, so they do exist. But realistically there is going to be some repeatability. I think the idea is to show the extreme.

There is limited overhead for Memcahed on the same server. The drop was not that significant in the grand scheme of things what about 13%? Plus there is always the chance that over the tests things slow down for one test or another ( even with an average of 3 test runs, the sample set is small ).

Your saying with a 4GB buffer pool, the Memcached PK + Mysql is 2x ish faster. The 1385 # is for 2 memcached lookups and 1 Mysql write + 1 Memcached set. I have pure memcached lookup #’s -vs- pk lookups without the 3 combined and could make another post just on that if there is interest.

Yes I can make the source available.

Database is setup to have only 256M Buffer pool, so for many of the pages it needs to find – i.e. read from disk and then replace.

Redis is on a very long list of tools I want to try out.

There are always choices and other options. Here I am trying to get people to think outside the box and outside the database. If you don’t need sql, why use it?

That’s an interesting question, Testing with ssd and seeing the performance impact for both NOSQL -vs- MySQL would be very interesting.

For these tests I was on the same local machine as the DB running a perl client. The test in part 1 read from Memcached when the row it was looking for was there, otherwise would go to disk. In the event of a write i would write the row to the database and replace the row in memcached with the new value.

Indeed uniform distribution barely exists in the practice but I think for demonstration purposes it is a good choice.

I do not quite understand why MySQL + Memcache has so large regression in the first case. Considering memcache can do 17K gets per second (even if these are misses) the overhead for constant misses should be small. Was MySQL somethat affected on having memcache on the same box (which I assume was the case)

It is also very interesting to see if you fit everything in memory memcache is about 2x-2.5x better than MySQL for primary key lookups. Am I reading it correctly?

Also are you planning to make a sources available I think it would be really helpful right now I’m not sure I understand completely what is involved in every graph you’re showing.

Finally for update…. why would you see 17ms for update ? Is this because you have to go to the database which does not have it in the cache so read has to happen from the disk ? Modification itself is done in Buffer pool and has very low added latency.

At the tool you’re looking it is interesting if you can add Redis to the list. It is not as powerful as some other technologies in terms of automatic clustering etc but it is very simple which is cool.

Finally… I should note the direct implementation in MySQL is not only choice. The approach similar to SS tables can be used in MySQL as well. Replace your data to the “daily” small table which fits in ram while select from both small and large table. Do merge in the background.

And there is yet another one. How this all relates to SSDs ? Can it be simple solution instead of using “optimized” systems ?

I’d like to know more about the testing environment.
We use memcached on webheads with our database on separate machines connected over ethernet. Our web servers run nginx and have a tiny memory footprint, we dedicate the rest of the webhead’s RAM to a local memcached instance so all queries are done locally; we don’t take advantage of the distributed features memcached is known for.

Only if an object isn’t in the cache or has expired do we query the database (and populate the cache again).

From this article it appears that you are looking into using memcached as an alternative to a database server where the clients are connected remotely, not locally, and that you are writing to memcached.

Most people write to their database and read from memcached, I assume quite similarly to what we do, your ideas appear to be to use memcached for both reads and writes, at what point is the data stored persistently in the database if at all?

I look forward to your next posts Matt, keep up the good work.

from the memcached perspective would it matter if there where 4 or 8 million rows and I selected from and tried to cache only 2 million of them? The result would be the same in this case, too little memory too much data. Now from the Tyrant perspective since its disk based increasing the dataset could/should decrease performance, however in my tests I went up to 6 million rows and saw almost identical #’s to the 2 million set. The point about memcached not always fixing issues, is you need to understand your application and your access patterns. I run into many applications which 100% of its stored MySQL data is hot, and many times adding a caching layer does not help nearly as much as other environments. Now from a gaming standpoint, the specific example I was thinking of was finding an opponent from a list at random, then doing something with them before stuffing back into a list. But I have worked on others a game matching-making service, game lobby, etc… that all do very similar PK lookups.

In terms of scalability… There are many options here ( this article was not intended to be a primer on tyrant, rather to get people to think outside the database ), and for the most part its as scalable or not as MySQL. Replication, sure… then? Sharding… if you plan for this, or with some tweaks in the API of tyrant you could build sharing into the system. Also you can use the memcached API to access and write to tyrant which allows you to distribute your data across multiple locations. Tyrant however may not be the best solution for every setup, maybe its redis, or volemort, or cassandra, or something else… I think these all have features and specifics which make them compelling for certain applications… and hopefully I will find the time to write about these as well.

Matt

No these tests were with text and not with the binary protocol. Although that would be an interesting separate set of benchmarks.

I have seen a few such cases. One, for example, is a p2p client, which, every time someone goes online/offline, needs to read/write to the DB. There’s also a list of buddies to be managed. There are users in many continents, so different timezones; a lot more users are connected than can be cached; the result is an almost random behavior.
Another one is a plugin for websites, which calls upon the DB each time it’s displayed. It presented the same characteristics.

@Matt,
Great post!