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

131–140 of 150 posts

Re: Goodbye, CouchDB

#131

Post by ithkuil »

sk5t wrote: post #105
JamisonM wrote: post #97

Earlier quoted context omitted.

I made it to the next one before I gave up: "Relational databases grew up solving problems where data integrity was paramount and availability was not a big concern."

Yow... is there a word for the special kind of bubble we're in now, with the profusion of Javascript and schema-free datastore-lovin' folks whose lack of experience in static typing and relational databases does not--in even the slightest way--constrain them from pronouncing their irrelevance?

NoOb ?

Re: Goodbye, CouchDB

#133

Post by papsosouid »

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 absolutely do not have to be "very smart" to design a correct relational database. There are a very small number of very simple, easy to understand rules. It requires making a small effort to educate yourself on the basics of the relational model, and that's it. No special genius required.

Re: Goodbye, CouchDB

#134

Post by mattbriggs »

sreeix wrote: post #127
baudehlo wrote: post #102

Earlier quoted context omitted.

And not only that, your application becomes littered with: if (data.schema_version === 1) { ... } else if (data.schema_version === 2) { ... } UGH!

But it is better than not having the ability to change the schema when there are more than a few million rows, thanks to the enormous time taken

Schemaless would let you add/remove a field easily. What is hard is if you need to restructure things, which is also probably a more common occurence in a document db then a relational one. If you hit a few million rows, you are in for a world of hurt changing things in any data store

Re: Goodbye, CouchDB

#135

Post by mattbriggs »

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 think the eventual consistency is what narrows riaks use case. Only heard good things about it though

Re: Goodbye, CouchDB

#136

Post by itaborai83 »

DennisP wrote: post #92
itaborai83 wrote: post #54

Earlier quoted context omitted.

You made me think about something. A CoffeeScript like approach to build a saner language that would sit atop SQL would be something definitely worth having. Maybe this could be the start of the "OnSQL" movement. Just my thoughts.

Being able to parameterize table and column names in queries would be a big help.

It could have a sharding aware data definition language and some support for "on-the-fly" data migrations.

Re: Goodbye, CouchDB

#137

Post by chanon »

DennisP wrote: post #93
nirvana wrote: post #51

Earlier quoted context omitted.

Every database is different, but that doesn't mean there are a lot of really unique features. The unique feature of CouchDB is the way it does views, but that doesn't mean you can't' do views (in fact, in my opinion, better) in other databases. Continuous changes feed- you can get this with Riak and more importantly you can get a feed of just the relevant changes. Plus you don't need this in Riak the way you do in Co…

I haven't seen any articles by users, but Couchbase looks pretty interesting: http://www.couchbase.com/couchdb

See http://blog.couchbase.com/how-couchbase-helped-omgpop-break-... .. not directly by a user but still a real world usage story.

Re: Goodbye, CouchDB

#138

Post by aphyr »

ithkuil wrote: post #125
aphyr wrote: post #109

Earlier quoted context omitted.

I feel somewhat responsible for this confusion, as the guy being quoted here... :-( Riak will handle billions of keys just fine. We had, I dunno, a half a billion in a six node bitcask-backed cluster and were only at half capacity. Much much bigger installs exist. The limit I was referring to is for a single mapreduce job; Riak MR just isn't well-suited to operations over millions of keys at a time. It can do it, but…

I have a use case, which I don't know if it's common or not. I want to put millions of items in riak, play with it, and then throw then away. I might want to do that because I'm testing out something, or because it's the result of some periodic batch processing in production, which I want to get by key later. Unfortunately, riak doesn't seem to have the notion of a "db", "keyspace" or whatever you want to call it; i.…

Tough call. If you did want to use Riak for fast bucket-drop, your best bet might be to:

a.) Run multiple clusters--not too difficult. Just give each one a different erlang cookie and run em on subsequent ports.

b.) Take bitcask_backend or leveldb_backend and add drop-bucket functionality. Custom backends are more difficult than running multiple clusters, but certainly not impossible. You could build it on top of fold or split writes up into, say, one leveldb per bucket. Don't recall if the vnode interface has drop-bucket so you might have to write some plumbing alongside Riak. jrecursive has done this in Mecha.

If I were building something like this, I might look first at Cassandra or Hbase, or possibly sharded master-slave postgres.

Re: Goodbye, CouchDB

#139

Post by papsosouid »

spudlyo wrote: post #104
moe wrote: post #95

Earlier quoted context omitted.

The postgres part of the statement is accurate; http://rhaas.blogspot.de/2012/04/did-i-say-32-cores-how-abou...

No, it's not. The referenced article is talking about Postgres 9.2devel. Version 9.2 isn't out yet, and even if it was, it still wouldn't be true due to the clause "and has done so for a few years". The lock manager bottlenecks that stopped PG from using more than 60% of the cpu power on a 24 core box were discovered a little less than a year ago. http://rhaas.blogspot.com/2011/07/read-scaling-out-to-32-cor...

You are making assumptions about one scenario based on limitations encountered in a very different scenario. The problems that occur around 24 cores occur on benchmarks consisting entirely of select statements against a single table. As I said, postgresql has scaled to 32 cores for real workloads for a few years. Real workloads have more than one table.

See here for an example of mysql having problems at only 8 cores (and postgresql destroying mysql's performance): http://www.scribd.com/doc/551889/Introducing-Freebsd-70

Postgresql scaling to 28 cores in 2007: https://docs.google.com/viewer?a=v&q=cache:-ytn3fY_Lr8J:...

Postgresql on 32 core t2000 being able to scale up to 1024 concurrent clients in 2008: http://www.pgcon.org/2008/schedule/attachments/50_46_pgcon20...

Re: Goodbye, CouchDB

#140

Post by JPKab »

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.

It seems like there is a huge amount of ignorance (on the parts of both developers and DBAs) about the fact that NoSQL doesn't necessarily mean "no schema." For whatever reason, the "cool kids" in the Web dev world completely ignore the ugly stepchildren of the NoSQL world, graph databases. Graph databases provide the protections of a schema, but the schema can be altered without massive pain on the parts of developers. Even better, the RDF style graph databases have a W3C standard query language called SPARQL.

Don't get me wrong, I love my RDBMS (MySQL and PostgreSQL) and I also use Mongo and love its extreme simplicity, but I wish more developers understood that schemas exist in places other than RDBMS.

Post reply on HN