

NoSQL Is for the Birds - thesethings
http://gigaom.com/cloud/nosql-is-for-the-birds/

======
antirez
I think that the data model of some new database is more suitable for
different use cases compared to relational DBs.

Also it's not just a matter of scalability: latency is a very important
constraint.

Finally I see a lot of small sites, forums, blogs, that can't scale easily to
small numbers using relational DBs, since with the relational model and
current implementation you have the illusion that can design a few table and
then invent your queries, and instead this does not work and is dramatically
slow.

No need to have very large numbers to see how hard traditional DBs sucked. And
the proof is the huge adoption of NoSQL in small companies: it's not just
hype, people want to go home and sleep well and will not trow away working SQL
solutions because there is the new hype. The reality is that they are
experiencing serious problems even at the scale a small and mid-size company
operates.

~~~
tkahn6
I'm using Redis as a backend to store course availability information at my
university. If the set contains the course ID it has an open seat. Data is
scraped and processed continuously and there are ~7200 courses so Redis is a
good fit.

~~~
desigooner
Is there a matrix of features or use case scenarios for the various NoSQL
options out there?

e.g. i have a lot of person data with various attributes like applications,
schedules, choices, demographics, courses, etc. (university). At certain times
of the year, a lot of transactions would occur and at other times, it'll be
getting very low traffic/transaction requests. MySQL tends to be a PITA if we
try to modify certain things to add or remove tracking and so on while live
hours and as things are run, unfortunately a lot of changes come in unplanned.

How should I go about finding the best fit for this scenario?

------
fiveo
Hmm, Twitter is really big in using Scala.

The important message is this: "focus on the process to build a great company
and great products... They didn’t become successful because they built these
systems. They built these systems because they became successful."

The next unproven startup that uses NoSQL solution is just wasting their time.
I know this because that happened to one of my previous workplaces (we use
HBase).

~~~
dorkitude
That does assume that the company's non-SQL choices don't actually _save_ time
during development.

In building a system the design of which is under constant flux, there can be
a lot of time lost dealing with schema rigidity.

~~~
jasonkester
That's one of the tough myths to overcome when building on top of a relational
database. Changing the Database has traditionally been Hard, so everybody has
been trained to think that way, therefore nobody is allowed to change the
database because Changing the Database is hard. Try it at your bigco and the
old guys will do everything in their power to stop you (thus making changing
the database hard to do).

Ignore that rule and build yourself an environment where changing the database
is easy. I make schema changes to my stuff all the time, and seldom push a
release live that doesn't do so. The tools are in place to ensure that it's No
Big Deal, so it just works.

If you live in a world where changing your SQL database is easy, it sort of
takes the wind out of the "start with NoSQL, because changing the database is
easy" argument. You get all the speed advantages of being schema-flexible, and
you can write ad-hoc queries when you want to, so you're flexible in that
direction too.

~~~
billybob
Would you mind telling some of the tools and techniques that make this easy
for you?

~~~
jasonkester
All you really need to pull it off are:

\- Change scripts for every schema change, stored in source control.

\- An automated build/deploy that pulls down new change scripts and executes
them in order.

\- (optional) a good way to generate your backend CRUD by looking at the
existing database schema, or as a lesser option an ORM that does the same
thing.

So your workflow is: script out your schema change, check it in, apply it to
your dev environment, regenerate the CRUD from your local schema, fix any
compile errors that you've introduced. (and optionally make sure all your unit
tests still pass).

You'll notice that all that stuff above is just the basic workflow you should
have in place anyway.

~~~
rbranson
This is exactly the pattern used by Rails apps with database migrations and
Capistrano deployment.

------
gte910h
Again this topic brings out the "Always use relational databases" folks.

Few say "Always use NoSQL stores".

Most of us who use NoSQL, use it in conjunction with other stores, some of
which are relational databases and some aren't.

Lunch isn't free, blah blah, etc. However with NoSQL solutions, we can
optimize the things we care about (reads and writes) over the things that
happen rarely (changes to the schema, indexing, etc) if we want to. Sometimes
our apps demand it, sometimes before the cash exists to even try to use oracle
or the people you have to hire to properly support it.

I don't get why people steadfastly assume everything fits the paradigm they're
most comfy with. It doesn't. People who are just as comfy with your paradigm
found stuff that works better, easier for them.

~~~
ergo98
_Again this topic brings out the "Always use relational databases" folks._

You show that strawman who's boss!

 _I don't get why people steadfastly assume everything fits the paradigm
they're most comfy with._

Indeed.

~~~
gte910h
Gaius at least is going all rdbms all the time all over the thread. I'm not
dreaming that up am I? (I didn't realize it was one guy at first).

------
js4all
Great article. But it only sheds light on the performance and scale aspect.
Having used nosql in my last project, I found some other aspects:

    
    
      - Flexibility
      - Replication
      - License agreements
    

Nosql allows easy and painless schema changes, because there is no hard-coded
schema. Using a morphing library every object can be stored without any
additional coding.

Some nosql DBs support two-way replication for nodes that can be offline for a
long time (for instance mobile clients). This can be very handy if you need
such a feature.

Some nosql DBs come in a very liberal apache license.

If find it great to have so much choices today.

~~~
fauigerzigerk
Relational databases have as much or as little schema as you like and the
article did point that out. NoSQL varies widely in terms of approaches to
schema so I don't think a blanket statement about NoSQL schema evolution is
even possible.

The issue I see is that moving the kinds of guarantees that schemas provide
into application code doesn't necessarily make the system as a whole more
flexible or easier to modify. The exact opposite could be the case.

Postgres has a very liberal license as well by the way.

~~~
gaius
Indeed. You could build a relational database like

    
    
      create table nosql (id number primary key, stuff blob);
    

Hey presto, generic key-value store. The point of a RDBMS is that you can do
this _and lots more too_.

------
sofuture
NoSQL and RDBMS are not competing tools occupying the same solution space.
It's not an either-or, and anyone who thinks that it is has _no idea what
they're talking about_.

NoSQL doesn't give you a tool that scales better, it gives you a different
tool that might fit what you're trying to better.

------
nivertech
Some NoSQL products geared towards rapid prototyping, and not for scalability,
like for example CouchDB. With CouchApps you can create entire Web App in
Javascript, sitting in CouchDB.

