On Sep 5, 2010, at 8:49 PM, ithkuil 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. >
Your question is a good one. Just my quick opinion: It is obvious that there is a lot of demand for sharding-like features. The interwebs have been ablaze with the news of BigCouch. I haven't had a chance to play with it or take more than a cursory glance at the code, but let's assume for the sake of argument that it is a top notch implementation of horizontal scaling for CouchDB. CouchDB wants to fit a wide array of deployment scenarios, from BigCouch to TinyCouch. If including the sharding functionality does not have a negative effect on the ability to run Couch simply on desktops, mobile phones, and the like, then there'd be no reason (other than the coding effort) not to merge it to trunk. However, one must assume that with features comes complexity. For people who don't need BigCouch scale (I assume 90% of users) the additional complexity is only a cost, not a benefit. For me, the question (assuming top-notch code quality) comes down to: how simple would it be to make BigCouch a build or run-time configuration option? Does adding BigCouch to CouchDB increase the install size and memory usage on mobile phones? Can it be added in a way that does not present an increase in install size and administrative complexity for most users? On the question of code quality - I can'y say much without reviewing it, but I'll say that complexity always has a cost. In the case of BigCouch, it will take time and work to know exactly how it's behavior compares to regular Couch. It could be that it is 100% as reliable, and introduces no surprises for users. Or it could be that there are subtle issues that won't be found without wider use. My guess is that CouchDB will ship with something like BigCouch in a future release. I think it is healthier for the project if there is 1 code line, not a separate fork for large scale deployments. However, I'm not sure how much work will need to be done to ensure that merging BigCouch won't add complexity for the majority of users who aren't storing multiple TBs of data. Chris > 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.
