The most important thing is to make sure that your application is easy to port, follow normal DI/IOC (Dependency injection/Inversion of control) principles. So code that depends on the cache should not
- Get a reference to the cache themself
- Reference a Dictionary<,> object
Instead, make sure that the code
- Call the cache through an interface, eg IDictionary<,>
- Get the reference to the cache injected
If you are using a DI framework, then when you make the move to memcached, you just change the DI configuration code, and all your components that need the cache will now work with memcached.
And if you found out that one particular memcached .NET component doesn't work well, you can change it easily.
I have never tried it, but what about redis ?
Its homepage says (quoting) :
Redis is a key-value database. It is
similar to memcached but the dataset
is not volatile, and values can be
strings, exactly like in memcached,
but also lists and sets with atomic
operations to push/pop elements.
In order to be very fast but at the
same time persistent the whole dataset
is taken in memory and from time to
time and/or when a number of changes
to the dataset are performed it is
written asynchronously on disk. You
may lost the last few queries that is
acceptable in many applications but it
is as fast as an in memory DB (Redis
supports non-blocking master-slave
replication in order to solve this
problem by redundancy).
It seems to answer some points you talked about, so maybe it might be helpful, in your case?
If you try it, I'm pretty interested in what you find out, btw ;-)
As a side note : if you need to write all this to disk, maybe a cache system is not really what you need... after all, if you are using memcached as a cache, you should be able to re-populate it on-demand, whenever it is necessary -- still, I admit, there might be some performance problems if you whole memcached cluster falls at once...
So, maybe some "more" key/value store oriented software could help? Something like CouchDB, for instance?
It will probably not be as fast as memcached, as data is not store in RAM, but on disk, though...
Best Answer
It would be pretty foolish for any substantial site to go live (in production) on a CTP of a product (edit - good point in the comments - this isn't a hard rule... there are exceptions, for example stackoverflow). Velocity is currently in CTP2, which is good for building out proof-of-concept and planning for product releases, but that's all. Once it is a supported product, I'm sure we will see plenty of usage. Follow the Velocity product team blog (http://blogs.msdn.com/velocity/) for details.
As far as memcached vs Velocity, they have somewhat overlapping but ultimately different purposes. Memcached is not reliable. That is spelled out very clearly in the documentation and by the authors. It is intended to be blazingly fast, cheap to run and simple to administer. Velocity, on the other hand, is much more familiar to the formal enterprise software crowd. It is complex, with a robust API and is better for a more formal data environment.