memcached Digest, Vol 16, Issue 5

[Troy Hakala]

This is why putting memcache in the database layer is a bad idea. You have
to parse SQL to do it correctly. However, if you cache data at the
application level it's easier to know what you're caching (and what needs to
be dirtied). And you are able to cache the data after it's been massaged for
presentation so you save yourself that work too when retrieving the cached
data the next time.


Message: 2
> Date: Fri, 4 Nov 2005 12:38:49 -0800
> From: mike <mike503 at gmail.com>
> Subject: Strategies to cache from MySQL (or any DB I suppose)
> To: memcached at lists.danga.com
> Message-ID:
> <bd9320b30511041238j54b31cb2keaffb59d9ad798a2 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Obviously it's quite easy to request a single row from a table based
> on a key of "table:PK" - however, what if I do not query the table
> based on it's PK?
>
> I'd say the majority of the time, my highest traffic queries are not
> using a PK (or a compound PK) but a combination of [indexed] columns.
> Perhaps this is where I become "re-educated" in my thinking, and you
> guys say "hey stupid, instead of sending one database query to your
> database, break it up into two" - I *may* be over-engineering this.
>
> Take for example my forum code.
>
> User requests /forum/posts.php?t=$threadid
>
> I select from my database:
> SELECT foo,bar,baz FROM posts WHERE threadid=$threadid
>
> Obviously, when checking to see if the cache exists for that, I
> suppose I could use "posts:$threadid" for the key. But then I have to
> make sure that any time I may modify a row returned from that query, I
> have to dirty the cache for any already-cached information with
> threadid of $threadid.
>
> Hopefully I'm making sense. Perhaps someone else has some BKMs on how
> to change/break up database operations so that I can do caching on
> nearly every type of SELECT I will use. Because I'd like to leverage
> memcache for everything possible.
>
> File caching is easy - the key would always be the filename (or some
> sort of token based on it) - but the database stuff gets interesting
> based on how the data is being retrieved, and also how it's updated.
>
> Thanks in advance,
> mike
>
>
> ------------------------------
>
> _______________________________________________
> memcached mailing list
> memcached at lists.danga.com
> http://lists.danga.com/mailman/listinfo/memcached
>
>
> End of memcached Digest, Vol 16, Issue 5
> ****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20051105/453a4256/attachment.htm