What happened to CouchDB's popularity? • Hacker News Board

Re: What happened to CouchDB's popularity?

#61

Post by jchrisa » Tue, Nov 01, 2011, 4:11 PM UTC

damncabbage wrote: post #47

parshap wrote: post #43

Earlier quoted context omitted.

> synch is not the killer feature it once was I disagree. Mobile connectivity is going to continue being spotty for the foreseeable future and Couch's "store locally, sync whenever" paradigm is perfect for any application that needs to remain functional when not connected.

Agreed. I'm using CouchDB for a front-of-house ticketing system; the roving units need to sync back to main base (surviving disconnections thanks to spotty wireless). CouchDB is perfect for this. I'm actually pretty worried about CouchDB going away. What's out there that does the equivalent (NoSQL or Relational, I don't care)?

CouchDB won't go away, at least not as long as HTTP and JSON are relevant. If you'd like to see more open source contributions, do what I did and learn the code base, contribute patches and ideas.

Re: What happened to CouchDB's popularity?

#62

Post by latch » Tue, Nov 01, 2011, 4:53 PM UTC

rdtsc wrote: post #58

sqrt17 wrote: post #48

Earlier quoted context omitted.

It's also that CouchDB is (or at least used to be) rather slow compared to MongoDB. 10gen sure has done a lot to keep MongoDB growing despite many people having their homework (or essential customer data, or...) eaten by MongoDB; so part of it probably is attributable to better publicity.

There is a reason they are fast. They didn't use to have durability. Think about that -- it is a database product that until the last version didn't have durability and its writes were not acknowledged with a response. If you store you data in memory and write it to disk sometimes, you can write very fast.

and now, since 2 versions, they have journaling, and offer a huge amount of flexibility over write durability available:

- fire and forget

- write with integrity check (safe)

- write with journal commit

- write with data file commit

- write with replication to X nodes

And you can combine the last 4 in any way you like.

They did a pretty good job turning a downside into a significant advantage (yes, fire and forget is a significant advantage in a lot of cases).

Re: What happened to CouchDB's popularity?

#63

Post by latch » Tue, Nov 01, 2011, 5:03 PM UTC

rdtsc wrote: post #41

johnbender wrote: post #16

Having worked with neither of them my perception is that MongoDB has "better performance". While I would never rely on that for making decisions about which to use, I'm sure that has some real consequences, particularly where search popularity is concerned.

You just don't know about the other side of the coin -- no durability to start with. You'll be flying fast, until one day you realize your data is corrupted. Not saying it is bad thing to optimize for speed, it is just a bit dishonest to downplay the negative effects especially after calling a product a DATA-base. http://nosql.mypopescu.com/post/392868405/mongodb-durability... http://blog.boxedice.com/2010/02/28/note…

Seriously, now you are just spreading FUD. You even said a few posts up that there WAS durability.

