in reply to Re: The State of Parallel Computing in perl 2007?
in thread The State of Parallel Computing in perl 2007?

You use memcached as a database? Not a good idea. Use a database for that. Memcached doesn't consider it a problem to drop your data silently if it runs out of free RAM. That's typical for a cache.
  • Comment on Re^2: The State of Parallel Computing in perl 2007?

Replies are listed 'Best First'.
Re^3: The State of Parallel Computing in perl 2007?
by toma (Vicar) on Jan 24, 2007 at 09:31 UTC
    No, I don't think I mentioned using memcached as a database. Memcached allows me to use multiple machines to cache data in a transparent manner. It allows me to use more, cheaper machines rather than one big expensive machine. I have heard people describe this tactic as "build out, not up."

    A common use case is to cache the results of an SQL query. I use the query as the cache key and the value is the result set from the query. I check the cache to see if the dataset is there. If it is, I get it from the cache. If it isn't, I run the SQL and put the results in the cache. This provides me with a huge speedup.

    If the data in the database gets updated, I flush the cache and start again. This is not a problem for parts of my application, so those are the parts where I use memcached. Instead of storing lot of data in a perl data structure in mod_perl program and counting on the copy-on-write mechanism to save RAM, I use memcached.

    It should work perfectly the first time! - toma
      Sorry, when you said "I use memcached to get more than one computer into the act" I took that to mean you were using it as your way of sharing data between machines, rather than using a database. The usage you described here makes perfect sense.
Re^3: The State of Parallel Computing in perl 2007?
by jettero (Monsignor) on Jan 25, 2007 at 22:14 UTC

    memcached is just about the coolest thing ever btw. It's on the top of my list of things to learn next. UPDATE: oops, wrong parent. Eh.

    -Paul