 <p>Caching large objects in NoSQL stores is generally not a good idea, because it is expensive in term of memory and network bandwidth. I don't think NoSQL solutions shine when it comes to storing large objects. Redis, memcached, and most other key/value stores are clearly not designed for this.</p> <p>If you want to store large objects in NoSQL products, you need to cut them in small pieces, and store the pieces as independent objects. This is the approach retained by 10gen for gridfs (which is part of the standard MongoDB distribution):</p> <p>See <a href="http://docs.mongodb.org/manual/applications/gridfs/" rel="nofollow">http://docs.mongodb.org/manual/applications/gridfs/</a></p> <p>To store large objects, I would rather look at distributed filesystems such as:</p> <ul> <li><a href="http://ceph.com/" rel="nofollow">Ceph</a></li> <li><a href="http://www.gluster.org/" rel="nofollow">GlusterFS</a></li> <li><a href="http://doc.mapr.com/display/MapR/Architecture+Guide" rel="nofollow">MapR-FS</a></li> </ul> <p>These systems are scalable, highly available, and provide both file and object interfaces (you probably need an object interface). You can also refer to the following SO question to choose a distributed filesystem.</p> <p><a href="http://stackoverflow.com/questions/269179/best-distributed-filesystem-for-commodity-linux-storage-farm">Best distributed filesystem for commodity linux storage farm</a> </p> <p>Up to you to implement a cache on top of these scalable storage solutions.</p>