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

51–60 of 150 posts

Re: Goodbye, CouchDB

#51

Post by nirvana »

rdtsc wrote: post #17
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…

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 CouchDB because Riak already has distribution built in.

Master-Master replication as done in CouchDB is inferior to the turely distributed database that Riak is. (Eg: its not replication, it is distributed itself.)

Web interface to data management-- futon was a lead here but there are several tools for Riak that cover these bases in my opinion.

I think CouchDB as a configuration database is an excellent job.

I looked at BigCouch which is taking the Dynamo Ring concept and applying it to CouchDB which is a good solution for couchDB (in fact, they should build it in to the core) ... but that's also what Riak is built from the ground up to be (a dynamo ring.) Cassandra is a different animal and I can never figure out what Couchbase is going to become.

Re: Goodbye, CouchDB

#52

Post by fusiongyro »

> What are schemas even for? They just make things hard to change for no reason.

This attitude right here is why the RDBMS old guard despises NoSQL. Willful ignorance should not be celebrated.

Re: Goodbye, CouchDB

#53

Post by nirvana »

dgrnbrg wrote: post #13
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…

Does riak support range queries?

Yes, it does range queries based on key, if the key follows a defined format.

It also has secondary indexes.

Re: Goodbye, CouchDB

#54

Post by itaborai83 »

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

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.

Re: Goodbye, CouchDB

#55

Post by nirvana »

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?

Your DB should be cognizant of JSON. For instance, JSON records can be converted into key-value combinations that are then indexed.

Re: Goodbye, CouchDB

#56

Post by mpd »

nirvana wrote: post #48
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 think your statement is both out of date and quite broad. Plus you imply that a database would be limited to 500k keys which is silly, when you really mean a map-reduce job. And further, are you really doing MR over your entire dataset, all the time, or would key filtering, ranges or secondary indexes be a better fit? Its easy to do M/R in Riak over only the correct amount of data. Hadoop may have been better for w…

You're welcome to peruse the mailing list thread.

http://lists.basho.com/pipermail/riak-users_lists.basho.com/...

Re: Goodbye, CouchDB

#57

Post by geophile »

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.

Re: Goodbye, CouchDB

#58

Post by scubaguy »

trimbo wrote: post #24
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.

The author mentioned one of the reasons for choose MySQL is that they are familiar with MySQL. They could've went with PostgreSQL and EnterpriseDB, also a great company. It's not like you can't get commercial support with PostgreSQL.

Re: Goodbye, CouchDB

#59

Post by bitdiddle »

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…

The current plan is to integrate BigCouch into CouchDB.

Re: Goodbye, CouchDB

#60

Post by spudlyo »

derekorgan wrote: post #20
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.

probably because as they stated they are familar with MySQL. After getting hurt trying out a new technology to them it makes sense they go back to something they know. Will probably lead to more uptime which is what they want.

We were excited to try a NoSQL db, having spent too many years using MySQL in ways that the designers of relational databases never imagined.

...

Given that we had experience with MySQL and knew it was adequate for our needs, it was hard to justify any other choice.

Agreed. It seems pretty clear from reading the article why they went with MySQL, which you wouldn't know from all of the Postgres butthurt in the comments.

Post reply on HN