Goodbye, CouchDB

Post by spudlyo » Thu, May 10, 2012, 10:03 PM UTC

papsosouid wrote: post #79

spudlyo wrote: post #66

Earlier quoted context omitted.

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.

Why do you say this like it is impressive? Postgresql will scale to 32 cores with a real workload, and has done so for a few years. Mysql performance still tanks at 8 cores. It is very unlikely that mysql will be able to match postgresql for this workload, much less outperform it "handily".

Post by DennisP » Thu, May 10, 2012, 11:57 PM UTC

nirvana wrote: post #51

rdtsc wrote: post #17

Earlier quoted context omitted.

CouchDB has some features that other databases don't have: a continuous changes feed, REST interface, master-to-master replication, a web interface to the data and management (Futon). We need those features (Yes including Futon. It is a feature because it lets us quickly prototype and debug. It makes a black box that you drop your data in transparent). But we not using to for large datasets. We are using it mostly fo…

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…

Post by moe » Fri, May 11, 2012, 12:24 AM UTC

spudlyo wrote: post #91

papsosouid wrote: post #79

Earlier quoted context omitted.

Why do you say this like it is impressive? Postgresql will scale to 32 cores with a real workload, and has done so for a few years. Mysql performance still tanks at 8 cores. It is very unlikely that mysql will be able to match postgresql for this workload, much less outperform it "handily".

Postgresql will scale to 32 cores with a real workload, and has done so for a few years. Mysql performance still tanks at 8 cores. Both of those statements are not accurate, but hey, what's it matter? Without benchmarks we're both talking out our ass anyway.

Post by JamisonM » Fri, May 11, 2012, 12:34 AM UTC

baconner wrote: post #76

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.

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.

Post by scott_s » Fri, May 11, 2012, 12:40 AM UTC

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.