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

81–90 of 150 posts

Re: Goodbye, CouchDB

#81

Post by dmpk2k »

nirvana wrote: post #74
mpd wrote: post #43

Earlier quoted context omitted.

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.

Based on what I've seen for some internal things, that's one claim I'd like to see support for. m/r on Riak has been an unmitigated disaster here for anything beyond incredibly trivial working sets.

Re: Goodbye, CouchDB

#82

Post by jeltz »

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.

And PostgreSQL 9.2 will be able to scale this workload linearly to 64 cores. So while MySQL may or may not win it will certainly not "outperform PostgreSQL handily".

http://rhaas.blogspot.se/2012/04/did-i-say-32-cores-how-abou...

Re: Goodbye, CouchDB

#83

Post by fusiongyro »

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.

I'm attacking what you actually said in the article. You're attacking what your own statement of what you think I believe.

Engineering choices are always tradeoffs. If they're founded on ignorance, they're bad choices--always. Your article is trying too hard to be cute and funny and comes across as ignorant. I assert that promoting uninformed decision-making is both intellectually dishonest and constitutes a much truer form of "cognitive poisoning."

Re: Goodbye, CouchDB

#84

Post by raylu »

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.

There's quite a big difference between "no reason" and "lousy tradeoff."

Re: Goodbye, CouchDB

#85

Post by sah »

baconner wrote: post #80
sah wrote: post #70

Earlier quoted context omitted.

"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

The quoted statement was hyperbole. I followed it with as much nuance as I felt it made sense to get into in the broader context of the article.

Re: Goodbye, CouchDB

#86

Post by [deleted] »

raylu wrote: post #84
sah wrote: post #70

Earlier quoted context omitted.

"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.

There's quite a big difference between "no reason" and "lousy tradeoff."

[deleted]

Re: Goodbye, CouchDB

#87

Post by pixelcort »

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…

One of the nice features of CouchDB is that the views are incrementally updated, ideal if you have a large dataset that changes frequently with little changes and you want frequently get the most up to date transformed data.

Looking into Riak, I am under the impression there is some caching done on parts of their map reduce system, but I couldn't really find a lot of advice on the performance characteristics of frequently running a map reduce over a large, slowly-changing dataset.

Does anyone else have experience using Riak for this kind of thing?

Re: Goodbye, CouchDB

#88

Post by dmpk2k »

balloot wrote: post #26

This article explains why I am using MySQL as the DB backend for a site I am currently building. It also explains why I am not using Node.js. New technologies are fun to play with, but they get decidedly less fun when your site starts getting traffic and you realize that your new toy isn't ready for prime time.

It's important to be conservative in the right places. Data storage is one of those places: data is the lifeblood of most businesses, and once it goes bad there's often no way of making it good again. Making sure it's correct and remains correct is critical.

Programs, by comparison, are a lot more flexible here, unless you're in the financial/health/auto/aero industries.

As an aside, where I work we use a lot of node. It works.

Re: Goodbye, CouchDB

#89

Post by SkyMarshal »

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.

Also, they should be forced to read Fabian Pascal's rants about the end of Western Civilization, aggressive ignorance, and lack of understanding of the Relational Model.

http://www.dbdebunk.com/

Re: Goodbye, CouchDB

#90

Post by georgefox »

oinksoft wrote: post #16
sah wrote: post #8

Earlier quoted context omitted.

The connection I see is the attempt to make the syntax English-like. Expressions like "SELECT * FROM users" remind me of COBOL's "ADD X TO Y".

How is that different from for foo in bar ubiquitous in modern programming languages?

Capital letters.
Post reply on HN