
I Can't Wait for NoSQL to Die (2010) - bontoJR
http://widgetsandshit.com/teddziuba/2010/03/i-cant-wait-for-nosql-to-die.html
======
ohsnap
I felt this way too in 2010. Not so much now. 'Nosql' Data services like parse
and firebase is how apps are going to be built. The speed from idea to
implementation is a real game changer.

~~~
bontoJR
This is a good point of view. Honestly I never thought that services like
Parse or Firebase could gain so much hype and get a place in the market for
the lack of flexibility. But the truth is that only few apps are successful
enough to require an high level of performance and flexibility, so it makes
sense to build a first version using these services and eventually move away
if the product is successful, there's no reason to build a top-class service
to later have it barely or even not used at all...

~~~
jkarneges
I'd say the success of Parse and Firebase have a lot to do with the fact that
they are services, especially _public internet accessible_ services (in
contrast to a host of DBaaS options that are meant for "behind the webserver"
use). Maybe if someone created a version of MongoDB that could be safely
accessed from the browser, it would have been just as interesting?

Or maybe it really is about the simpler APIs that Parse and Firebase provide.

Or, maybe Firebase is mega popular due to the realtime change events. Too many
variables. :)

~~~
bontoJR
I would bet on development speed. Using SQL and No-SQL software brings a lot
of engineering, you have to decide where to host, how to host, who is going to
take care of that. This translates into costs. After that there's a new bunch
of problems, it's required to engineers to know the platform and create the
software for that. After that there's maintenance, etc... all things services
like Parse and Firebase removed, with the trade-off of less flexibility, but
as I said before, this can be a problem later in the development stage...

------
sklogic
There are some areas where relational DBs simply have no place at all, and
never had. For example, CADs always relied on the hierarchical database
engines, and it should always stay this way.

This new hipster relational model is not nearly as universal as its proponents
are claiming.

~~~
hobarrera
Much like the relational model isn't universal, neither is the nosql model,
and that's exactly the point. It keeps being adopted in places where sql is
the right solution.

~~~
sklogic
I'd consider it a kind of revenge. Previously we had to deal with an unwelcome
invasion of SQL into the areas it's not suitable for, now the SQL guys have to
fence off an invasion of document-, graph-, hierarchical- and whatever else
models.

Once dust is settled on this battlefield, the world will become a better
place, where more people are aware of their tools limits.

------
bryanrasmussen
I don't understand the part about NoSql replaced Ruby on Rails - apples were
replaced by pears?

------
liquidcool
I like RDBMs, they get the job done for me (yay Postgresql), but his AdWords
example is no longer correct. From Wikipedia:

> Eventually, Google developed a custom distributed Relational database
> management system (RDBMS) known as Google F1 specifically for the needs of
> the Ad business, which requires strong consistency, high scalability across
> data centers and powerful SQL queries. The interface has also been revamped
> to offer better work flow with additional new features, such as Spreadsheet
> Editing, Search Query Reports, and better conversion metrics.

~~~
HolyHaddock
It's no longer correct that it uses MySQL - it's still not using BigTable, and
in fact an RDBMS seems to have been implemented instead. That would appear to
still support his rant?

~~~
liquidcool
You're right, that's a good point. And it seems Google has started to move
away from BigTable with Spanner, which F1 is built on:
[https://en.wikipedia.org/wiki/Spanner_%28database%29](https://en.wikipedia.org/wiki/Spanner_%28database%29)

------
GauntletWizard
Lots of companies use NoSQL badly, and lots of NoSQL is implemented very
badly. I can't help but think an awful lot of these engines read the bigtable
whitepaper and completely misunderstand why it was important.

MongoDB, for example, uses collection latches. Thankfully, these are per-
server, so if you're using sharding you've got one per server. It is still no
better at single-server performance than MySQL using table-based locks (except
that you are unable to write a query that uses two tables), except that the
latches and 'documents' (locks and rows) are lighter-weight.

The writes in mongo are only document atomic. Why not use a latch per-
document? It needn't be memory intensive; Use a bloom table to represent the
latches, and a small amount of entries (a thousand or so) is plenty to allow
real concurrency.

Lots of companies use collections badly. I've seen a collection of user
addresses. These make no sense as a collection; They're less than a kilobyte
long. They should be an array in the user object. Mongo documents are meant to
be an order of magnitude larger than SQL rows, and a few kilobytes here and
there won't break the bank. You're better off doing a 1M read than three
serialized 1k reads; The RTT is comparatively long, even at sub-milisecond
latencies.

~~~
threeseed
Not sure what you mean. MongoDB is not an implementation of BigTable
whitepaper. It's a document store. And document level locking has been
available in WiredTiger since version 3.0 and TokuMX since version 2.x.

And the most well known database that is derived from BigTable is Cassandra
which is unquestionably very well designed and the authors (Facebook,
Datastax) clearly understood what they were doing.

------
yati
I felt the same when my previous company was stubbornly using MongoDB for its
"flexibility" and we ran into all sorts of issues (following which we slowly
migrated to Postgres -- having solid ORM libraries with similar interfaces
helped).

I'm genuinely curious about one point, though: How is Walmart a "real
business" vs Twitter?

~~~
justthistime_
> I'm genuinely curious about one point, though: How is Walmart a "real
> business" vs Twitter?
    
    
      - One of them actually earns some money from time to time.
      - If one of them disappeared overnight, it would have some impact on peoples' lives.

~~~
yati
Haha, making real money is indeed a good point :)

But, can't it be argued that in fact if Twitter disappeared overnight, it
would have some tangible effects on the earnings of many businesses that use
the platform for advertising/brand presence?

~~~
lowmagnet
Wal-mart employs 2.2 million people.

