NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter



FUSE: All content tagged as FUSE in NoSQL databases and polyglot persistence

redisfs - a Replication-Friendly Filesystem

The notion of a replication-friendly storage system inspired me to build a filesystem around it, using the FUSE system.

Masterless peer-to-peer sounds better than master-slave replication. Just check the other NoSQL based FUSE enabled filesystems.

The usage scenario suggested by Salvatore Sanfilippo is more conceivable:

My best guess is a ramdisk-speed-alike filesystem that is partially persistent

Original title and link: redisfs - a Replication-Friendly Filesystem (NoSQL databases © myNoSQL)


CouchDB as FS with couch-fuse

Adding CouchDB with ☞ couch-fuse to the list of NoSQL databases exposing a FS interface: Riak, Cassandra, Project Voldemort.

Original title and link: CouchDB as FS with couch-fuse (NoSQL databases © myNoSQL)

Redis-based Replication-friendly Filesystem

A new project to the list of the filesystem interfaces on top of NoSQL stores:

So with a little creative thought you end up with a filesystem which is entirely stored in Redis. At this point you’re thinking “Oooh shiny. Fast and shiny”. But then you think “Redis has built in replication support…”

Meanwhile, Redis creator is trying to put a Redis API on top of a filesystem.


Filesystem Interfaces to NoSQL Solutions

Sounds like it is becoming a trend. So far we have:

Jeff Darcy explains why having a filesystem interface to NoSQL storage can make sense:

Voldemort is pretty easy to use, but providing a filesystem interface makes it possible for even “naive” programs that know nothing about Voldemort to access data stored there. It also provides things like directories, UNIX-style owners and groups, and byte-level access to arbitrarily large files. Lastly, it handles some common contention/consistency issues in what I hope is a useful way, instead of requiring the application to deal with those issues itself.