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

21–30 of 150 posts

Re: Goodbye, CouchDB

#21

Post by AlisdairO »

scott_s wrote: post #10
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".

Which is a completely superficial connection with no relationship to the actual semantics.

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'm not by any means saying that the NoSQL movement as a whole is a fad - there's good motivations behind some of these products - but a lot of people who are just ignorant also seem to have hopped onto the bandwagon.

Re: Goodbye, CouchDB

#22

Post by rdtsc »

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.

However as a developer guy I am glad they picked a technology that let them make quick prototyping progress and started shipping a product.

Remember only successful companies have to worry about scaling. Un(/not yet)-successful company have to worry about shipping first, then scaling. So perhaps Saucelabs reached that milestone, and they simply have outgrown the original technology that helped them ship.

Who knows, maybe if they had spent time re-implementing a REST interface on top of MySQL or re-implementing Futon for doing debugging, we might not even have heard about Saucelabs these days.

Re: Goodbye, CouchDB

#23

Post by sah »

balac wrote: post #19

How do you go about searching the DB if everything is stored as a JSON object? Are you using an index like solr/sphinx instead of doing any searches directly in mysql?

We keep things we might need to search in regular columns (typically with indexes). The JSON object is just a way to add extra data to rows, which we can fetch and deal with on the app side. That works fine for a lot of things, and we're hoping it will give us some flexibility around when we need to do schema migrations in some cases.

Re: Goodbye, CouchDB

#24

Post by trimbo »

yxhuvud wrote: post #2

What really don't understand is why they chose mysql over postgresql - postgres already have hstore as a column type to store schemaless data. This includes support for indexes on the field.

Except they didn't choose mysql -- they chose Percona. Bonus of going with Percona is that in the process you get a fantastic company to back you up.

Re: Goodbye, CouchDB

#25

Post by Androsynth »

I've been using CouchDB for the past six months for the internal product-CMS for my business. Its got a great feature set for what I am using it for. MVCC architecture, master-master replication and stored views make it a natural fit as a backend for internal tools. The benefits actually grow as you get more desginers/artists etc working together; each on their own DB.

It seems like all the problems he has are with scaling. I can't comment on that, but I would whole-heartedly recommend it for internal tooling.

Re: Goodbye, CouchDB

#26

Post by balloot »

This article explains why I am using MySQL as the DB backend for a site I am currently building. It also explains why I am not using Node.js. New technologies are fun to play with, but they get decidedly less fun when your site starts getting traffic and you realize that your new toy isn't ready for prime time.

Re: Goodbye, CouchDB

#27

Post by mpd »

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

Re: Goodbye, CouchDB

#28

Post by bsg75 »

DennisP wrote: post #9

"constructing strings of code...which after being constructed have to be parsed for every single query?" I don't know about MySQL, but my database caches compiled queries. "Things like SQL injection attacks simply should not exist." They don't exist, if you don't construct SQL queries by concatenating strings and variables. Meanwhile, all the cool kids are talking about getting rid of procedural code in favor of decl…

The article sounds like they will be trading one set of problems for another, if they implement SQL on any RDBMS using those techniques.

Re: Goodbye, CouchDB

#29

Post by scott_s »

AlisdairO wrote: post #21
scott_s wrote: post #10

Earlier quoted context omitted.

Which is a completely superficial connection with no relationship to the actual semantics.

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

That was an issue I had with the post: how can "non-relational" be a good thing about CouchDB? If you have relational data, then there's an entire theory (relational algebra) behind ways to interact with it that have clearly defined semantics. I can see that one may decide they don't need that, but I don't see how it's absence can be a good thing. Being non-relational frees CouchDB to provide different kinds of capabilities, but it's those capabilities that are a good thing, not the lack of being relational itself.

Rather, I think the author has confused "relational" with a lot of other properties of relational databased management systems - such as transactions and data integrity guarantees.

Post reply on HN