Memcached Database Use

[Cal Heldenbrand]

No ORM, just pretty much straight up script doing most of the logic within
SQL.

I think our case is absolutely perfect for caching though, our top 10 tables
make up 99% of our reads.  Also, these top 10 tables have a massive
percentage of reads vs. writes.  In fact, our most hit table is at
96.4billion reads, and 26 writes.  This particular table is referenced
about
1500 times in the entire code base, so it will take some effort to scour
over the code and rewrite it for caching.

I think that is going to end up being our first solution, to sort of ease in
to the memcache integration.  We're starting to do a very small set of
functionality, and all of our web developers know it's available to them,
and they know how to use it.  New features rolling out the door are starting
to use memcache, and we're going through the current code base and
determining what can be cached.

I'm the one thinking that there just might be that "easy way" to do all of
this.  But apparently it's going to take some good ol' fashioned work.  :-)

Thanks!

--Cal

On 6/25/07, ydnar <ydnar at shaderlab.com> wrote:
>
> How abstracted are those 230 tables from the millions of lines of code?
> Are you using an ORM or is everything explicitly tied to the underlying
> schema?
>
> While Memcached can be used for row-level caching, it is ideally suited
> for caching in the Model layer of an MVC application.
>
> One approach might be to identify a small number (< 5) of areas in your
> code that would most directly benefit from caching, and implement a first
> pass there. Once that's working and you're more familiar with Memcached,
> look into a more comprehensive solution.
>
> Randy
>
>
> On Jun 25, 2007, at 8:33 AM, Cal Heldenbrand wrote:
>
> You have to one-by-one implement a separate variable storage after pulling
> from the database with a specific query, or implement some layer on top of
> memcache to try and do some of the logic for you.   We have 230 tables and
> millions of lines of code, the latter seems much more attractive.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070625/023edfa2/attachment.html