>>What are other options then << Several. 1. Mogilefs. Stores on filesystem but metadata in database (MySQL or Postgres). Also has redundancy built in. Does not require RAID. No SPOF. But I think it has too many moving parts and requires a few more boxes than cassandra. 2. Ofcourse the good old Blob in databases. But leads to chunking for sizes greater than pagesize. overhead is high and fragmentation is an issue over time. 3. S3. Takes care of redundancy and durability much better than anything. But you are tied to Amazon. Also check their SLAs on uptime. It might or might not meet your needs. 4. MongoDB is pretty good too for large files. But it splits files at 16MB and storage is not atomic for sizes greater than that. It too like MogileFS needs a few more boxes for trackers and metadata.
Each has their pros and cons. I still think there is opportunity to build more simpler storage just for large files with metadata being in a central place. If anyone is aware of other options or customized solutions, please suggest. On Tue, Mar 1, 2011 at 5:36 PM, mcasandra <mohitanch...@gmail.com> wrote: > Why do we think it's good to have files < 64 MB? How did one arrive at this > no.? > > If I understand correctly the problem is with Java Heap space might grow > because of the large files. But doesn't it really depend on the concurrent > requests * size of the response? > > What are other options then? Store it on the filesystem but then that > introduces SPOF. > > -- > View this message in context: > http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Storing-photos-images-docs-etc-tp6078278p6078983.html > Sent from the cassandra-u...@incubator.apache.org mailing list archive at > Nabble.com. >
