[Gluster-devel] Proposal for GlusterD-2.0
nprasad at idirect.net
Thu Sep 11 16:01:28 UTC 2014
I really hope whatever the outcome and final choice is ... as an end user I hope that Gluster stays as simple to deploy as it is today.
Yes, the peers and volume files would be nice to be in one cloud storage (chicken and egg problem - gluster is a cloud storage but it unable to bootstrap its own stuff into its own cloud infra) and overall aim is to get scalability.
All heavy products with their own servers, large key value stores are fancy tools that take a long time to setup and have their own problems.
From: gluster-users-bounces at gluster.org [mailto:gluster-users-bounces at gluster.org] On Behalf Of Jeff Darcy
Sent: Thursday, September 11, 2014 10:23 AM
To: Balamurugan Arumugam
Cc: Gluster Devel; gluster-users at gluster.org
Subject: Re: [Gluster-users] [Gluster-devel] Proposal for GlusterD-2.0
> For distributed store, I would think of MongoDB which provides
> distributed/replicated/highly available/master read-write/slave
> read-only database. Lets get what community think about SaltStack and/or MongoDB.
I definitely do not think MongoDB is the right tool for this job. I'm not one of those people who just bash MongoDB out of fashion, either. I frequently defend them against such attacks, and I used MongoDB for some work on CloudForms a while ago. However, a full MongoDB setup carries a pretty high operational complexity, to support high scale and rich features . . . which we don't need. This part of our system doesn't need sharding. It doesn't need complex ad-hoc query capability. If we don't need those features, we *certainly* don't need the complexity that comes with them. We need something with the very highest levels of reliability and consistency, with as little complexity as possible to go with that. Even its strongest advocates would probably agree that MongoDB doesn't fit those requirements very well.
Gluster-users mailing list
Gluster-users at gluster.org
More information about the Gluster-devel