Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Tue, Dec 7, 2010 at 11:13 AM, Mark Woodward <markw-FJ05HQ0HCKaWd6l5hS35sQ at> wrote:

>  On 12/07/2010 10:41 AM, Matt Shields wrote:
> I think the NoSQL term "eventually consistant" sums up why it should not be
> used for all situations.  They say that eventually all data will
> be committed, but if your bank was running a NoSQL database and you just
> deposited your money and expected the transaction to show up when you looked
> at it from your phone and didn't see it there and they told you your account
> would be "eventually consistant" with what they were telling you, would you
> be happy?
>  How about an environment where you have to make sure that transaction 1
> is processed before transaction 2.  From what I've read about NoSQL, they
> cannot guarantee that.
>  Sure, sites like Facebook and Twitter where you have status updates and
> profiles, this is the perfect place to use NoSQL.
> I don't want to come off as a member of the anti-NoSQL  (head spinning from
> negativity :-), but generally speaking, and this is understood to be a major
> generalization, NoSQL advocates don't really seem to get the depth that is
> involved with mature SQL databases.
> Data access, searching, indexing, concurrency, consistency, caching,
> ordering, gathering access statistics, etc. are complex problems that have
> been studied for years, and the results and knowledge gained by, who knows
> how many man-lives of research, is embodied in products like PostgreSQL,
> DB2, Oracle, etc. Dismissing them because they are "old" is like dismissing
> algebra because it is an ancient egyptian math construct.
> You brought up three very important issues: durability, atomicity and
> consistency. The idea that data is reliably saved, that specific
> transactions are performed individually with data in a known state and in
> the correct order. People have spent years studying how to do this well. You
> can trust a mature sql database to do this quickly and efficiently. This
> very difficult set of problems have been solved for you. Don't abandon these
> amazing systems because of a perception of oldness or being out of date.
> Regardless of whether or not you think you "need it," having it will make
> development easier because your data will be predictable.
> There is a huge segment of the data storage environment for "NoSQL" type
> systems, but as I said, the preference should be toward using mature SQL
> systems for data and only after you've evaluated the problem as not being
> doable in SQL, then you should employ other systems, not the other way
> around. A SQL database either solves or provides facilities to solve an
> uncountable number of problems that a modern web site will encounter. The
> NoSQL systems merely claim that they scale better, and by scale, I mean they
> abandon "known good practices" in data management in favor of potentially
> more risky ones which may perform better.
> -matt

Nor do I.  I'm not against NoSQL, but I've seen a lot of people who are in
charge of projects I have direct say in jump on the latest technologies (not
just databases) without understanding what happens underneath just because
they want to work with something new and cool.  I'm not a dba, I'm a
sysadmin, but understanding databases has helped me immensely when it comes
to dealing with people who want to try out every cool toy that comes along.
 And that goes for all the latest technologies, not just new database types.

I've also noticed part of this trend is contributed by developers now trying
to become their own sysadmin because they can now auto-provision their own
wants with services like Amazon Cloud.  They then show this cool new toy
they have to upper management, who likes it.  Then when they deploy it, it
crashes and burns because they haven't thought through the whole environment
and how it will be impacted by actual load.  It used to be that they would
work with operations departments to help draw up requirements, now they're
going around us.


BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /