NoSQL Zone is brought to you in partnership with:

Mr. Lott has been involved in over 70 software development projects in a career that spans 30 years. He has worked in the capacity of internet strategist, software architect, project leader, DBA, programmer. Since 1993 he has been focused on data warehousing and the associated e-business architectures that make the right data available to the right people to support their business decision-making. Steven is a DZone MVB and is not an employee of DZone and has posted 139 posts at DZone. You can read more from them at their website. View Full User Profile

NoSQL -- Old Wine, New Bottle

07.28.2010
| 8253 views |
  • submit to reddit
Got an email with links about NoSQL. Links like "Going NoSQL with MongoDB". This -- like many such articles -- includes the phrase "the NoSQL movement" as if there's something new going on. Thank goodness Ted Neward includes quotes around "new". This isn't new. And doubly good, Neward doesn't use words like "excitement".


Some folks like to link to http://en.wikipedia.org/wiki/NoSQL. This is misleading, of course, since avoiding SQL isn't new or even that interesting. If you're going to treat avoiding SQL specially, then you should have a NoProceduralProgramming, NoFunctionalProgramming, NoAssembler, NoShellScript and NoHTML movements, also.


Why stop there? Why not have a NoDumbAssArchitecture movement, too?


If you want to see dumb, breathless stuff, however, use Google and search for "nosql excitement". You'd think that the file system was new technology. In particular, posts like "NOSQL Movement - Excited with the coexistence of Divergent Thoughts" seem silly.


Unless -- I guess -- you've been solving all data management problems with a relational database. I guess when you discover that you don't have to use the hammer, then it's exciting to see that everything isn't simply a nail, either.


If avoiding the hegemony of SQL seems important, or even interesting, perhaps you've been living in a cave. Seriously. The file system has always been there and has always worked nicely for lots of problems. My 2002-era Ralph Kimball Data Warehouse Toolkit books are very clear that large, high-volume data warehouses are mostly flat files. Data marts are SQL databases suitable for ad-hoc SQL queries. But the RDBMS isn't always the best place for large volumes of data.


Bottom Line


NoSQL isn't new or even very interesting.

Consequences


If you're an architect, but you're not looking at alternatives to the RDBMS -- and running benchmarks to compare the choices -- you're not really doing architectural work. You're probably a glorified programmer and should consider working in a place that doesn't stifle you by imposing a "one world -- one architecture" viewpoint.


If you're a manager and think that "everything in SQL" is a risk-reducer, you need to actually talk to your people. If you think that your people's skills are limited to SQL, you're doing your team (and your customers) a disservice. Consider a skill upgrade of your own. Your team can learn other non-RDBMS technologies. Perhaps you should stop stifling them.


If you're a DBA and you know -- for a fact -- that the relational database is perfect and complete, you should perhaps pause a moment and consider things the relational databases don't do well. Graph-theory problems and hierarchies require fairly complex workarounds. Even a many-to-many relationship requires this extra association table. Perhaps those things are the signs of force-fitting data into the RDBMS model.
References
Published at DZone with permission of Steven Lott, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Fabrizio Giudici replied on Wed, 2010/07/28 - 8:35am

The following statement doesn't make much sense to me:

If you're going to treat avoiding SQL specially, then you should have a NoProceduralProgramming, NoFunctionalProgramming, NoAssembler, NoShellScript and NoHTML movements, also. 

Well, I don't do Procedural - I might do Functional, but I don't, in any case I don't see why I should hate it - I'm doing no more Assembler, nor ShellScript. I don't like HTML 5 etc..

But independently of my or others' personal preferences, SQL is different from the other technologies because 1) it has been there for decades and 2) it creates one of the biggest problems around which is OO/RDBMS impedance. So there are objective reasons, IMHO, for SQL to attract most of the "hate".

Of course you're right that people shouldn't jump into the dark and, above all, not because of fashion. I suppose there are in the world architects who go NoSQL with salt in their mind and others who don't - but this indeed applies to many other architectural choices, we're just telling that there's smart people as well as dumb people around.

My personal take with NoSQL is that I don't like the static RDBS schemata - so when I can I go with a RDF store, which in turn relies on a RDBMs. So I have classic ACID, but I don't see SQL any longer and can enjoy a persistence mode which is closer to my "concepts". I reckon that this is a minority view of NoSQL and that most people talk about the filesystem, which is a more drastic change.

