I believe this is conceptually similar to what Brisk is doing under CassandraFS (HDFS compliant file system on top of cassandra).
Robert Jackson [1] - https://github.com/riptano/brisk ----- Original Message ----- From: "Sasha Dolgy" <sdo...@gmail.com> To: user@cassandra.apache.org Sent: Thursday, August 25, 2011 12:36:21 PM Subject: Re: Is Cassandra suitable for this use case? You can chunk the files into pieces and store the pieces in Cassandra... Munge all the pieces back together when delivering back to the client... On Aug 25, 2011 6:33 PM, "Ruby Stevenson" < ruby...@gmail.com > wrote: > hi Evgeny > > I appreciate the input. The concern with HDFS is that it has own > share of problems - its name node, which essentially a metadata > server, load all files information into memory (roughly 300 MB per > million files) and its failure handling is far less attractive ... on > top of configuring and maintaining two separate components and two API > for handling data. I am still holding out hopes that there might be > some better way of go about it? > > Best Regards, > > Ruby > > On Thu, Aug 25, 2011 at 11:10 AM, Evgeniy Ryabitskiy > < evgeniy.ryabits...@wikimart.ru > wrote: >> Hi, >> >> If you want to store files with partition/replication, you could use >> Distributed File System(DFS). >> Like http://hadoop.apache.org/hdfs/ >> or any other: >> http://en.wikipedia.org/wiki/Distributed_file_system >> >> Still you could use Cassandra to store any metadata and filepath in DFS. >> >> So: Cassandra + HDFS would be my solution. >> >> Evgeny. >> >>