With respect to the speed of writes, MongoDB has, at least, three other things going for it [that CouchdB doesn't]: 1) the journal file is append only, 2) updates can often be done in-place, 3) a binary protocol.

Re: What happened to CouchDB's popularity?

#64

Post by latch » Tue, Nov 01, 2011, 5:06 PM UTC

rdtsc wrote: post #59

mumrah wrote: post #45

If we're comparing CouchDB's popularity to that of MongoDB's, it's simple - 10gen. 10gen has done a very good job generating lots of hype around their product. I believe they have people dedicated to this task (aka, evangelists). CouchBase on the other hand, has not done so well at this.

And that hype turned me off. I have an allergic reaction to it. Especially when they were caught acknowledging they didn't have default durability for their writes. Then suddenly they removed their benchmarks from their site and made some comment about how data will be lost anyway, so it is not a big deal.

  caught acknowledging

instant classic.

Re: What happened to CouchDB's popularity?

#65

Post by rdtsc » Tue, Nov 01, 2011, 5:17 PM UTC

latch wrote: post #64

rdtsc wrote: post #59

Earlier quoted context omitted.

And that hype turned me off. I have an allergic reaction to it. Especially when they were caught acknowledging they didn't have default durability for their writes. Then suddenly they removed their benchmarks from their site and made some comment about how data will be lost anyway, so it is not a big deal.

caught acknowledging instant classic.

> caught acknowledging instant classic.

Those that can, comment, those that have nothing to say, make fun of those who speak English as a third language.

http://blog.mongodb.org/post/381927266/what-about-durability

Feb, 2010

"We get lots of questions about why MongoDB doesn’t have full single server durability, ...there are some very practical reasons why we think single server durability is overvalued"

http://www.mongodb.org/pages/viewpage.action?pageId=2752708&...

May, 2010

"MongoDB does not publish any official benchmarks...."

EDIT: Added link to blogs, quoted parent, in case gets removed

Re: What happened to CouchDB's popularity?

#66

Post by rdtsc » Tue, Nov 01, 2011, 5:20 PM UTC

latch wrote: post #62

rdtsc wrote: post #58

Earlier quoted context omitted.

There is a reason they are fast. They didn't use to have durability. Think about that -- it is a database product that until the last version didn't have durability and its writes were not acknowledged with a response. If you store you data in memory and write it to disk sometimes, you can write very fast.

and now, since 2 versions, they have journaling, and offer a huge amount of flexibility over write durability available: - fire and forget - write with integrity check (safe) - write with journal commit - write with data file commit - write with replication to X nodes And you can combine the last 4 in any way you like. They did a pretty good job turning a downside into a significant advantage (yes, fire and forget is…

> and now, since 2 versions

So 20-30 days ago only?

> yes, fire and forget is a significant advantage in a lot of cases

Sorry, but not as a default option in a DATAbase product.

Re: What happened to CouchDB's popularity?

#67

Post by [deleted] » Tue, Nov 01, 2011, 5:36 PM UTC

rdtsc wrote: post #66

latch wrote: post #62

Earlier quoted context omitted.

and now, since 2 versions, they have journaling, and offer a huge amount of flexibility over write durability available: - fire and forget - write with integrity check (safe) - write with journal commit - write with data file commit - write with replication to X nodes And you can combine the last 4 in any way you like. They did a pretty good job turning a downside into a significant advantage (yes, fire and forget is…

> and now, since 2 versions So 20-30 days ago only? > yes, fire and forget is a significant advantage in a lot of cases Sorry, but not as a default option in a DATAbase product.

[deleted]

Re: What happened to CouchDB's popularity?

#68

Post by rdtsc » Tue, Nov 01, 2011, 5:36 PM UTC

latch wrote: post #63

rdtsc wrote: post #41

Earlier quoted context omitted.

You just don't know about the other side of the coin -- no durability to start with. You'll be flying fast, until one day you realize your data is corrupted. Not saying it is bad thing to optimize for speed, it is just a bit dishonest to downplay the negative effects especially after calling a product a DATA-base. http://nosql.mypopescu.com/post/392868405/mongodb-durability... http://blog.boxedice.com/2010/02/28/note…

Seriously, now you are just spreading FUD. You even said a few posts up that there WAS durability. With respect to the speed of writes, MongoDB has, at least, three other things going for it [that CouchdB doesn't]: 1) the journal file is append only, 2) updates can often be done in-place, 3) a binary protocol.

> You even said a few posts up that there WAS durability.

When did I say that? Just cut-and-paste my phrase if you are replying to it. I don't remember saying it.

> With respect to the speed of writes, MongoDB has, at least, three other things going for it [that CouchdB doesn't]: 1) the journal file is append only, 2) updates can often be done in-place, 3) a binary protocol.

I never said MongoDB wasn't faster. It is in most situations. I was criticizing their hand-wavy attitude and what I perceived was shady marketing when it came to their trade-off. That turned me off and made me look for another product.

Besides, what exactly do those implementation features mean? CouchDB has an append-only BTRee so it doesn't need journalling:

http://guide.couchdb.org/draft/btree.html

Updates-in place are great but they again are a trade-off. Now you also need a journal.

Binary protocol -- ok. That probably makes a significant difference in some case. I would actually like CouchDB to have a msgpack or protobuf driver.

Not saying MongoDB is worse or better, it just works differently.

Re: What happened to CouchDB's popularity?

#69

Post by stoph » Wed, Nov 02, 2011, 1:36 AM UTC

My issue with CouchDB is the basic approach. Instead of maintaining indexes, the goal of CoachDB is to pre-cache all search functions with the actual result, for all records. This takes a lot of disk space for certain use-cases. This difference makes MongoDB a more attractive choice than CouchDB.

Re: What happened to CouchDB's popularity?

#70

Post by mehwoot » Wed, Nov 02, 2011, 1:46 AM UTC

foxylad wrote: post #17

mehwoot wrote: post #13

Google trends is not the sole decided of popularity. http://www.google.com/trends?q=ruby+on+rails%2C+django&c... Do you really think that ruby on rails has been declining in popularity since 2006?

Quite possibly. The Twitter debacle tainted RoR's reputation (fairly or not), and there is a concern that Ruby might turn out to be a flash in the pan. Django/Python is just as effective, and enterprises feel far more comfortable with Python's depth of support across the board. Google's real fail is the event tags - a grand total of NONE relate to Django the web framework.

I dunno, RoR is so widespread now compared to where it was in 2006. I think, because it is widespread now, people don't have to search for "ruby on rails" because they don't know what it means. You are going to be searching for something more particular now. I guess that's sort of my point of what could be happening with CouchDB (I don't use it... so I have no real idea).