Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Does anyone have experience with NoSQL databases (CouchDB, MongoDB, Google's BigTable, Dynamo, Cassandra...)? What was it like? Was it actual production/on the job experience?

What will happen to the relational databases in 5 years? 10 years?

share|improve this question

closed as not constructive by ChrisF Jan 30 '12 at 22:53

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

9  
If this ever happens, I will cry. –  Talvi Watia Sep 20 '10 at 1:15
16  
The screwdriver did not replace the hammer, though the main purpose of both is to hold things together. NoSQL and relational DBs are two different tools for two different jobs. –  webbiedave Oct 25 '10 at 21:40
2  
Short of it is that we now have the hammer (file system), the screwdriver (RDBMS), and the wrench (NoSQL). –  MIA Dec 29 '10 at 18:16
    
This could be off-topic. If you didn't commit for the DBA proposal, wait until next week to post this question on dba.stackexchange.com –  bigown Jan 4 '11 at 18:03
    
What will happen is that all fancy and useful new features are going to be integrated into the SQL language, which isn't strictly about relational databases. SQL has already integrated OLAP (star schema) and can deal with column stores ("NewSQL"). So, while NoSQL is often referred to as meaning "Not Only SQL", it will really evolve into "No, SQL" ;-) –  Lukas Eder Dec 15 '13 at 8:45
add comment

8 Answers

up vote 21 down vote accepted

I don't think so. Basically most of the NoSQL solutions seem to store key value pairs more or less. If you want to report on something, it is much easier to join a few tables together then to figure out how to string a whole bunch of key value pairs together. Also many of the products have their own API so the skills don't translate as well as SQL. Whether someone uses DB2, Oracle, PostgreSQL, MySQL, Mimer, SQL Server, etc. the general syntax of SQL is similar and the subset of ANSI SQL will work. Then you just need to pick up a few particulars. With the NoSQL solutions, just because you know how to use Hadoop and MapReduce does not mean that you can pick up Pig Latin in a day or two and use that....

Also with line of businesses, a big deal is the reporting. If NoSQL makes this harder, then it won't fly. In most companies information is power and there is huge value in being able to efficiently share that information. Basically you want the sales transactions to go into some type of data store where users can run reports, data mine, etc. to slice/dice/analyze that sales data and figure out corporate strategy.

One of the chief advantages of NoSQL now is price. Both DB2 and Oracle have shared nothing architectural solutions (I can't speak for Oracle but DB2 has had theirs since before 1999 and it worked pretty well at the time). But these cost a fortune in licensing costs. The advantage with Hadoop is that there are no licensing costs. Buy your 20 computers, download it, and go....Or just buy some Amazon Web Services instances, install a Linux image and use Hadoop to get going there...The Linux image that would enable you to use Hadoop is much cheaper than just the windows operating system on Amazon (without even the cost for SQL Server or Oracle).

Also NoSQL can be simpler for the programmer. There is no need to figure out a table structure in advanced to structure your data. Also you don't need to work hard to map your objects to the table structure, you can just store them as key value pairs. On the other side, these two advantages make it harder to report on. If you use not well defined structures, this presents challenges on trying to read the data later to report on. Also if the format is convenient for the program, you will spend a lot of time figuring out how to report on it as well. Nevertheless if you need to get a product out the door yesterday, the time saved might matter....

I think that NoSQL solutions are basically one more tool in our toolbox. And also they might force the open source database makers to focus more on scaling and shared nothing approaches. Probably we will see some of the more popular features make their way into relational database systems over time... This is similar to the way that a lot of relational databases now have data types and extensions for dealing with XML data while there was once talk of XML databases replacing relational databases. Now where are the XML databases? And yet the relational databases still remain in power....

share|improve this answer
11  
Why is cost such a big deal for NoSQL? Plenty of SQL databases are free. You don't have to use Oracle or MSSQL. –  alternative Oct 24 '10 at 0:22
3  
But not many SQL databases that scale properly are free. Also some of the vendors charge extra on clustering to enable scaling out. –  Cervo Oct 29 '10 at 3:18
    
which free SQL databases would you consider to scale well? –  user1249 Dec 29 '10 at 19:47
2  
MySQL claims to be able to scale mysql.com/why-mysql/scaleout/booking.html. Here's a thread on the issue at serverfault.com serverfault.com/questions/204700/…. Also from what I have seen, people have gotten PostgreSQL to scale mostly using custom solutions. Basically both are way behind Oracle/DB2's scaling and even MS SQL Server now has some support for horizontal scaling. –  Cervo Feb 21 '11 at 14:39
add comment

NoSQL puts the burden of managing your data directly upon the programmer to work with the information primitives whatever NoSQL database provides. Think of a relational database as a ready-to-use package of information management functions within its framework of storage and computation. Programming a NoSQL system is a lot like having the parts of a disassembled relational database and bolting them together into devices that provide the minimal amount of infrastructure required to implement a feature.

File systems are still here despite the existence of relational databases, so too will relational databases be here despite the existence of NoSQL databases. They're still a valuable tool for certain kinds of data. As computers get "larger" with available memory, bandwidth or disk space, there are datasets that could migrate away from NoSQL-style solutions back into relational, or perhaps, to distributed file systems that scale beyond what NoSQL or relational databases can provide.

share|improve this answer
    
I've never really liked the CouchDB principle: "All of your data entries are separate objects floating in space. Organize." –  TheLQ Sep 19 '10 at 21:11
    
I don't mind it as long as I'm able to retrieve the information back from its position in space. More often than not, the organization of those objects are also "separate objects floating in space." It's a matter of deciding what's important to your application, defining it and staying consistent, whether its stored in a file system, relational database or NoSQL database. Consistency makes the difference--but I'm unsure if I'm ready to try and use the MapReduce as the hammer upon everything in a NoSQL database like CouchDB does. –  Wxfz Sep 19 '10 at 22:10
add comment

Not anytime in our present careers. SQL syntax may change a few more times, but the relational model is a strong one, and SQL is a sufficient API (yes I said API), and without a fundamental computational database shift, I think SQL or it's children's syntax will be here for a long time.

2008 was the last year that I was directly involved with FORTRAN (77 actually). That's like 40+ years.

share|improve this answer
add comment

Will the equation 2+2=4 be outdated and replaced by 2+2 > 4 or 2+2 < 4 ... any time soon ?? The Relational model is not just a technology. Its based on Relational Calculus and Relational Algebra... whose foundation is the very heart of mathematics : The Set Theory. The operations like filtering, joins, projections ... on relational data that SQL exposes are not mere system calls. They are in league with addition , subtraction, multiplication etc.
File systems might be replaced by some other storage abstraction, object oriented programming might be superseded by some X oriented programming paradigm, even the very act of computer programming itself might not be there but forget about mathematics being out dated for at least a hundred years from now.

share|improve this answer
10  
You're using new math. I prefer II + II = IV. –  Richard Morgan Dec 29 '10 at 21:12
    
Still, don't forget that in the past when people needed a logarithm or value for sine, they would look them up in tables. Now the calculator/computer implements numerical methods to evaluate the equations on the spot (sometimes even evaluating the power series...). Also as people find new ways of doing things the old fall out. E.g. would you use the trapezoid rule to compute a numerical integral, or would you use Simpson's rule... For testing primes you'd probably use Fermat's primality test. –  Cervo May 7 '11 at 21:00
add comment

Current relational databases are not purely relational but spoil relational algebra at several places (NULLs, duplicated rows etc.), so referring to the relational model to defend relational databases is no valid argument. Nevertheless relational databases are popular for good reasons. There will just be some more special types of databases or additional DBMS features to choose from. @Cervo already mentioned how XML got integrated into SQL, it was the same with object orientation and OODBMS. Because in practice "relational databases" are not truly relational, they can simply incorporate other features if needed.

Asking for SQL: I wish that it would go away, to be replaced by a standardized language. Just now it is more like a bunch of dialects and every DBMS interprets a different subset in a slightly differently way. As far as I know SQL-92 was the last standard thanks to the NIST test suite.

share|improve this answer
add comment

Relational databases will eventually fade away, and SQL will fade with them, but I do not expect this to occur any time soon. The relational database model, for all its warts and foibles, is "good enough" for many applications - it's the right-sized hammer for the nail of "how do I easily store my data". It's reasonably easy to understand and work with, and there's plenty of implementations. So if your question was an indirect way of asking "Do I really have to learn and understand SQL?" the answer is "Yes". :-)

Share and enjoy.

share|improve this answer
add comment

There are too many NoSQL solutions for all of them to succeed. All the ones I have looked at are flawed in some way. The main issue is infrastructure, the next issue is reporting.

Right now I can hire a professional with SQL tuning expertise. There just aren't the numbers of those people with NoSQL expertise. Reporting is a mess and normally requires lots of hand written code. People will start to build JDBC drivers etc for NoSQL and suddenly they will look like ... databases.

What NoSQL will do though is to force the SQL vendors to improve their products. Expect to see NoSQL style APIs work their way into major vendors products in a years time.

Oracle/Sybase/MS should embrace the NoSQL movement. It will allow them to lock people into their products with custom apis!

The lack of a defined schema is attractive when you are starting up, its a mill stone when you are consolidating code. Most developers have no idea how to build an evolvable data model and the lack of a schema will cause major issues.

share|improve this answer
add comment

NoSQL-databases definitely have a place in the software world. But it will take a long time, if ever, for them to replace traditional RDBMS:es. In the mean time, use them for what they're good for.

The most interesting type of NoSQL (which can mean "Not Only SQL" by the way, a much better name in my option) is the graph database where data is represented as nodes and relations (edges). It lets you model Facebook-type who-knows-who-relationships in a very efficient way.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.