
The NoSQL Hype Curve is Bending - tswicegood
http://phparch.com/2010/12/29/the-nosql-hype-curve-is-bending/
======
latch
Some NoSQL solutions are general purpose, and some aren't. I think the
analysis is accurate for those which aren't (Cassandra), but way off for those
which are.

The advantage of NoSQL for the average folk isn't their speed, but rather it's
their dynamism. This is especially true if you're coding in a static language.
You also gain from the shift to map-reduce vs group by.

There seem to be two other points to the argument. First, someone made a funny
Youtube video (and it was funny!). Second some people failed with NoSQL. Not
especially good arguments.

------
mark_l_watson
The author is an SQL language and MySQL database consultant, and he writes an
article questioning NoSQL. Fair enough, and I agree with his point that
different NoSQL datastores have different strengths and weaknesses and it can
be difficult on a new project to know up front which CAP tradeoffs may be OK
to make (e.g., HBase may have better tuning for faster consistency but
Cassandra is likely easier to set up across different data centers; MongoDB is
very easy to use in simple master slave or replica sets setups if no sharding
is required; etc.)

Personally, I use PostgreSQL and MongoDB for most of my work but make a real
effort keep up to speed on CouchDB (actually, BigCouch is more interesting),
HBase, Cassandra and a few RDF datastores.

------
ibejoeb
I've had a pretty good run at cleaning up after botched database jobs, so
caveat emptor...

Two things:

1\. Most day-to-day problems involve relationships among entities. It's not
stodgy or wrong to use a good RDBMS when that's the problem you're dealing
with.

2\. Many NoSQL adopters wind up building a relational database on top of
something else. That's a fun job, but not everyone can afford to ditch 40
years of R&D and pretend they've invented something. I think a lot of the
allure in implementing these solutions comes the hype, promise of a silver
bullet-like solution, and the opportunity to dabble the intricacies of
creating a database.

~~~
yrb
You could also arge that adopters 'sql style RDBMS' end up building a NoSQL
datastore.

If you find you are using a lot of EAV, polymorphic associations, multicolumn
attributes, trees, graphs it might be a better option to go down one the on of
the many NoSQL routes. Key/Value, Column Stores, Document and Graph databases.
Sometimes you can make huge gains in design simplicity because you persistance
and/or queries map far more cleanly.

An interesting example of "NoSQL" on top of an "RDBMS" is Salesforce [1].

A huge upside to RDBMS in my view is that they are 'well understood' in
production, and operations know how to deal with them.

It is a big design space out there, and you can make a lot of tradeoffs :)

[1] [http://www.infoq.com/presentations/SalesForce-Multi-
Tenant-A...](http://www.infoq.com/presentations/SalesForce-Multi-Tenant-
Architecture-Craig-Weissman)

------
jamesbritt
Does attention and interest == hype?

I've seen many articles about NoSQL, but few that insisted it was the shit and
the True Path for all development.

Mostly the articles explained what this or that DB was, or how this or that
company solved a problem using some NoSQL tool.

It's new (for many people), interesting, and worth talking about.

If anything seems over-inflated to the point of hype, it's the idea that
there's all this hype about NoSQL.

~~~
catshirt
to answer your question: true

------
seanmcq
One of the biggest costs of a NoSQL solution in an early-stage startup: what's
hot today may be abandoned by everyone else by the time you're a real company,
leaving lots of effort inventing clever solutions to novel problems created
entirely by your data.

It's much more feasible to start with a solid database and add caching for hot
data than it is to try to build a company and a brand new database technology
at the same time.

------
gabrtv
I took me 3 months or so to finally grok CouchDB map/reduce queries. Now that
I've seen the light, I'm not sure I'll go back to an RDBMS any time soon -- at
least not for bread and butter webdev.

"...You must know what will be the questions that you will be asking upfront."

Even in SQL land you need to know your queries in advance. Sure you can do
table scans on unindexed fields, but you're going to crush i/o.

With Couch you can always deploy new views during a maintenance window for
queries you didn't anticipate. Same thing with adding indexes in an RDBMS to
handle unanticipated/slow queries.

At least with Couch I know that my queries are more-or-less pre-computed in
B-trees. I know I'm not scanning the same tables over and over.

Moreover, if you know what you're doing wrapping conflict handling around
Couch's MVCC is straightforward.. and you get all the benefits of offline
replication.

In my case, I've built a service that calculates utility-style usage based off
Couch range queries that are reduced into a cost calculation. Given any date
range I can reduce a utility fee an order of magnitude faster than I could in
SQL land.

