3 ms·
Cool project. It's great to see people doing things like this. On the other hand, I don't know that it would be useful for many people. Note this caveat near
by bluesnowmonkey 16y ago
Cool project. It's great to see people doing things like this. On the other hand, I don't know that it would be useful for many people. Note this caveat near the end.
> No benefit for HDD bound workloads
Which is most workloads.
The author cites the expense of memory as the drawback to memcache. It's true, a large pool of dedicated memcache machines can be quite expensive. However, the given technology only works when the database fits in memory. If the database fits, then a cached subset of it certainly will fit as well. So memcache will only use a single server. One server is not a major expense compared to overhauling an application to marry it to a custom MySQL extension.
Also consider what happens if the database ever does grow beyond memory capacity. If you're using memcache, you might just need to add more cache servers. With HandlerSocket you'd have to... switch to memcache. Then add more cache servers.
- quassnoi 16y ago"HDD bound" here means that not all data fits into the cache. Given the average RAM size on even an entry-level server (some 16 or maybe even 8 GB) and the average size of a database (same 8GB on http://musicbrainz.org/ http://musicbrainz.org/, the largest online music database), I wouldn't claim that it's "most workloads".
- icey 16y agoIf we're comparing anecdotes, the smallest database I deal with on any given day is 50GB. Enterprise applications trap lots of data. I don't know that most of our queries are HDD bound, but a significant portion of them are.
- alexro 16y agoI think while the most performance-critical portion of your data fits in memory you should be alright with this method. The rest of the data can be consumed using normal SQL approach.
- morgo 16y ago"No benefit for HDD bound workloads" This means no benefit over regular MySQL releases, not to say that MySQL doesn't have some nice features. InnoDB can read/write in multiple threads - which is useful on RAID controllers which require concurrency to exploit all their throughput. Newer SSDs also like concurrent writes. Compare this to at least MongoDB which uses a single reader/writer thread.