
Oracle on why you shouldn't use NOSQL (PDF) - omaranto
https://docs.google.com/viewer?a=v&q=cache:G4pI4ZOkzWYJ:www.oracle.com/technetwork/database/debunking-nosql-twp-399992.pdf+oracle+debunking+nosql&hl=en&gl=uk&pid=bl&srcid=ADGEESiaUPuEdyJ9cnDc_GzgsfsNq6UytDZeO5f0pgDJyUeo7x-xfe2W091nseq4s1cIl9lZ79jmGT0TRpE5PF8svROWbJSjcbrm6TXb2AWfM2TaAa6Z80dEupN3oSFzZG6y9mWBsgTd&sig=AHIEtbSXOrH6n87xP4yC4bqqMaLHSMBBNg
======
praptak
_"NoSQL databases are not free to operate. Each NoSQL Databases come with the
cost of hardware, administration of the hardware, and support of the
software."_

Hey Oracle, if you want to bring this point up, please at least pretend to
compare the above costs between NoSQL and your own solution. Otherwise it is
just pure FUD: "NoSQL databases eat your CPU cycles, disk and network
badndwith! Booooo!"

~~~
antirez
Same argument that was used against Linux, that is also system software. Too
old, they should retry with something more interesting.

~~~
praptak
Well yes but AFAIR MS at least provided some data that could be critically
analyzed (whether it stood up to the analysis is a different matter.) I am all
for using TCO as an argument in tech advocacy, just as long as it has some
backup in verifiable data.

~~~
bad_user

         as long as it has some backup in verifiable data
    

A discussion on TCO is very dependent on the context in which the analysis was
made, such as application type, volume of data stored, volume of data indexed,
type of data (e.g. is it a tree? is it a graph?), queries per second/hour,
number of concurrent connections, analysis on further scaling possible
(vertical / horizontal), analysis on the requirements for real-time ad-hoc
queries, entry-level costs, and so on and so forth ...

Basically, the variables are so many and so complex that any TCO analysis
(regardless of validity) won't apply to your case.

That said - I rarely feel the need for NoSQL, simply because I can fine-tune
PostgreSQL to whatever needs I want. But I'm not running neither Facebook, nor
Twitter.

~~~
mgkimsal
Also include the skills of the people operating everything. A MCSE trying to
administer various Linux boxes will have terrible TCO, and a RHCE trying to
optimize an NT box will have similarly bad TCO.

------
sdizdar
I guess this boil down to the following four points:

\- NoSQL is good in scaling: but do you really need to scale? Is your business
so great to handle 1M users? Simple MySQL (and PostgreSQL when mysql is not
ok) will go a long way for many many installation.

\- NoSQL are in good in scaling but it is pain to maintain it: it hard to hire
somebody who knows it good, there are no good management tools, etc.

\- NoSQL requires you to make your application logic more complex and not
portable

\- There is no clear NoSQL leader and clear mainstream knowledge. And a lot of
these NoSQL implementation requires some secret sauce known only to engineers
maintaining and developing big NoSQL installations at Facebook, Google and
Amazon.

In short, for startups, NoSQL is one more variable introducing risks and
unknowns. So I think startups should not go NoSQL unless that is the core of
their offering.

~~~
jeffdavis
"In short, for startups, NoSQL is one more variable introducing risks and
unknowns. So I think startups should not go NoSQL unless that is the core of
their offering."

Well said.

NoSQL may have a lot to offer in some cases, but I think "easy" is an illusion
when you look at the full picture.

------
pdubroy
In other news, the barber thinks you need a haircut.

~~~
Roboprog
And perhaps a few leaches to get the bad humors out, as well. (financial)
"haircut", indeed.

I actually agreed with much of the data integrity problems the paper pointed
out, but found it a bit too condescending, or perhaps even a bit threatening,
around the "You are not Google" part. Big Brother loves me!

