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

111–120 of 150 posts

Re: Goodbye, CouchDB

#111

Post by aphyr »

pixelcort wrote: post #87
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 frequ…

In short, don't. In Riak you would aim to update those views at write time, to minimize the number of reads required.

Re: Goodbye, CouchDB

#112

Post by johnbender »

jmathes wrote: post #107
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.

'A properly normalized and "constrained" database prevents data loss from stupid mistakes.' A properly written application layer also prevents data loss from stupid mistakes. A stupid mistake made while setting up a properly normalized database also causes data loss. You have to be very smart to be able to design a normalized constrained DB well. The fact that only smart people can do it doesn't mean that people who…

"A properly written application layer also prevents data loss"

Agreed but the application layer _generally_ doesn't have the abstractions at a point where it's trivially easy to put these safe guards in place like it is at the database layer.

Also, "stupid mistakes" does not in any way imply that the people who make them are stupid. Nor am I implying that you have to be particularly intelligent to normalize and constrain a database properly. I'm simply lamenting how undervalued a "good schema" can be.

[side note: upvoted your comment :D]

Re: Goodbye, CouchDB

#113

Post by aphyr »

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…

I am the person being quoted. You are correct that keylisting is not suitable for production use. We definitely don't do MR jobs over billions of keys: our huge data queries are powered by Mecha, which uses Solr.

Re: Goodbye, CouchDB

#114

Post by aphyr »

smn wrote: post #15
dgrnbrg wrote: post #13

Earlier quoted context omitted.

Does riak support range queries?

It does on secondary indexes http://wiki.basho.com/Secondary-Indexes.html

I should mention that 2I performance may be a little slow, depending on what kind of indices and queries you need. It's not hard to try it out and benchmark, though.

Re: Goodbye, CouchDB

#115

Post by stephen »

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.

Yeah, I don't get the anti-schema sentiment either. Coincidentally, I just wrote up my thoughts on it yesterday:

http://draconianoverlord.com/2012/05/08/whats-wrong-with-a-s...

Re: Goodbye, CouchDB

#116

Post by stephen »

jmathes wrote: post #107
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.

'A properly normalized and "constrained" database prevents data loss from stupid mistakes.' A properly written application layer also prevents data loss from stupid mistakes. A stupid mistake made while setting up a properly normalized database also causes data loss. You have to be very smart to be able to design a normalized constrained DB well. The fact that only smart people can do it doesn't mean that people who…

> You have to be very smart to be able to design a normalized constrained DB well.

Eh, nit picking, but I think "very smart" is overkill--I think "just smart" people should still be capable of designing normalized constrained schemas.

If they are incapable of doing this, then I don't want them writing any code anyway.

Being capable of doing it and choosing not to is either at least forgivable or completely understandable, depending on the situation.

Re: Goodbye, CouchDB

#117

Post by autarch »

jmathes wrote: post #107
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.

'A properly normalized and "constrained" database prevents data loss from stupid mistakes.' A properly written application layer also prevents data loss from stupid mistakes. A stupid mistake made while setting up a properly normalized database also causes data loss. You have to be very smart to be able to design a normalized constrained DB well. The fact that only smart people can do it doesn't mean that people who…

"You have to be very smart to be able to design a normalized constrained DB well."

But you can be a complete moron and write "[a] properly written application layer [that] prevents data loss from stupid mistakes"?

What's the difference? Writing correct code can be hard. I don't think it's particularly easier to apply all your constraint in app code unless you just don't know about the database backend you're using.

Re: Goodbye, CouchDB

#118

Post by sk5t »

NDizzle wrote: post #78

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.

Notes' main problems are/were the lack of joins and most aggregates, lack of proper transactions, lack of indexes that would permit useful runtime queries, somewhat slow data access layer, and glacially slowly-evolving, ugly-ass UI.

It is also so easy to build on, that people who don't know what they're doing and shouldn't be building any software for redistribution, will do so anyway, and gain just enough success to become extremely annoying. Its IDE is about on par with most other IBM-involved software development exercises, i.e., fairly bad.

Now, all that aside, it is a very powerful, but not generally well-appreciated, system, and is great (fast, cheap, hard to kill) for a large swath of applications that don't require any of the stuff from the first paragraph.

Re: Goodbye, CouchDB

#119

Post by baconner »

jmathes wrote: post #108
baconner wrote: post #76

Earlier quoted context omitted.

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.

It was colorful language, not dismissal out of hand. It can be hard to communicate emotion online, so it's easy to take offense where none was meant. I think that's what happened here.

Definitely agree on communication of emotion, for instance I'm not offended in the least. :) all I'm saying is its hard for me to take someone's opinions on data stores seriously given that quote.

Re: Goodbye, CouchDB

#120

Post by [deleted] »

jmathes wrote: post #108
baconner wrote: post #76

Earlier quoted context omitted.

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.

It was colorful language, not dismissal out of hand. It can be hard to communicate emotion online, so it's easy to take offense where none was meant. I think that's what happened here.

[deleted]
Post reply on HN