Yeah, I was thinking - gluster as a domain-specific-database PLATFORM, rather than just a store for some other db that already indexes, hashes, and shards. Where - you define the CAP tradeoffs in translator stack using glupy or something like that. On Wed, May 1, 2013 at 2:26 PM, Jeff Darcy <jdarcy at redhat.com> wrote: > On 05/01/2013 01:50 PM, Jay Vyas wrote: > > There has been chatter about "X on gluster", where x=mongo, riak,... > > > > Im wondering - is there a "most popular" or most well tested > > transactional datastore that runs/leverages gluster ? > > > > Or is the idea of running a transactional nosql tool on gluster still > > mostly a fun/cool/interesting thought experiment? > > I follow developments in the NoSQL world pretty closely, and count many > people in that space as my friends. This idea comes up often, but > nobody really pursues it much because what they do and what we do is > already so similar. The consistent hashing we use in DHT is clearly of > the same general sort as that used in Cassandra, Riak, or Voldemort. > Some of the discussions we've had about various forms of replication and > different consistency models clearly relate well to those same concepts > in MongoDB or Couchbase. If we're using the same algorithms for things > like distribution and replication already, why put one on top of the > other? Putting Cassandra on top of GlusterFS would be too much like > putting Cassandra on top of itself. > > That said, there are a couple of related ideas that are somewhat > interesting. Most have to do with splicing pieces of these related > technologies together instead of layering them. What if we could layer > our front end (full POSIX via FUSE plus SMB/NFS support) on top of their > back end? What if we could put their API on top of our back end with a > specialized translator or libgfapi, much as we're doing for Swift and > Hadoop? There are plenty of possibilities like that to explore. > -- Jay Vyas http://jayunit100.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130501/45124ab8/attachment.html>