------
zzzeek
This document is nothing more than an embarrassment for Oracle. "One size DOES
fit all - and that size is ORACLE!" Really? Even the most entrenched, old
school DBA stuck in the bowels of some drab insurance company in Indiana
wouldn't buy that. I'm not a NoSQL guy by any means (check my profile) but the
desperation in this doc is way more palpable than a guy like Ellison would
approve of.

~~~
illumin8
You truly underestimate the zealotry and kool-aid drinking capacity of the
average Oracle DBA. When your entire career is based on the training and
certifications you've received from a single company, every database solution
magically becomes Oracle...

~~~
warfangle
When all you have is a hammer, all the problems you encounter end up looking
like nails.

------
nphase
_"While in theory, NoSQL databases can be deployed on hundreds or thousands of
machines, in practice the deployments are much smaller and can typically
easily fit within a single Oracle database with fewer and more reliable
components. The largest production Cassandra cluster has over 100 TB of data
in over 150 machines."_

I find this interesting. I wonder if there any real TCO comparisons have been
done to this point.

Sure, this paper is full of FUD. But it does raise a valid question for me:
What's the difference between paying for Oracle and paying for MySQL,
Datastax, or Cloudera support/enterprise to get the added features needed to
run my business and keep away from reinventing the wheel?

~~~
shin_lao
That sounds bogus. A 100 TiB Oracle database is doable but incredibly
expensive. 1 TiB with the appropriate redundancy will cost you around 10,000 €
if you go Oracle. Perhaps you can get a good discount if you order a large
cluster right away. So we're looking at 1,000,000 € just for disks here.

Then you would have to pay for the CPUs, the licenses and the consulting (lots
of it, tuning a 100 TiB system is a huge task). Add another million or two...

