Moving From CouchDB To MySQL

itwbennett writes "Sauce Labs had outgrown CouchDB and too much unplanned downtime made them switch to MySQL. With 20-20 hindsight they wrote about their CouchDB experience. But Sauce certainly isn't the first organization to switch databases. Back in 2009, Till Klampaeckel wrote a series of blog posts about moving in the opposite direction — from MySQL to CouchDB. Klampaeckel said the decision was about 'using the right tool for the job.' But the real story may be that programmers are never satisfied with the tool they have." Of course, then they say things like: "We have a TEXT column on all our tables that holds JSON, which our model layer silently treats the same as real columns for most purposes. The idea is the same as Rails' ActiveRecord::Store. It’s not super well integrated with MySQL's feature set — MySQL can’t really operate on those JSON fields at all — but it’s still a great idea that gets us close to the joy of schemaless DBs."

Re:Wikipedia and Slashdot use MySQL

[SuiteSisterMary]

MongoDB is webscale. It has sharding. That is the secret webscale sauce. [youtube.com]

Re:The decision the simple

[TheSpoom]

The real key is for the person doing the hiring to understand which of those of methodologies fits their application.

This is insighful. I've worked extensively with RDBMS solutions and now quite a bit with NoSQL technologies. They each have their place. An entire article could be written on where each fits most naturally, but in general if you don't need to join between tables, need to throw data to your store at a high velocity (e.g. logging), and/or need a loose schema, a NoSQL solution works best. If what you're doing can be naturally modeled (i.e. users HAVE AND BELONG TO stations, stations HAVE MANY playlists, etc. etc.), use an RDBMS.

One can see in the subtext of the GP that they may not get this, with their comment that people using RDBMS solutions are "stuck in old ways". It seems like they are saying that NoSQL is effectively always best. I'm curious why they think that. Nail, hammer, etc...

Re:Is a DB even needed sometimes?

[rtaylor]

A CSV or XML or JSON file is a db (a DB is just structured data).

Are relational DBs always required? Certainly not.

The big benefit to a relational DB with lots of enforcement at the data layer is that you can have one or more applications reading/writing to it with minimal concern of data corruption.

What isn't obvious is that second application is often aggregate reporting for management. "How many customers are using $foo and where do they live geographically". With a relational DB, I might knock that query out in a few minutes across millions of customers.

With a flat XML file per customer spread across a number of servers, this could take days to assemble, particularly if $foo is nested deep in the structure.

Having spent far too much time writing one-off scripts to gather customer data because the middleware didn't support that type of query, I've actually gone the other way and started shoving some business logic into the DB.

Functions such as isCustomerPaymentOverdue are now in the relational DB with a very thin model in the middleware to allow for much easier and faster reporting.

Not quite true

[Viol8]

If all your application is ever going to do is read and write to fixed sized record structured data with little relational (or any) attributes then COBOL will suit you fine as that's what it was designed for. Unfortunatly those sorts of apps are few and far between these days, but in its ever decreasing niche COBOL is still good.

Re:Not getting RDMS

[Joey Vegetables]

From a purely pragmatic point of view, it may not seem unreasonable to model it that way. But you should be aware that you are trading one form of complexity for another, probably bigger one. For instance, now, if you want to know who was alive on some specific date, you have to write something like "WHERE DateOfDeath IS NULL OR DateOfDeath > @date." You also will not know for certain whether a NULL means "person is still alive" versus "person is dead but we do not know his or her date of death." When you try to compare different people's death dates any comparison to NULL will yield NULL and you will need special case logic in every such comparison. You will need tristate logic throughout any part of your application that does logical tests based on the date of death. Nullable values will sometimes require special treatment in your code, depending on the language (e.g., whether date/time values are considered to be nullable in that language). I could go on. I also could build you both tables, an updateable view, and a set of SPs to do your basic CRUD stuff on both tables plus "show me living people" and "show me dead people", in a LOT less time than it would take to handle all the code problems that would result from breaking 1NF. I am not an extremist on this subject, but I wear both DBA and developer hats, and when I'm acting as a DBA or in any other situation where I have control over the DB, I do try to get into 3NF, and then denormalize only if there are demonstrated reasons to do so. As a developer, I will sometimes take shortcuts if it's genuinely necessary, but, more often than not, I end up regretting them.