Cloud proves that OldSQL is still cool As the IT world scrambles pell mell into the cloud, veteran vendors like Oracle are having to figure out how to make money in an IT market that is increasingly turning its back on traditional software licensing. While Oracle has faced down challenges to its core database business before from open source, the cloud presents an …
As an employee of a stodgy old traditional company, I can tell you that we have no plans to move to NoSQL on the grounds that we would have to adopt a whole new set of applications. We arguably need to crunch big data (sorry, Big Data), but the applications to do so in our type of business are simply not there. By the time they are there, the rest of the world will likely have moved on to something new, leaving all the NoSQL developers to recode their apps into the Next Big Thing.
it means "whatever the fsck we want it to mean while we break various guarantees that SQL RDBMSes usually deliver in creative new ways, for we crave speed more than anything".
It's cool and exciting technology if it fits your niche (and you know what you're doing). As a general data storage provider it's data corruption and data loss misery itching to strike.
Saying "not only sql" implies it is more, but while in certain senses it is, in others it is not. In particular, it's taken some rather fundamental safeties off. If you make your decisions based on this sort of platitude, then this backronym is nefariously misleading.
Recently worked through "introduction to database systems" (standford online course), and while really just an introduction, what it explains about what relational databases deliver combined with a little thought and realisation about where nosql compromises for its gains, it ought to be blindingly obvious that "nosql" is inherently incapable of replacing all that rdbmses deliver. We're talking specialised tools for specialised purposes with specialised and tricky tradeoffs.
So it becomes curious that those who need databases on a level technical enough that you really ought to understand this need to have this explained. Then again, for a web2.0 crowd weaned on mysql, that is maybe understandable, if not so much excusable.
The idea that NoSQL would ever kill RDBMS for all purposes is just another round of hype-driven ignorance. It's another technology that all DBAs and DBMS developers _should_ learn so that they can incorporate it into their projects where it's applicable, and relational where it works best. It fills a niche that was incredibly hard to work with regular SQL, and NoSQL grew out of the lessons learned there, but it will always be a niche more suited to analyzing metrics than building web sites and other perfectly boring uses that RDBMS works great for. (That isn't to say that something else couldn't come along that does boring data storage and retrieval better, just that NoSQL isn't it.)
but I've often felt the rise of NoSQL, in particular columnar databases and key/value object stores, is also related to the use (over use) of automated development strategies, namely auto written ORM/DataAccess layers. These will find much better performance when storing a serialized object in a key/value store as opposed to storing each field nicely in it's own typed column. Some systems I've seen have hugely terrible performance when using RDBMS's as the back end store because they effectively issue trillions of single row selects as they build up the objects to satisfy a multirow "query", when they *could* have leveraged the SQL language to get the same job done directly against the RDBMS, but for whatever reason didn't.
I'm not sure that the correct fix for such perf and throughput issues is rejecting the relational paradigm... perhaps the data access layer needs to be more intelligently written with respect to set based operations.
Or perhaps I'm a dinosaur who hates change?
Using a DBMS that specialises in gathering up the full result set efficiently and then having to put a lot of work into gathering up your single value queries efficiently, means you're doing a lot of work (requiring a lot of coding effort, long code paths, and complexity) to optimise one side of the interface for the sake of the other side, twice.
Thus the conclusion should be obvious: If your usage patterns suggest a key/value store then you'd better use that instead. Why that conclusion wasn't reached is a little beyond me, but then in computing it is in fact normal and accepted for people to get a little carried away with solutionising into ever more complexity.
(Also, neither possessives nor plurals get apostrophes, thanks.)
The problem of NoSQL database is that they have an "application view" of data. On the other hand, RDBMS have a "data view" of them, in no way tied to an application representation of them. That could make the less efficient in some situations, but also make them more "resilient" to changes.
Application comes and go, while data stays (and live) for much longer. The real value is usually in the data itself, not in applications using them.
Underneath exist physical files and indices, to which your RDBMS is an overlay. You can certainly have a transaction monitor without an RDBMS. SQL's origins are from the days of Code Generators, where the idea was to provide tools so that people who were totally ignorant of computing could write their own applications. Code generators have mainly died their deservedly loathsome deaths, but SQL managed to get itself firmly embedded based mainly on marketing and it's real ability: which is to generate quick one-off queries. If you know what you are doing, you can successfully bypass most of SQL features and costs on most transaction processing systems. Which is definitely the way to provide service to customers in real applications. NoSQL is an attempt to store unstructured data for later definition and use. Basically, it's BLOB with an index. You could more easily do most NoSQL tasks with flat files and an index to them. Another way to look at it, is that NoSQL is for people who don't understand what a log file is.
Let me ask this: do you want your financial transactions to be done using the latest NoSQL or a proper RDBMS? What about the software behind what the pharmacist is using to check for drug-drug interactions? And if the the police are searching for a murder suspect who has your name, which do you hope they have dealing out data?
OTOH, if you have a quicky web site to put up, do you need a full-blown Oracle application? If you are researching something and the data is incomplete and non-orthogonal, is cramming that into an RDBMS the best use of your resources (time/people/money)?
There are certain times when NoSQL makes sense; it does in the products my current company is creating and supporting. And there are times when you need to have a proper RDBMS. The idea that RDBMSs are going away soon is ridiculous.
Indeed. The Dwight Merrimans of the industry have always made sweeping claims about how their favorite technology will displace some related established technology, and time and time again they've been shown to be foolish. Remember the 1980s, when OO databases (and then OORDBMSes) were going to completely replace existing relational databases? Or a decade later, when the next generation of that particular species of idiot was telling us that soon it'd all be XML databases?
Different kinds of data and different application requirements mean no single data management architecture will be optimal for every application. You'd think that would be obvious.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