In the end, it might be hype as well and perhaps in a few years it will be over (I don't think so, BTW - probably there will be a selection and many of the current products will die, but a few will survive and get to success). But it 's good that after decades people look around and try to discover whether it's possible to change an old way to do things.

Suck NR replied on Wed, 2010/07/28 - 9:30am

I think you've misinterpretted the meaning of "NOSQL" it's not "No SQL" it's "Not Only SQL", therefore your "NoDumbAssArchitecture" is actually "Not Only Dumb Ass Architecture" probably not what you meant.

 Yes the idea of using other mechanisms of persistence, namely the file system, have existed for years but what has happened is that due to de facto standardisation and corporate thinking file systems and SQL databases have become generally the only acceptable options.

The NOSQL is driven by the emergence of more "enterprise ready" Non-SQL databases and seeks not to replace SQL but to say "hey look there is no good reason why we should have to stick our graph data in to your SQL database when a more specialised and separate graph db can sit along-side". The reason why this is somewhat radical is because of the complexities of transations when operating on more than one database at a time. Hence all the talk about "eventual consistency".

 IMO the NOSQL movement is not about changing the technologies we have but trying to be able to use the most appropriate one when needed and not be bound by some senseless IT systems policy to a single brand/type of db.

Jilles Van Gurp replied on Wed, 2010/07/28 - 12:32pm

Nosql is a bit misleading as a term. It suggests it is all about the query language. Which is not the case at all. Most nosql users couldn't care less about the query language. As in they don't care about paying in terms of throughput, performance, scalability and operations for features they don't need to begin with that you get with typical SQL databases. As in, they really don't want to compromise on any of those. 

What it is about is fast, atomic read/writes on gigantic data sets  where data is sharded and replicated with zero fuss across machines and data centers and even continents. Nosql is jumping in the vacuum left by commercial SQL products that are purpose designed for enterprise usage, which is quite different from the needs of most web software.

Simple example. We run a service with a shitload of data that needs to be provided world wide to hundreds of millions of users with decent latency. That means we require multiple data centers world wide (simply because the latency from where I live to Australia sucks). Of course we want to have failover in each of the data centers so we don't go down because of a single machine failure, and between the data centers in case of bigger trouble. Additionally our dataset does not fit on a single machine to begin with. So we need sharding, replication inside and between datacenters, failover, etc. We can't really afford to have down time. Twitter style fail wales are not something we want to implement.

Do we care that inserts in Europe are not immediately visible in Australia? Not really but we expect Australia to catch up eventually. Do we care that out database is in a consistent state when we read it. Eh yes. So we got sort of a relaxed consistency constraint here. We want consistency but we don't see a need for immediate consistency. Do we do transactions across data centers? Not really. Do we need transactions inside a data center. Actually, all we want is that we get consistency when we read. And non corrupted data. What if bad stuff happens? Well we don't want to go down and we want to recover to a consistent state and if we can avoid/minimize data loss that would be great as well.

Non relational data stores have been around forever. That's because there has always been a need for fast, non relational storage. Nosql is about introducing this type of storage where it was previously missing (or at least not very common): the network. For example, couchdb style eventual consistency is quite a novelty and I'm pretty sure it has not been attempted at the scale e.g. Ubuntu is using it (i.e. replicating between their servers and all their  tens of millions of end user installations).

Nosql is pretty much accepted across the industry. People don't put their geographical data in SQL databases but in GIS systems. CAD systems have never really depended much on SQL. People don't store spreadsheets in a SQL database but use some proprietary in memory datastore + binary or xml file format. People don't store wordprocessor documents in a SQL database. When it comes to storing stuff, SQL databases are pretty much restricted to the enterprise and very specific application domains. There's a reason for this: most SQL databases would be a pretty bad match for the requirements of any of those. The same is true for many modern web applications, or indeed enterprise applications.

Fabrizio Giudici replied on Thu, 2010/07/29 - 3:38am

When it comes to storing stuff, SQL databases are pretty much restricted to the enterprise and very specific application domains. There's a reason for this: most SQL databases would be a pretty bad match for the requirements of any of those. The same is true for many modern web applications, or indeed enterprise applications.

I beg to disagree strongly. SQLite is used by: Firefox, Thunderbird, Apple Mail, Safari, Google Chrome, Apple Aperture, Adobe Lightroom, iTunes, the iPhone/iPad/iPod, Android, perhaps even Skype, and as far as I know even some high-end Symbian phones. SQL is pretty pervasive and thanks to iPhone and Android it will be more and more in future. This doesn't surprise me because desktop and mobile applications are more and more demanding, must crawl high volume of data and people appreciate the consistency. Now it's really a matter of using the proper words: I appreciate a lot the ACID part of SQL databases. What I don't like is precisely SQL and the relational data model. That's why I'm constantly repeating that NoSQL at least means two families of use cases.

Rehman Khan replied on Sat, 2012/02/25 - 3:47am

NoSQL is a marketing brand, not a technology or architecture term. All the hype and "newness" and "excitement" makes more sense if you view it in this context.

As for many-to-many tables, this is not a good example of "force-fitting".

Take for example regular expressions. Making a regular expression to match any problem you throw at it is really easy! Here it is: .*

The hard part is making a regular expression that matches your valid input, but also rejects invalid input.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.