YMMV, etc.. but I'd say this is a case of "haters gonna hate".

------
michaelchisari
It seems contradictory, since startups thrive on making radical departures
from the status quo, but I think there's a strong case to be made to build
your foundation (the stuff nobody sees, but plugs along silently in the
background) on tried and true technologies, as opposed to the hot new thing.

Of course, in 5-10 years, some NoSQL solutions will be the tried and true
tech, and we'll be arguing whether DoublePluSQL is really worth all the hype
it's been getting.

~~~
neilk
> startups thrive on making radical departures from the status quo

Meanwhile, Pinboard.in quietly sucks up the Delicious community, using
technology that's as dishwater-dull as possible.

Delicious itself is floundering, due to (among many other things) a
problematic migration to a framework that was internally marketed as the sexy
new thing. That framework wasn't NoSQL at all (quite the opposite) but the
point stands that the cost of new frameworks can be dear.

~~~
zeemonkee
Do you have any reference for this ? Delicious' problems as far as I've read
anywhere are due to Yahoo's cutbacks, plus having to integrate with Yahoo
services, making it hard to break off and sell to another company. However
I've not heard about any specific technical issues with Delicious itself.

~~~
neilk
I worked one floor away and have friends who worked on Delicious. Generally
they haven't talked about this, so I don't think I should. Plus I'm getting a
bit tired of all the TC "scoops" that come out of all of this bitching in
public.

------
jforman
This is a terrible article. His three main points:

1\. "You find yourself writing lots of code to reinvent the wheels that SQL
gives you for free, and before long you’ve unwittingly reinvented the
relational database."

NoSQL came about because people were sharding their data and managing
relationships outside of the data layer in custom code anyway, and they were
well-served by putting some of that complexity back into the data layer. This
wasn't a trend because people don't understand the mathematical beauty of
normal forms. This was a trend because altering the schema of a heavily
accessed MySQL table will bring your website down.

2\. Digg

A Digg engineer on Quora recently said, "The whole 'Cassandra to blame' thing
is 100% a result of folks clinging on to the NoSQL vs SQL thing. It's a red
herring." ([http://www.quora.com/Is-Cassandra-to-blame-for-
Digg-v4s-tech...](http://www.quora.com/Is-Cassandra-to-blame-for-
Digg-v4s-technical-failures)). Yup.

3\. The MongoDB is Web Scale video

...really?

------
fleitz
The irony is that most of the arguments for NoSQL have nothing to do with SQL
itself and everything to do with the underlying storage mechanism and ACID
semantics. A more accurate acronym would be NoB-tree or NoACID.

~~~
gregschlom
Would you care to elaborate on that?

------
Luyt
This is actually the first time I came across
<http://www.xtranormal.com/watch/6995033/>

I have always seen the relational-databases-VS-nosql-databases as a false
dichotomy. I think these systems serve different purposes. I use
MySQL+memcache for a site now, but I'd have no hesitation to use CouchDB for
another site if that's more suited for it. I'd even use them both if that's
beneficial for the webapp.

~~~
Luyt
And the followup: "MySQL is not ACID-compliant",
<http://www.xtranormal.com/watch/7091415/>

------
DrStalker
NoSQL is a terrible name for a technology. Why define it by what it isn't,
instead of what it is?

I've pretty much ignored NoSQL because of this, and because I haven't had any
data storage problems that aren't easily solved with either a relational
database or LDAP.

------
p_nathan
A chap named Brooks wrote an article a long time ago that went by the name "No
Silver Bullet".

Sorta sad how the world keeps looking for the silver bullet to slay the
vampires of software. You'd think by now we'd know...

------
linuxhansl
Yep... I never quite bought the NoSQL hype.

The only valid point was to relax some of the guarantees (like consistency) in
order to achieve better scalability.

In the end once cannot escape the CAP theorem
([http://www.julianbrowne.com/article/viewer/brewers-cap-
theor...](http://www.julianbrowne.com/article/viewer/brewers-cap-theorem))

~~~
ethangunderson
Is there a NoSQL database that claims that? I don't know of one. Rather, they
attempt to implement different facets of CAP. Also, the CAP theorem, as it
stands, is showing its age, Brewer himself has said it needs to be updated.

------
Charuru
I'm one of those who dove head first into NoSQL primarily because of hype.
I've learned better. Relational is now my default, and I identify specific
cases, specific tables that I know for sure won't need complex querying, and
move those to NoSQL.

Though the end effect is that NoSQL still stores 60+% of my data.