------
Animats
There are scaling problems which require something that scales better than
MySQL or Postgres. If you're Google, you really need BigTable. But, as I've
pointed out before, unless your site has more traffic than Wikipedia, you
probably don't have those problems.

Wikipedia is basically MySQL front-ended by ngnix and memcache caches.

~~~
russell_h
Wikipedia is also unusually cacheable, a tiny fraction of users are even
signed in. More dynamic and personalized content means hitting the limits of a
traditional RDBMS with less traffic.

~~~
Joeri
Stackoverflow runs on sql server. Even with dynamic sites, proper design tied
to a proper rdbms scales quite nicely

------
samdung
[https://www.google.co.in/trends/explore#q=mongodb%2C%20mysql...](https://www.google.co.in/trends/explore#q=mongodb%2C%20mysql%2C%20couchdb%2C%20nosql%2C%20postgres)

------
calgoo
I believe it has its places, just as SQL does. From what i have seen, NoSQL
fits in where i was doing FS operations before, as a cache, or "blob" store.
Somewhere to dump stuff for a while before its processed into SQL or whatever
other format is needed. Something that can be easily replicated and queried
instead of having to deal with the underlying FS and clustering that.

It also fits in as Key/Value stores for temporary session data, and where you
need very high performance in memory access that can be shared between several
servers or processes.

------
unusximmortalis
NoSql type of DBs have their value added. They'll not die, instead businesses
will learn when they are useful, some the hard way some the easy way :)

------
franze
still alive [2015]
[http://www.indeed.com/jobtrends?q=mongodb%2C+mysql%2C+couchd...](http://www.indeed.com/jobtrends?q=mongodb%2C+mysql%2C+couchdb%2C+nosql%2C+postgres&l=)

~~~
onion2k
Is "times mentioned on a job advert" really an accurate measure of whether or
not something is still used? Surely it lags years behind trends - if a
technology is abandoned quickly there'll still be jobs maintaining the old
code that need that skill. That doesn't mean the technology is still 'useful'.
For example, there are still plenty of COBOL job ads around.

I'm not suggesting that's the case for NoSQL, just questioning the way you're
measuring it.

------
teh_klev
The sanctioned archive of TD's posts are here:

[http://widgetsandshit.com/teddziuba/2010/03/i-cant-wait-
for-...](http://widgetsandshit.com/teddziuba/2010/03/i-cant-wait-for-nosql-to-
die.html)

[http://widgetsandshit.com/dozba.html](http://widgetsandshit.com/dozba.html)

~~~
dang
Thanks. We've changed the URL to that from
[http://www.memonic.com/user/dorian/folder/internet-
tidbits/i...](http://www.memonic.com/user/dorian/folder/internet-
tidbits/id/1HiG).

------
dxedxaede
No one is going to fund your start-up if you do not speak web scale. And the
only web scale game in town is NoSQL. Also node.js.

~~~
gjolund
It is really obvious that you don't know what you are talking about. Sometimes
it is better to say nothing at all.

~~~
nice_byte
He/she was joking.

------
braz1973
This is where a bunch of people with no clue talk about how great pgsql is and
everyone should create their startup using raw sql and only psgsql because it
does everything even nosql ;) It is funny how forums gravitate towards
inappropriate and obscure solutions and then recommend them in every
situation. You can see the same effect all over the internet. Eg MFA on reddit
recommending Allen Edmond shoes. A completely inappropriate shoe with leather
soles that costs 10 times as much as modern shoes.

NoSQL databases are much nicer to work with for typical web applications
(yeah, even the ones with relational data). They are much closer to how we
actually use data as a programmer. Most startups using a SQL database will be
using an ORM, which is a massive piece of software designed to make SQL
databases more compatible with how we actually work. Even then, they still
don't have the flexibility you get from using a nosql solution.

As for this article, it is hard to get past the fact that he thinks the only
reason to use nosql is for scalability. He also states that mysql was fine,
yet fails to understand that the massive startups using mysql didn't use it at
all like a relational database.

~~~
eropple
_> They are much closer to how we actually use data as a programmer._

No, they're how you, as what sounds like a predominantly object-oriented
programmer, use data. And that's fine, but don't pretend it's universal. A
programmer approaching a problem from a functional perspective may well
exploit the relational nature of an RDBMS to work smartly within the paradigm.
(I've seen it done, and done very well and easily, in a way that's
approachable even for relatively novice functional programmers.) Even if using
an object-oriented style of programming, with the feature set of something
like PostgreSQL--or SQL Server, if that's your bag--and the ability to very
easily provide assurances around data integrity and correctness using the
built-in tools, you have a very powerful and easy-to-use set of tools for
building a rugged, _correct_ data model. For product developers that do not
find a cavalier approach to users' data to be acceptable, this can be a wise
choice. Being fast and wrong is not always the right answer (and I personally
consider it to usually be the wrong one).

But it's even better to be fast and right, and that can quite obviously be
done, in many cases, with a relational data store. And this may mean
understanding how to write code in a style that doesn't necessarily use the
Active Record pattern or a similar ORM. That's true. But that does not imply
an inherent product development benefit to using such a tool (for their
partisans), nor does the common reliance on these tools and its well-
documented failures imply that the various NoSQL technologies are better at
building a product.

~~~
braz1970
Err no. It's great that you have just discovered functional programming but
your claim that the data presented by a relational database is only unnatural
for object oriented programming is absurd. When you join tables you get
something like this:

User1 firstname1 lastname1 role1 rolename1

User1 firstname1 lastname1 role2 rolename2

User1 firstname1 lastname1 role3 rolename3

This is purely a result of how the database works. That data is never
presented to the user in that way. It has to be converted into a new form.