How much would it cost with a NoSQL solution? Don't want to turn this answer
into self promotion, but I'm confident it's well under the million with better
performance (assuming you don't need a relational database).

~~~
sliverstorm
They probably give you volume discounts, you know. And would a 150 machine
NoSQL cluster really compare _so_ favorably? An enterprise-grade server with
an array of 10k-15k RPM drives or SSD's and appropriate redundancy is not
going to be cheap.

What about the cost of manpower to operate one vs. the other? If you can hire
one novice sysadmin @ $40k, labor costs will be small, but for a 150-machine
cluster you aren't going to get far with a $40k novice.

~~~
shin_lao
The price I gave you is what one of our customers pay, after negotiation.
True, they didn't order for 100 TiB.

In 2011, you don't need 150 nodes to build a 100 TiB system.

Don't take this as an official estimate, but I think we would advise on 7200
drives and more RAM and it would probably end up with a system one (several?)
order(s) of magnitude faster than what you would get with a regular RDBMS.

~~~
nknight
Hell, you could probably fit 100TB in pure RAM for what you'd spend on Oracle.

~~~
sliverstorm
Good luck with that. At $100 per 8GB of ECC RAM, that's $1mil in RAM, and with
4-slot machines you'll need 3,200 boxes. 1,600 boxes if you go for dual-CPU
machines with 8-slot.

~~~
onemoreact
You can get dedicated machines that hold 16TB of ram in 18U. Also you can get
2x8GB of ECC ram for 150$ and with bulk orders it drops even more.

------
alanX
In my own experience, deploying applications on traditional relational
databases is a pain. Most of the applications I have worked on were
applications for State government. The applications get heavily tied to the
database, requiring the database to be populated to test the logic. The table
structures are unnecessarily convoluted. These applications process client
data (eligibility, certifications, enrollment) sometimes in the context of
state data.

I have built solutions that allow me to collect data from running
applications, and later inject data from these collected scenarios into the
business logic for testing and debugging.

All of this to say that any objective analysis of these systems would reveal
no need for a relational database. In fact, imposing the relational
transaction model onto these applications is clearly detrimental to the
development of these systems, the cost of these systems, the testability of
these systems (though this isn't really the fault of the database technology
itself), and the performance of these systems.

We should be processing the information through an application designed solely
according to the needs of the application, and then selective pushing data to
a data warehouse for reporting (which can certainly be a relational database).

It is almost like Ford claiming all your transportation needs require a truck,
and forcing all supermarkets to accommodate driving trucks up and down the
grocery aisles...

Nobody would say you don't need trucks. But the fact that trucks are sometimes
needed isn't proof you should always use a truck.

------
omaranto
This is a Google cache link to an Oracle whitepaper on NoSQL databases that
jakewins posted to the programming subreddit. On page 13 the paper asks "Do
you really want to be contributing to an open source effort?".

~~~
spinchange
That entire paragraph (paper?) is an interesting bit of FUD:

>>The NoSQL database has been sponsored by large internet companies. Such
sponsorship has added credibility to internet scale claims of the databases
and an aura of "coolness." The large internet companies have been motivated by
having free database software that is under their complete control. These
companies have hired top developers for their scalable database
implementations and to keep them running. Is your company prepared to make
such an investment in an area which is not your company's core competence? Do
you really want to be contributing to an open source effort? Do you really
want to bet your project on something that's on the bleeding edge? Do you want
to build the superstar team required to make the NoSQL vision a reality? You
are not Google.

~~~
shin_lao
That point falls short. There are companies (such as ours) that provide fully
integrated NoSQL software and you don't have to worry about any details.

In addition, I'd say that any reasonably-sized database requires full-time
engineers to get decent performances (DBA in the case of Oracle).

------
bitsweet
"These companies hire top developers for their scalable (NoSQL) database
implementations and to keep them running...Do you really want to build the
superstar team required to make the NoSQL vision? You are not Google."

Wow - a salient remark about the state of enterprise software and what message
Oracle sees resonating with management.

~~~
anamax
Are you saying that management should want to build a superstar team to
support the DB?

DB operation is overhead. I can see wanting a superstar team to provide things
that customers value, but no customer cares about SQL vs NoSQL.

~~~
bitsweet
The reality is running software (proprietary or FOSS) is costly...A large DB
operation will be an expensive overhead regardless.

I wasn't commenting on SQL vs NoSQL and which will add more value. I was
making a remark on Oracle's insinuating tone "Your developers are probably
poorly skilled, your not going to change that, using new tools require new
skills, you'll fail at that because your not Google - don't even try"

Regardless of my personal opinions, what happened to striving for excellence?

~~~
anamax
> I was making a remark on Oracle's insinuating tone "Your developers are
> probably poorly skilled, your not going to change that, using new tools
> require new skills, you'll fail at that because your not Google - don't even
> try"

That "insinuation" is mostly true.

> Regardless of my personal opinions, what happened to striving for
> excellence?

Striving for excellence in everything is bad business.

Excellence is expensive. In many cases, the expense far outweighs the
benefits.

------
johnzabroski
There is some good information in this article if your ignore the Oracle
marketing message. It is basically a synopsis of the past 3 years of NoSQL
discussion.

What it doesn't mention is that everyone who picks NoSQL generally
acknowledges these downsides. So it doesn't do a good job explaining why
people still pick NoSQL.

TCO is probably the biggest factor I would have in picking NoSQL. As a
(Microsoft) SQL Server customer, we (developers) all hate the cost of scaling
SQL Server for each customer. Each customer needs their own resource
governance. This means either separate servers or a virtual machine, both tied
to a SAN. Virtualization MSSQL licensing costs are large without much material
benefit due to odd licensing strategies that negate most if not all financial
benefit to virtualization for small IT shops like us. By comparison, the
better we understand why customers use our product and the more engineering
decisions we can make (get away with?) then the cheaper technologies we will
be able to use (NoSQL, etc.).

~~~
Roboprog
Your TCO points sound more like a "commercial vs FOSS" argument than a "SQL or
not" argument. Care to elaborate or refine?

~~~
johnzabroski
I left out the part where most of our fetch operations operate on just one
primary key. The data structure is very stable and the need for different
kinds of analysis has disappeared after several years of refining what the
product does and should be. It's an analysis app that sets market prices to
hypothetical values and simulates that alternate reality. It provides very
fine-grained maximum likelihood explanations for why revenue would drop or
rise.

------
stickfigure
_"Go for the tried and true path. Don't be risking your data on NoSQL
databases."_

The document makes a lot more sense when you imagine the Samuel L. Jackson
character from Pulp Fiction reading it aloud.

~~~
Roboprog
Never saw Pulp Fiction. I remember SLJ giving a speech in "Deep Blue Sea",
though. Alas, I think that speech ended a little prematurely :-)

