On 04/15/2011 07:04 AM, Sean Copenhaver wrote:
CouchDB tries to make sure everything you do allows it to continue to scale
with good performance. So all the database functions are pretty much
isolated and can have no side effects. Easy example of the benefits of this
is the incremental map and reduce. I would be curious to know how MongoDB's
performance goes once you use a dynamic query on a data set that does not
fit into memory.
Mongo sometimes crashing during development (and then, reading other
comments on the web) was why I thought Couch was worth exploring myself
- and in my limited experiments, Couch never had a hiccup. And yes,
the REST api is really nice (cries out for a cool Sammy client, Node
backend design) and makes Rails or LAMP seem so outdated. My tests
never scaled it up big enough to compare performance at huge data levels
and so far, haven't run into that problem with Mongo.
But I found the Couch built-in Auth process limiting and confusing and
then became bogged down trying to get good map-reduce queries, and then
didn't really get the node-backend concept working - I simply had to
cut the time bleeding. Whatever documentation, forum queries, etc I
found seems split between server and couchapps - I found this really
confusing. Couchapp is nice, just not something on our radar.
btw - I view Futon or Mongo command line as simply nice ways for
developers to either see, check, or debug something and not a good
systematic way to manage - scripts are much more trackable. Mongo's
command line is nice and I found simpler than using a GUI (again YMMV).
So for me, it was a decision of not enough time and budget for us to
play around with Couch and instead, get things out with Mongo and hope
any stability issues work themselves out. YMMV. And I post this with
the hope that someone who has figured out some of these issues using
Couch gets inspired to write up some good blogs/posts/gists (or we can
get enough development funds to work out issues ourselves) to enable us
using Couch more in the future.
Meanwhile, I really, really like the JSON / NoSQL approach that both
Couch and Mongo offer over the traditional SQL world.
I will say that you have to mix the book and the wiki at the least to get a
good picture of everything.
Also for time to market that's really going to depend on how you need to use
the database. MongoDB could also be slower to market then PostgreSQL if I
picked it for the wrong reasons.
CouchDB running as your web server, database, and middle tier is crazy
awesome. Your mileage will vary, but thanks to it's simple API over HTTP
and the availability of the _changes API you have many options available to
you.
Now I do not have a lot of exposure to MongoDB (mostly just read about it a
year ago). I would be interested in it's advantages over CouchDB.
On Fri, Apr 15, 2011 at 3:24 AM, Dirkjan Ochtman<[email protected]> wrote:
On Fri, Apr 15, 2011 at 06:03, Kinley Dorji<[email protected]> wrote:
@John Taber: I agree on one point that I know of - MongoDB has a very
accessible database shell.
For example, entering something like demonstrates the full query
support it has over all fields, not just the keyed field:
db.things.find({name:"mongo"}).forEach(printjson);
That kind of support does make it engaging for new users. Here, like
in some of the other areas you mentioned, CouchDB has a steeper curve.
I suppose you've seen Futon? Seems like a rather accessible UI to me.
Cheers,
Dirkjan