Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye, CouchDB

saucelabs.com

Post reply on HN
Print view View original

71–80 of 150 posts

Re: Goodbye, CouchDB

#71

Post by [deleted] »

cynicalkane wrote: post #65
nirvana wrote: post #64

Earlier quoted context omitted.

That thread shows that all of the particulars of your claims about Riak are actually false. Further it seems you didn't bother to understand how Riak can solve your problem and thus decided that it cannot.

Verbatim, from the mailing list: "If large-scale mapreduce (more than a few hundred thousand keys) is important, or listing keys is critical, you might consider HBase." "Riak can also collapse in horrible ways when asked to list huge numbers of keys. Some people say it just gets slow on their large installations. We've actually seen it hang the cluster altogether. Try it and find out!"

[deleted]

Re: Goodbye, CouchDB

#72

Post by dochtman »

nirvana wrote: post #4

They're doing what works for them and good for them for that. But...I think a LOT of people are really missing out by passing over Riak. Many of the issues they found with CouchDB have been resolved with Riak. I think the sync API for CouchDB is really cool, but Riak has the auto-sharding thing down cold. Riak runs map reduce queries across multiple nodes, so performance and capability can grow as you add nodes. Couc…

I looked at Riak a bit (we use CouchDB and Redis at our startup). It seemed to not scale down as nicely as CouchDB: no Futon, binary API's and a lot of emphasis in the documentation on sharding stuff (where we just run CouchDB on a single server with a backup server where we continuously-replicate to).

Re: Goodbye, CouchDB

#73

Post by nirvana »

cynicalkane wrote: post #65
nirvana wrote: post #64

Earlier quoted context omitted.

That thread shows that all of the particulars of your claims about Riak are actually false. Further it seems you didn't bother to understand how Riak can solve your problem and thus decided that it cannot.

Verbatim, from the mailing list: "If large-scale mapreduce (more than a few hundred thousand keys) is important, or listing keys is critical, you might consider HBase." "Riak can also collapse in horrible ways when asked to list huge numbers of keys. Some people say it just gets slow on their large installations. We've actually seen it hang the cluster altogether. Try it and find out!"

I chose the most polite way to point out his error, and now you are compounding it by attempting to rebut me with quotes that don't actually rebut me if you know what you're doing. Listing all keys is a function meant for debugging, not for running in production. If you're running M/R jobs based on that then you don't know what you're doing. The person you're quoting, in fact, said they were doing MR jobs over billions of keys. Further the person who made that recommendation doesn't work for Basho, and that they said he should consider HBase is not the same as saying that Riak can't do it.

You want to say I'm wrong, make a specific argument. Don't selectively quote things out of context that actually don't rebut my position, as that's profoundly dishonest. It is a way of pretending to rebut someone but without saying anything yourself so you can't be pinned on any statements. It is disingenuous.

I'm really tired of having to rebut these argument-from-ignorance "rebuttals" here on HN.

Re: Goodbye, CouchDB

#74

Post by nirvana »

mpd wrote: post #43
astrodust wrote: post #31

Earlier quoted context omitted.

That doesn't seem like a very large number. Are you sure?

Yes. I should clarify that I meant 500k keys used in a single m/r job. We needed to be able to run m/r over roughly 200 million keys at the time.

And it turns out you are misrepresenting the situation completely. You can run M/R over key sets in the billions of keys. It sounds like you've not organized your data at all.

You're bashing a product here based on your lack of knowledge, not the products lack of capabilities.

Re: Goodbye, CouchDB

#75

Post by cynicalkane »

nirvana wrote: post #73
cynicalkane wrote: post #65

Earlier quoted context omitted.

Verbatim, from the mailing list: "If large-scale mapreduce (more than a few hundred thousand keys) is important, or listing keys is critical, you might consider HBase." "Riak can also collapse in horrible ways when asked to list huge numbers of keys. Some people say it just gets slow on their large installations. We've actually seen it hang the cluster altogether. Try it and find out!"

I chose the most polite way to point out his error, and now you are compounding it by attempting to rebut me with quotes that don't actually rebut me if you know what you're doing. Listing all keys is a function meant for debugging, not for running in production. If you're running M/R jobs based on that then you don't know what you're doing. The person you're quoting, in fact, said they were doing MR jobs over billio…

"The person you're quoting, in fact, said they were doing MR jobs over billions of keys"

Ctrl-F billions and found one match in the post I was quoting. No other reference to very large MR jobs in the post quoted.

"At Showyou, we're also building a custom backend called Mecha which integrates Riak and SOLR, specifically for this kind of analytics over billions of keys. We haven't packaged it for open-source release yet"

So the OP is supposed to use an unreleased experimental custom backend to do his big mapreduce jobs?

Re: Goodbye, CouchDB

#76

Post by baconner »

johnbender wrote: post #67

"No schemas. This was wonderful. What are schemas even for? They just make things hard to change for no reason." While they do mention the need to enforce constraints on your data, it's comments like these that make me wish all application developers were required to work as a DBA for a few months. A properly normalized and "constrained" database prevents data loss from stupid mistakes.

Seriously, after that line I gave up on reading the rest. There's plenty to be said about schema vs no schema but its pretty ignorant to just dismiss the entire concept out of hand.

Guess what - in lots of applications data integrity is more important than developer convenience.

Re: Goodbye, CouchDB

#77

Post by [deleted] »

johnbender wrote: post #67

"No schemas. This was wonderful. What are schemas even for? They just make things hard to change for no reason." While they do mention the need to enforce constraints on your data, it's comments like these that make me wish all application developers were required to work as a DBA for a few months. A properly normalized and "constrained" database prevents data loss from stupid mistakes.

[deleted]

Re: Goodbye, CouchDB

#78

Post by NDizzle »

Sounds like he has Lotus Domino-like problems in a product that closely resembles Domino.

Yet in the same page makes fun of SQL for being old and busted? I don't get it.

Re: Goodbye, CouchDB

#79

Post by papsosouid »

spudlyo wrote: post #66
JoachimSchipper wrote: post #62

Earlier quoted context omitted.

I don't like MySQL either, but they're basically using it as a networked hash table. It's not so bad that it can't do that .

This is InnoDB's sweet spot really -- a mostly read-only in memory data set where the lookups are done primarily by PK. MySQL 5.5 can scale this kind of workload to 32 cores. I'm pretty sure given this kind of workload MySQL will outperform PostgreSQL handily.

Why do you say this like it is impressive? Postgresql will scale to 32 cores with a real workload, and has done so for a few years. Mysql performance still tanks at 8 cores. It is very unlikely that mysql will be able to match postgresql for this workload, much less outperform it "handily".

Re: Goodbye, CouchDB

#80

Post by baconner »

sah wrote: post #70
fusiongyro wrote: post #52

> What are schemas even for? They just make things hard to change for no reason. This attitude right here is why the RDBMS old guard despises NoSQL. Willful ignorance should not be celebrated.

"If you don't like it, it must be because you haven't taken the time to understand it" is cognitive poison. What evidence will convince you that someone has understood well enough to judge that something doesn't make sense? I've spent many years using schemas, and I know well how they work and what they achieve. I'm saying they're a lousy tradeoff.

You may well understand what they are and have a well thought out nuanced opinion, but the quote shows none of that. It sounds like an out of hand dismissal of the whole concept of schema which would be pretty ignorant.

*edit I misspelled ignorant... irony alert

Post reply on HN