On Jun 4, 12:25 pm, vishal garg <vishal17g...@gmail.com> wrote: > Thanks for the solution. But I was looking for something more > efficient. Suppose you have an object which you need very frequently, > so you store it into memcached. But that object may change, so you may > need to update. Now there are two possible approaches: > > 1)You update the database accordingly and store the newly formed > object in the memcached.//I think this has been suggested > > 2)You update the object in the cache and leave the database untouched. > But here you update the database whenever the object is removed from > cache incase the object changed. //you may require flags here > > The (2) is more efficient to implement which I perceive since the > database is seldom touched. And infact is the core of the dirty bit in > cache of OS as I mentioned before. > I rephrase my question to - is there any way we can set flags to the > key:value pair which can be detected by the memcached when it removes > data from memory? Please reply incase you find something related.
If you update the cache, but not the primary store, you lose data. Memcached doesn't know *why* you gave it data and has no way to decide what's important. *or* If you update the cache and have cache operations block on writing data out the other side, you lose absolute predictability of cache behavior. This is exactly what membase does. If you write fast enough, you can't update the underlying store and you hit memory limits and have to slow down (or add nodes to compensate for the increased write volume). You can, of course, write another engine that fits your semantics better, but the core engine is designed to add speed to unobtrusively add speed to something that's already working. At the point where you need reliability of the data you're storing in it, you're doing something else.
