Bruce, > The big concern I have about memcache is that because it controls > storage external to the database there is no way to guarantee the cache > is consistent with the database. This is similar to sending email in a > trigger or on commit where you can't be certain you send email always > and only on a commit. Well, some things ... ON COMMIT triggers, or messages with NOTIFY, would improve the accuracy by cutting down on cached aborted transactions. However, caching is of necessity imperfect. Caching is a trade-off; greater access speed vs. perfect consistency (and any durability). There are cases where the access speed is more important than the consistency (or the durability). The answer is to use memcached judiciously and be prepared to account for minor inconsistencies. For that matter, as with other forms of cumulative asynchronous materialized view, it would be advisable to nightly re-build copies of data stored in memcached from scratch during system slow time, assuming that the data in memcached corresponds to a real table. Where memcached does not correspond to a real table (session keys, for example), it is not a concern at all. -- Josh Berkus Aglio Database Solutions San Francisco
