Under the covers, BigCouch has separate databases per shard (hit the single-node instance on 5986 to see them), so I think it's closer to Lounge than you think.
I've read the code a little and liked everything I've seen so far. I'm not too sure if using erlang distributed nodes puts an upper limit on a cluster yet. B. On Mon, Sep 6, 2010 at 6:05 AM, Randall Leeds <[email protected]> wrote: > Wee! I like this question. :) > > I've probably been the most active Lounge developer for a little while > now and though I'm not intimately familiar with BigCouch yet I think > I'm pretty clear on its overall architecture and design. I'll try to > highlight some of the differences for you without really selling > either system. > > On simplicity and production use: > > Lounge is "fairly simple" in that it runs outside CouchDB. It is not > simple to set up or maintain. Thankfully, since 0.11 added filtered > replication there is no longer a need to patch CouchDB. If you like > compiling nginx from source and you want to roll some of your own > management scripts then Lounge is a great choice. Meebo skipped the > 0.11 cycle and that's why I haven't been pushing a lot of changes. I > hope to change that in a couple weeks after I get back from Couch Camp > and bring Lounge up to date with 1.0.1. > > BigCouch is, obviously, in production use by Cloudant. Therefore, it's > clearly been battle tested a bit. It has the advantage of having > Dynamo-style R/W/N consistency settings. I've always said that if > someone needed this feature it'd be easy enough to add to the Lounge > and I stand by that. However, either way you will be rolling your own > management scripts since, as I understand it, this is part of the > value add of the commercial Cloudant offering. > > On stability: > > Until I've personally reviewed the changes to the core parts of > CouchDB I won't outright recommend you put your production data in > BigCouch, but I'm 99% sure it'd be fine. You probably won't lose data > but maybe you'll get a few 50x responses. I could probably say the > same about Lounge, though. I'll be playing with BigCouch a bit myself > in the next few weeks and will have a better idea. > > On scalability: > > In short. CouchDB can scale just like Cassandra and there are (at > least two) viable options for doing so. Nothing has out-of-the-box > easy management in place. There will be some operational overhead if > you decide to manage it yourself. If you don't want that, take a > hosted solution like Cloudant. > > If you do not need the scale immediately the best option is to not > worry about it. Like Mr. Miyagi said in Karate Kid 2, "The best way to > avoid a punch is not be there." Set up your single couch instance or > set up two with bidirectional, continuous replication so you have > redundant copies of your production data. If you're worried about > consistency use one of them as a write master and the other as a read > slave/hot standby. You can always migrate later. > > If you still care about the technical differences, read on. > > -------------------------------------------------------------------------- > > I believe BigCouch *does* use filtered replication. Lounge does not, > instead opting for database suffixes to distinguish shards. A database > in BigCouch called "stuff" will be called "stuff" on every node. In > Lounge you will see "stuff0", "stuff1", ... I don't think there's > anything more to say about that. It's a choice, but I do not see it as > a particularly significant one. > > BigCouch has dynamic re-sharding with key ranges much like Cassandra > that can be split as needed. Lounge is almost more like Riak in that > it buckets the whole hashed key space into a fixed number of shards > and then distributes membership of them to nodes. Arguments can be > made for both of these approaches. If you "overshard" enough in Lounge > there shouldn't be much concern about the lack of key-range > splitting/merging. > > BigCouch uses distributed Erlang for internode communication. I don't > *think* replication happens this way, so that really just means the > proxying is faster and you can round-robin all your BigCouch nodes. > Lounge goes directly to the node with the data always through nginx > and this is also very fast. > > The most significant difference is, of course, that BigCouch is > written in Erlang. For the reason I'd predict better longevity for the > project simply because it stands a chance of being included in CouchDB > (in whole or in part). > > Oh. To its credit, Cassandra makes nice use of the JMX console. :) > > If I have said anything false or misleading I encourage anyone to > please chime in. > > -Randall > > On Sun, Sep 5, 2010 at 20:49, ithkuil <[email protected]> wrote: >> >> What advantages does BigCouch have over Lounge? Lounge seems fairly simple >> which is a big plus, but since Cloudant is using BigCouch in their >> commercial product that looks like a bigger plus. >> >> Do either of these solutions take advantage of new features like replication >> filters? >> >> What is the direction of internal CouchDB development in regards to >> "complete" partitioning functionality? Is the need for Lounge or BigCouch >> (for many use cases) really a clue that if I need a completely partitioned >> distributed database I should look at something like Cassandra (do not >> like)? >> >> I'm sorry if you are tired of answering this question. Please consider just >> ignoring it until you are in a really good mood. That could be two weeks >> down the line if you like, or never. Also, I know this could be on the user >> list, but I am asking here because I want to know what CouchDB internal >> developers think of the options and the direction for the future. >> >> Also, here is a tiny virtual representation of me which you can imagine >> stabbing in the eye with a tiny pencil, if that helps: >> >> O >> \|/ >> | >> / \ >> >> -- >> View this message in context: >> http://couchdb-development.1959287.n2.nabble.com/BigCouch-vs-CouchDB-Lounge-vs-Cassandra-tp5501938p5501938.html >> Sent from the CouchDB Development mailing list archive at Nabble.com. >> >
