unclear on memcached ?

[surfivor]

I understand that memcached can store objects on different servers
using hashing, and I've seen typical things such as storing query
results.

Say at line 100 in module 'A', I want to render some content so I
check the memcache. If previously I had rendered this from this same
line of code and it's in the cache, then I use that. However, what if
module B changed one of the records on the database and that was in
the cache ? It must be up to me to have a scheme worked out that I
will delete the object from the cache that is referenced from module A
because I changed the database.

[Erwin Moller]

surfivor wrote:

>
I understand that memcached can store objects on different servers
using hashing, and I've seen typical things such as storing query
results.

Say at line 100 in module 'A', I want to render some content so I
check the memcache. If previously I had rendered this from this same
line of code and it's in the cache, then I use that. However, what if
module B changed one of the records on the database and that was in
the cache ? It must be up to me to have a scheme worked out that I
will delete the object from the cache that is referenced from module A
because I changed the database.

Hi,

Sorry if I sound stupid because I never worked with memcache, BUT isn't this
excactly the kind of thing where you need a database?
A database will handle your concurrency, possible changed tuples, etc just
fine.

You can even store the results of a query in the database if you want, and
just update that when needed (= when the underlying data changes).

Regards,
Erwin Moller

[Czapi]

Erwin Moller wrote:

You can even store the results of a query in the database if you want, and
just update that when needed (= when the underlying data changes).

Yes, but memcache is a lot faster than any SQL engine. The only thing
that could match the speed would be a memory storage engine as
implemented in MySQL - for simple pkey indexing I think it still
couldn't match memcache.

So RDBS gives you much more flexibility and scalability but at the cost
of complexity you might not need.

However in this case I would go for MySQL + memory storage engine.

--
Cz.

[surfivor]

On Mar 16, 5:21 am, Czapi <[e-mail] te:

Erwin Moller wrote:

You can even store the results of a query in the database if you want, and
just update that when needed (= when the underlying data changes).

Yes, but memcache is a lot faster than any SQL engine. The only thing
that could match the speed would be a memory storage engine as
implemented in MySQL - for simple pkey indexing I think it still
couldn't match memcache.

So RDBS gives you much more flexibility and scalability but at the cost
of complexity you might not need.

However in this case I would go for MySQL + memory storage engine.

--
Cz.

Thanks, but I asked the question as a hypothetical to try to
understand how memcached works. At this point, I am not sure all the
possible scenarios we may use it in, but I have seen many examples on
the web where it caches SQL query results.
It's my impression that the examples of memcached where the cache is
set to expire in 10 seconds will work if there is an update somewhere
else, say that part of what you are saving is data and the data is
upated someplace else where a new record is added to the database. A
page that is rendered within the 10 seconds may not show the new data,
but it's ok because after 11 seconds, any rendering will reflect the
new data. However, It occured to me that if a record was deleted and
then a page was rendered 5 seconds later that showed the old record.
If it was say on a blog and someone tried to update a comment based on
the old record, there will be a problem because now it is gone. This
seems to imply in some cases you can let the old pages expire, in
others you may have to expire them yourself which is more complex.
Ideally you might like to find as many cases that favor the other
approach.

Memcached seems like the best general solution to caching that I have
come across in that it is very low level. In some cases it may be
overkill and be slightly slower for moderate caching than other
approaches, but it is probably more extendable to the case where you
experience a moderate amount of traffic initially which then grows
into greatly increased traffic. You may have to monitor traffic
patterns and make changes, but your general caching archetecture may
not change. Some other caching schemes seem high level, but if there
is a bug or you create a problem by customizing the open source code
of some product or using various plugins with Wordpress, you could
break some of the other caching schemes such as the caching plugin
that wordpress has.