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

121–130 of 150 posts

Re: Goodbye, CouchDB

#121

Post by jeltz »

spudlyo wrote: post #103
jeltz wrote: post #82

Earlier quoted context omitted.

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

The key is that PostgreSQL 9.2 will be able to handle a 64 core workload, but current released versions of PG do not. The fact is current versions of PG are unable to use more than 60% CPU on a 24 core machine. Do you know anyone who uses a dev version of an RDBMS in production? http://archives.postgresql.org/message-id/BANLkTimVboKxzGS9B...

I believe that MySQL 5.5 scales to 32 cores but not linearly, while PostgreSQL 9.1 caps at 24 cores. As I said in my last comment: I do not doubt much that MySQL would beat PostgreSQL 9.1, but it wont beat it "handily".

Re: Goodbye, CouchDB

#122

Post by lmm »

autarch wrote: post #117
jmathes wrote: post #107

Earlier quoted context omitted.

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

It's easier to constrain your objects in the same language they're written in. Say I have an object where my constraint is that either fielda is set, or fieldb and fieldc are set, but not both (ignoring for the moment that that's a stupid object to have). I can trivially enforce that in a constructor, but it would take me quite a while to work out how to express that in SQL, if it's even possible.

Re: Goodbye, CouchDB

#123

Post by lusr »

geophile wrote: post #57
JohnBooty wrote: post #6

"No SQL. It’s 2012, and most queries are run from code rather than by a human sitting at a console. Why are we still querying our databases by constructing strings of code in a language most closely related to freaking COBOL, which after being constructed have to be parsed for every single query? SQL in its natural habitat" COBOL? Really? I don't see the COBOL connection at all. SQL is more closely related to relatio…

The level of ignorance revealed by that one short quote is just stunning.

I have to wonder whether the author is one of those people who writes SQL that reads like procedural code, full of IFs and WHILEs/cursors. I can't count how many times I've converted application-layer-equivalent code like that into briefer, more readable set-based SQL equivalents that perform thousands of times faster. (I say this as someone who is quite happily using MongoDB in my current personal project - but who will almost certainly be piping that data into PostgreSQL for offline analysis. Right tool for the right job, as GP says.)

Re: Goodbye, CouchDB

#124

Post by xd »

"guesses wrong about how to perform queries all the time. Experienced MySQL users expect to write a lot of FORCE INDEX clauses."

This is most generally a sign of bad indexing/query construction. I've seen so many databases with dozens of indexs placed on tables (which only had a requirement for a few) because the developers just didn't grasp how they should be setup - which isn't rocket science.

Re: Goodbye, CouchDB

#125

Post by ithkuil »

aphyr wrote: post #109
mpd wrote: post #27

Earlier quoted context omitted.

I investigated using Riak for dealing with our metrics a few months ago, but with the data sizes we are dealing with, even the Riak people told us that Hadoop was likely a better solution. Once you are dealing with more than 500k keys or so, Riak starts to fall over. EDIT: The 500k key limit pertains to mapreduce jobs, not the overall data size.

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.e. something which you could "drop" and that will simply delete a directory with a dozen of files in it (should be quite cheap).

The only thing I can do is to drop the whole riak db, which has the following problems:

1) I have to do it manually on all nodes (stopping the cluster, deleting the files etc)

2) I cannot share a riak cluster between several users/team, so that each user/team can play with a portion of it but there is only a central installtion of the whole cluster. Every application (which I want to be able to drop all the db and recreate it) has to run it's own riak cluster.

Initially I thought that "buckets" were intended to solve this problem, but buckets don't map to a separate storage location, it's just a way to group items. Even listing all buckets present in the db requires scanning all keys and, as the doc says, "Similar to the list keys operation, this requires traversing all keys stored in the cluster and should not be used in production."

Although I've been told that "riak is not designed to do this and that", I'm not sure if these limitations are really technical, or just because the product development effort was targeted at some of the aspects, and these issues could be addressed in a later stage.

Any idea?

Re: Goodbye, CouchDB

#126

Post by j-kidd »

lusr wrote: post #123
geophile wrote: post #57

Earlier quoted context omitted.

The level of ignorance revealed by that one short quote is just stunning.

I have to wonder whether the author is one of those people who writes SQL that reads like procedural code, full of IFs and WHILEs/cursors. I can't count how many times I've converted application-layer-equivalent code like that into briefer, more readable set-based SQL equivalents that perform thousands of times faster. (I say this as someone who is quite happily using MongoDB in my current personal project - but who…

The problem with SQL is that everyone thinks they know SQL.

So, on one hand, you have a group of people who think they know SQL well enough and dismiss it as inadequate. These are people who build schema without foreign key and run queries without JOIN because they "know better".

On the other hand, you have a group of people who think they know SQL well enough and fall back to it whenever possible. They go on to create views on top of views on top of views, create temp tables to hold intermediate values that get discarded right away, format application output with string concatenation in SELECT, add DISTINCT to SELECT whenever in doubt, etc etc.

We have an interview question (for a senior position) to test if the applicant grasps the concept of "EXISTS/IN ()", and thus the concept of set-based SQL. Nobody has got it right yet, though they all can write a ton of SQL.

Re: Goodbye, CouchDB

#127

Post by sreeix »

baudehlo wrote: post #102
mattbriggs wrote: post #94

Earlier quoted context omitted.

"no schemas" means "schema in the application layer". sometimes its nice for the additional flexibility, but its never as reliable.

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

Re: Goodbye, CouchDB

#128

Post by j-kidd »

itaborai83 wrote: post #54
AlisdairO wrote: post #21

Earlier quoted context omitted.

Very true. I'm tempted to argue that SQL's English-like syntax was a mistake, but only because I think it makes people think you don't really need to learn it. It's frustrating to see people trash something when they don't even properly understand it - a lot of the database-related blog posts I've seen make the front page of HN would be shot down if they were similarly misinformed about a language like Javascript. I'…

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.

Well, SQLAlchemy is designed just for that. In the words of the author:

> Like "power steering" for SQL. Doesn't teach you how to drive!

Re: Goodbye, CouchDB

#129

Post by baudehlo »

balloot wrote: post #96
sandfox wrote: post #68

Earlier quoted context omitted.

It does nothing of the sort, node.js is ready for the prime time, just have a look at transloadit, voxer, yammer etc etc. Don't confuse the tool not being ready, with you not being ready to use the tool. Equally, there are plenty of people are making couchdb work for them.

None of those companies have a website as their main property as I do. The one I think of when it comes to using node is Klout, and Klout's performance is absolutely atrocious.

Voxer does 170m https hits/day and 2 billion http hits/day on node.

Re: Goodbye, CouchDB

#130

Post by baudehlo »

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

That's just a limitation of MySQL, not relational databases in general. In Postgres you can do it live in a transaction.
Post reply on HN