Few queries on atomicity of requests
dormando at rydia.net
Sat Jun 21 06:18:33 UTC 2008
Sorry, I'll weigh in a little here. I've only been skimming so forgive
if this is a repeat:
- Overcomplicated. See dustin's rails examples for easy abstractions on
getting to the 90% mark.
- Crazy in-memory databases probably aren't that much faster. If you rip
out most of MySQL's parser and optimize your schema so InnoDB clustered
indexes and adaptive hash indexes morph into life, that's probably close
to as far as you're going to go.
- Limits your ability to cache the results of processing on multiple
queries... If you issue three queries, parse the results a little, then
use that elsewhere, you want to cache the cumulation if it's possible.
- Shouldn't limit your memcaching to the database :\
If you're displaying a blog, the amount of processing time you blow on
the template will likely outweigh any DB activity. Cache the results of
the entirety or chunks of template renderings. I believe you can KISS
all sections of this without wasting too much time.
> So, in conclusion, the end goal of this is to provide memcached type
> caching to the database in such a way that the data it returns is always
> accurate. I'm not saying this would be easy, but it does seem to be well
> worth the effort.
More information about the memcached