Goodbye, CouchDB • Hacker News Board

Re: Goodbye, CouchDB

#141

Post by spudlyo » Fri, May 11, 2012, 5:19 PM UTC

papsosouid wrote: post #139

spudlyo wrote: post #104

Earlier quoted context omitted.

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…

Your MySQL example isn't exactly relevant. It was in 2007, yet you said "MySQL still tanks at 8 cores". Furthermore it was on FreeBSD, with a flawed libpthread.

In terms of "real" workloads, I'm not going to bother getting into it, as this is quickly devolving in to a true Scotsman argument.

Instead of arguing pointlessly about it, maybe our energy would be better spent publishing some benchmarks.

Re: Goodbye, CouchDB

#142

Post by [deleted] » Fri, May 11, 2012, 5:19 PM UTC

papsosouid wrote: post #139

spudlyo wrote: post #104

Earlier quoted context omitted.

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…

[deleted]

Re: Goodbye, CouchDB

#143

Post by [deleted] » Fri, May 11, 2012, 6:56 PM UTC

JohnBooty wrote: post #44

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

I still don't see the similarity. Just about any modern language is full of English keywords - for, while, unless, function, etc. Unlike COBOL (which I admit to not being very familiar with) SQL uses standard mathematical symbols as operators whenever possible... + instead of "ADD" etc.

[deleted]

Re: Goodbye, CouchDB

#145

Post by empthought » Fri, May 11, 2012, 8:14 PM UTC

josephkern wrote: post #5

As a systems guy, I appreciate stories about developers learning that systems are complicated, and the latest and greatest technology is often not as stable or optimized as hoped. Although, I do have high hopes for Key:Value store data repositories. TANSTAAFL.

Key-value stores like dbm since the 1980s? You're not exactly going out on a limb with those high hopes. :)

Re: Goodbye, CouchDB

#146

Post by autarch » Fri, May 11, 2012, 10:49 PM UTC

lmm wrote: post #122

autarch wrote: post #117

Earlier quoted context omitted.

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

I think this reflects more on you than on SQL.

This is fairly trivial to express as a table-level constraint. I've done very similar things in Postgres. I have no idea if you can do this in MySQL, but it's quite crippled.

Re: Goodbye, CouchDB

#147

Post by Roboprog » Sat, May 12, 2012, 6:15 AM UTC

Roboprog wrote: post #34

To summarize some of the other (upvoted) comments on this cringe-worthy article: Output to any external system must be encoded to prevent fill-in-the-blank injection, if it uses a language vs a string API-only approach. Used prepared statements. SQL is not COBOL. Sets != ISAM. You can store arbitrary data (XML, JSON) in BLOBS/CLOBS in an RDBMS. Denormalization is frowned upon, but not forbidden. PostgreSQL is arguabl…

that should have been "strong API" (not string)

Re: Goodbye, CouchDB

#148

Post by mh- » Sat, May 12, 2012, 7:03 PM UTC

ithkuil wrote: post #131

sk5t wrote: post #105

Earlier quoted context omitted.

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 ?

that's probably already reserved by some new fad where the notion of objects is considered absurd.

Re: Goodbye, CouchDB

#149

Post by ithkuil » Mon, May 14, 2012, 9:47 AM UTC

aphyr wrote: post #138

ithkuil wrote: post #125

Earlier quoted context omitted.

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 fol…

Thank you for your answer. The problems I see with (a) from the top of my head are:

1. Even if it's easy, somebody has to do that. 2. Setting up all the monitoring etc for each instance 3. Running more than one riak daemon on the same machine means that the riak daemon is unaware of the IO operations performed by the other one, hence IO throughput could suffer. This means that in practice you would need to mount separate disk heads (and we are back to 1.) 4. Each riak instance will require some RAM as well, so memory has to be allocated and there is the risk that's over-allocated. 5. Port allocation. I fear it would end up with smth like: "just keep a internal wiki page where each 'db space' is mapped to a port number"

Well, the problem with (b) is of course that I don't have time to do that. For now we stick to cassandra, but Riak is so nice in many aspects that I really hope that at some point, as the product matures, more resources can be invested in aspects which are not currently perceived as "selling points" for riak, but are important for some scenarios and not technically impossible.

Re: Goodbye, CouchDB

#150

Post by aphyr » Mon, May 14, 2012, 6:18 PM UTC

ithkuil wrote: post #149

aphyr wrote: post #138

Earlier quoted context omitted.

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 fol…

Thank you for your answer. The problems I see with (a) from the top of my head are: 1. Even if it's easy, somebody has to do that. 2. Setting up all the monitoring etc for each instance 3. Running more than one riak daemon on the same machine means that the riak daemon is unaware of the IO operations performed by the other one, hence IO throughput could suffer. This means that in practice you would need to mount sepa…

Yeah, if you're using Cassandra and the GC/rebalancing issues aren't affecting you, you're probably fine sticking with it. Both are Dynamo-structured, so your consistency/failover model advantages are similar.