As an alternative, how about having (Simpsons) "Comic Book Guy" read it? (with
apologies to Steve Yegge)

------
sevenproxies
"As a result NoSQL databases may only have partial or no sql support."

Gee, thanks Oracle

------
dicroce
Yes, this document is FUD. Frankly, I'm surprised they released this... The
tone is: desperation.

That said, the NOSQL movement is so full of hype... It really annoys me that
whenever anything new comes around, a large amount of people want to use it
for EVERYTHING! NoSQL is inconvenient for a lot of what it is getting used for
today... In 5 years, we'll be past that and we'll see it used more
appropriately.

~~~
Klondike
I think that's a bit of a misread. Sometimes ravenous adoption comes from
something that legitimately makes 90% of cases easier. Once I tried MongoDB,
it effortlessly became my default for projects large and small going forward -
SQL would be a lot of extra work. NoSQL scaling well explains companies
adopting it, but it doesn't explain the masses of individual developers and
tiny startups jumping to it. That's explained by it being really, really
pleasant.

------
mbeattie
Oracle really doesn't understand FOSS in general or NoSQL in particular. One
of their points is that NoSQL databases don't have all of the advanced
features of Oracle database completely missing that the point is not to have
PL/SQL or secondary indexes but for simplicity and speed.

------
6ren
Oracle must be miffed: they built the first relational database (the first
implementation of Codd's paper), which largely replaced hierarchical databases
- i.e. NoSQL.

~~~
psykotic
> Oracle must be miffed: they built the first relational database

No way. What about System R? And there were probably others of which I am
unaware. Many of the now-standard RDBMS implementation techniques were
pioneered in System R. This paper has a good overview:
<http://www.cs.berkeley.edu/~brewer/cs262/SystemR.pdf>

~~~
6ren
Ah, I see; it was just the first _commercially_ available relational database
- at least according to wiki, it beat the commercial version of System R
(System/38) "by a few weeks" <http://en.wikipedia.org/wiki/SQL#History> I read
somewhere that it was previously thought of as nice theoretically but not fast
enough to be practical.

I'm actually very interested in what made the relational model so commercially
successful, if you happen to know more about it (it's hard to judge now,
because so many other features have been added and market standardization
etc). The mathematicians say it was because it's based on a mathematical model
- but that doesn't sound like it would be very convincing to pragmatic
benefit-oriented business buyers.

 _EDIT_ that pdf looks pretty good - I'll have a proper read of it when I get
the chance - thanks

------
DanielRibeiro
The best part of the article is the links. They also provide a competent
summary for some concepts, like CAP, BASE and PACELC.

They totally fail at argumenting them though, having a strong bias towards
their products. As expected.

------
jsr
Amazing that this post hits HN the same day Oracle announces "Oracle NoSQL
Database" ...
[http://www.oracle.com/technetwork/database/nosqldb/overview/...](http://www.oracle.com/technetwork/database/nosqldb/overview/index.html)

------
oacgnol
And yet at the same time, Oracle is trying to fold in NoSQL to its product
line. The idea of them trying to stymie NoSQL growth and using it at the same
time is laughable. They're starting to feel the pressure a little too late
now.

~~~
meow
May be they will produce a white paper on why Oracle's NoSQL is better than
other NoSQLs :)

------
KevinEldon
This is a marketing piece targeted at decision making managers or architects
who have to justify their decision to activist decision making managers. Which
is ok, Oracle knows who pays the bills.

------
cleaver
Sometime soon, Oracle will develop or acquire a NoSQL product and this
whitepaper will be buried. It will then be replaced by a new whitepaper to get
you excited about how Oracle's new product will revolutionize price and
performance for your web application.

------
latch
Interesting when you consider Oracle's recently announced NoSQL and big-data
plans:

[http://gigaom.com/cloud/big-data-startups-weigh-in-on-
compet...](http://gigaom.com/cloud/big-data-startups-weigh-in-on-competing-
with-oracle/)

------
bartz
The problem with NoSQL databases is that developers still do not understand
how to use them well. NoSQL requires relearning how to use a database. Many
developers misuse NoSQL databases, relying on the SQL patterns they know so
well. I think that's Oracle's main point here. For example, it's easy to have
a lot of round trips if you use NoSQL badly, but if you adapt and take
advantage of its strongpoints, NoSQL can easily reduce the query complexity.

The point of this paper is to scare Oracle's customers from switching to
NoSQL, and I agree that companies should not blindly switch from SQL to NoSQL
without the willingness to relearn and adapt.

~~~
Tsagadai
Everything in computing requires learning and relearning. If you hired, or
work with, developers who can't learn or adapt you have far more serious
problems than database choices to worry about.

------
wizzard
"NoSQL databases may only have partial or no sql support."

Really?! I never would have guessed. I mean, it's not like it's right there in
the name.

They go on to state that if you need RDBMS features, you should use an RDBMS.
My mind is being completely blown here.

~~~
rada
Nowadays, NoSQL is expanded to "not _only_ SQL".

------
justinhj
Some of the points are definitely worth considering. It's also a great
resource for links on NoSQL issues. I can't help feeling this was a project
for an intern however. It wasn't proofread very well.

"embrace asynchrony" - really?

"Clearly the traditional 3-tier application development model scales well and
the desired development model for established non-internet companies." -
there's a missing word here somewhere to make this a sentence

------
Calamitous
"Philip-Morris on why you shouldn't quit smoking"

------
smoyer
Oracle is correct when the bemoan NoSQL's lack of joins and relations ... so
I'm using CouchDB as my operational store and exporting the data to PostgreSQL
so that I can issue arbitrary queries. It took a little bit of work to make
the exporter understand that there might be missing or extra fields in the
CouchDB documents, but it was well worth it.

------
davesims
I guess that means they'll be sunsetting this guy:
[http://www.oracle.com/technetwork/database/nosqldb/overview/...](http://www.oracle.com/technetwork/database/nosqldb/overview/index.html)

------
roder
[http://www.oracle.com/technetwork/database/nosqldb/overview/...](http://www.oracle.com/technetwork/database/nosqldb/overview/index.html)

hipster oracle loves irony

------
7952
Why don't they just create a key value style API for Oracle? If people are
prepared to a lot pay for a database, maybe the same people will pay a lot for
NoSQL.

------
VladRussian
nice FUD (strange resemblance to the Sun's old FUD on Sparc vs. x86)

With all my respect to Oracle (and gratitude for that part of living i make
from it), they would better spend these resources on implementing a
distributed query execution (the parallel query implementation they have is a
joke really), and it would make their position vs. NoSQL much more stronger.

------
dlitz
TL;DR: OOGABOOGABOOGA!

------
cowmix
NoSQL? Nope.

I just need PostgreSQL and SSDs.. done!

------
hugacow
Wow, this is a huge fail. It should have started with graphs based on studies
of major customers that tried to make the switch and failed and why on the
first 20 pages, but instead it starts off by naming the leaders in the space
that use NoSQL. They've convinced me to use NoSQL now, because they couldn't
just shut up. Oracle, you screwed Sun, and now you are screwing yourself.

------
shareme
Hmm, hey Oracle Google got away with not buying your solution..I think others
will wise up to..

