NoSQL is designed to address a certain problem space and RDBMS is designed to address another.
I don't see it that way at all.
It's more like RDBMS is the all-purpose data store that attempts to distill the maximum number conceivable data storage, integrity constraints and lookup requirements into a set of powerful primitives. And NoSQL is a large group of technologies that are each optimized for specific cases which SQL is traditionally bad at, but which don't necessarily have much in common with each other.
I agree with this, but I'd add that we developers tend to make an RDBMS do everything because it's what they're familiar with. NoSQL is an alternative to solve a specific problem, but you can't see that problem if you're ignorant of it.
It's like my experience with SVN vs Git. I didn't know how useful and more efficient my workflow would be if I used branches, so I never saw why Git was useful. Sure I could branch in SVN, but it was way more work. I got involved in a project where I had to use git, and I learned how branching works, and now I use it all the time because I understand where it's applicable.
I don't think you have to choose MySQL over MongoDB. I think you could be very happy using both, each for its purpose. You don't always know why you need something until you need it. It's always good to keep an eye on what others are doing.
The same argument about branches in source control can made about SQL itself. In my opinion, a large number of developers don't know how to code SQL properly and a lot are afraid of it. They end up using an RDBMS as nothing more than a dumb bit bucket -- often hidden behind increasingly complex abstractions. The NoSQL movement, unintentionally, lets these programmers feel superior about their lack of knowledge.
I don't want to argue against the legitimate use of NoSQL solutions. I just don't think there are enough use-cases to justify the hype. For example, an article was posted here last week about using NoSQL solution to store e-commerce orders.
I disagree. Lots of applications only require dumb bit buckets. There is no real sophistication or structure to the data. Anything more is over engineering for a large majority of products which data storage is not particularly useful or meaningful.
I worked on a system a couple of years ago where we ran calculations nightly and then we write the results of this calculation to a row in a table for caching purposes. This row was then fetched by another job to generate a PDF. We used SQL for this because Reporting Services could build a pdf from a row in a table.
It's not a good solution. This type of data doesn't need to be searchable. It's using a database server as a caching mechanism. That seems wrong. Seems like memcached, mongo, couch, or anything else would have been better.
Heck, people have been using memcached for a long time, and yet all of a sudden people don't see a use for NoSQL setups?
Are we sure we're not just doing the same old "Defend what you know" dance?
An excellent comparative case in point that in my opinion actually undercuts what you are asserting.
You do not lose features and functionality in that transition (where as noSQL is by design reductive), and further, Git is a replacement for SVN and not a complementary tool.
Actually you do lose functionality by going that way. SVN handles binaries better. I can also cherry-pick files from a directory structure, so if I need to fetch out a subfolder or an individual file, I can do so. With Git I must clone the repo or set up a web service so I can get access to the file system. But they're different tools for different audiences. In my environment, I do use both of these tools together.
The lesson Git, Ruby, Subversion, Apache, and many other projects have taught me is that instead of saying "What I have is fine, I don't need what you have", I need to ask "Why do you use what you use, why does it help you, and how might it help me?
The whole idea with "NoSQL" is that you pick the best tool for the job. Most people that push RDBMS solutions try to shoehorn an RDBMS for every possible scenario. For modeling the majority of business data, an RDBMS is fine. There are many problems such as graphs, logs, lossy real-time data, etc that CAN be modeled in an RDBMS but shouldn't be.
I largely agree with this, but in my mind using an RDBMS for a sub-optimal task is not always shoehorning—it can be a powerful hedge. In an early stage startup you don't know what the final business model is going to be, or how your data will need to scale. Spending time researching and setting up optimized data stores for things that change drastically or never end up being important is a tremendous waste of time.
I suppose it could also be said that spending time designing relational schemas that will change drastically, then migrating data every time they do, is wasteful. Many non-relational databases allow quite a bit of flexibility in terms of incrementally changing structure as you learn about your business needs.
Not that I am in one camp or the other. We use both relational and non-relational databases where it makes sense. The more of each (both in choices and users), the better, so far as I am concerned.
That's a really good point. Saying that NoSQL is about picking the right tool for the job makes it easy to dismiss. There are lots of programmers out there that just refuse to look at any other tools than the very small set that they already know. I think it would be beneficial to change that attitude across the spectrum of programming tools.
Both are in nearly every dictionary around. And given the base of "ubiquitous", I prefer adding a "ness" to denote a quality, which is extremely common in English and can even be applied to words that don't normally accept it, so it's an easy cognate. Something being cheesy == has cheesiness. "Ubiquity" is more of a hacked form of a word, as it removes from the base word.
Though I admit it's shorter, thus may eventually achieve ubiquity over ubiquitousness.
Not to continue the content-free let-me-fix-that-for-ya sniping you're answering, but "ubiquity" dates back to 1579. It's a nice, old word, not a hack or neologism.
Nonetheless, both words are entirely proper, acceptable, and clear.
>Most people that push RDBMS solutions try to shoehorn an RDBMS for every possible scenario.
I don't think that's true for well-informed developers in a space where NoSQL is acceptable.
It might be true generally only in the sense that most developers don't know or care about NoSQL and don't like the idea of learning something new. That's to be expected; most of these guys will never leave .NET/Java and the blessed toolkits associated with each. They are corporate programmers and they don't really count.
A well-informed person might make some good social arguments against NoSQL adoption, like the lack of experienced available developers, or the relative immaturity of the respective codebase, or other issues that surround emerging platforms. These arguments will sometimes hold merit.
Otherwise, I don't know why one would be averse to the implementation of a "NoSQL" datastore for information like logs. I know that I've always having logs in the relational db.
I haven't met many experienced, decent developers who shun NoSQL when there is a good technical and environmental atmosphere for its implementation. I don't think it's a widespread thing.
What it boils down to is choose the right tool for the job and sometimes that means using two tools that do similar things. I for one won't be giving up SQL any time soon but also look forward to replacing some of our poorly performing sections with NoSQL (we sort of already do thanks to memcache).
I can't help but see this post as the blog equivalent of the guy trying to keep people from fighting in the real life, at the same time trying to draw attention to him, and at how mature he is.The article has almost no content at all.
I have that wish for humanity: I'd really like people to use words that are in proportion with what they describe.
Things like: "we're dead" (when we just talk about loosing a contract or even closing one company), "it's totally catastrophic" (when someone cannot make it to a meeting, or the vegetables you had planned for dinner are not available anymore at the groceries).
Come on.
Talking about "worst holy war" for tooling trends - sorry, not for me, even for the purpose of creating a catchy headline or of underlining a point.
Oh and yes: I use both NoSQL and SQL, sometimes in conjunction in the same system.
>I use both NoSQL and SQL, sometimes in conjunction in the same system.
As any sane developer would, and without having to go all-or-none either which way. I don't understand the people who are balls to the wall for either side. They both have a purpose.
The fights around "tech X is better than tech Y" usually boil down to some kind of fear (of being replaced, of loosing the job) or biaised-validation of all the effort already invested in X.
I think the article used "worst holy war" in the sense of "lamest". The (No)SQL "holy war" is just as dumb as any other computer-related "holy war" throughout our industry's short history (e.g., emacs/vi, Windows/Mac/Linux/Unix). It's as dumb as the arguments about who the best Captain of the Enterprise was.
Recently I've researched all NoSQL databases(grpaph oriented to be precise). We're building a project which I think fits best in NoSQL solution.
And I did not find any suitable solution.
Either it doesn't a have client api(we're using .NET) other then REST or plain TCP/IP (and of course I don't have time to create my own API)
Either this is just some project more like a school homework.
Do you seriously believe that you can rely your business solution which will run across dozen of PCs on someones experiment?
I actually think this says something interesting about .NET v.s. open source platforms. The new batch of NoSQL products are being developed almost exclusively in the open source world - they're written to run on *nix (Windows support, if it exists at all, is generally an after thought) and the client libraries that ship with them target the open source languages first. In this particular case, it feels like closed-source platforms are second class citizens.
I'll hazard a guess that one reason for this is that NoSQL systems are mainly designed for scalability, and free operating systems are significantly cheaper to scale than platforms with a license fee per node.
I don't understand the problem with the client apis. If you're working with .net, you should have access to an xmlhttprequest library. Building and reading xml to talk to a REST api shouldn't require a specific API library. Unless of course you're just looking to avoid that step altogether and would rather just point, click, drag, and drop and get on with it.
Another problem is deployment, if I adopt some RDBMS system to my needs, then I already have a bunch of web hostings supporting this type of DB or I can use installer to deploy the DB, run a few scripts and everything is ready to run.
Deployment isn't the issue with these - deployment can be automated just as easily as an RDBMS. Sometimes easier. It's trivial to throw up several instances of MongoDB for example. As for hosting solutions that support this stuff, well, I prefer VPSs that I control to shared hosting with Mysql for anything that's serious.
But you and I appear to have very different needs.
I prefer VPSs too, but if you aim wider auditory you should at least try to support web hosting. With RDBMS it is easy. And with NoSQL it is almost impossible. Maybe this is just a matter of time, when NoSQL will be as much widely used as MS SQL for example, then maybe you will be able to use MongoDB in a web hosting.
But if one of the purported values of many NoSQL technologies is their benefit to scalability, and you are using this tech in your application because the app needs to scale, then does it make sense to deploy this ultra-scalable app on shared web hosting (regardless of whether they support NoSQL tech)?
Deployment with, e.g., Neo4J involves simply telling the Neo4J library which path to use for its binary data files at initialization time. It finds a DB if it's there and uses it, otherwise it creates it. Applicable line of code from their wiki:
GraphDatabaseService graphDb = new EmbeddedGraphDatabase( "var/graphdb" );
Of course, Neo4J is an embedded solution. It's quite different than using a separate server application.
This is simply not true, if we're talking about horizontal scalability (which is probably the most relevant kind of scaling these days, because it's the most cost-effective).
You can't add more nodes to an RDBMS, keep ACID, and get linear scalability. You just can't.
From what I know of CouchDB, you could scale it linearly if you manage the partitioning of data yourself according to load. But if your data distribution changes you're a bit screwed. My impression though is that most people just use CouchDB on a single machine.
For BigTable, on the other hand, it really is just a matter of adding or removing machines at any time and getting nearly linear scaling. The load is dynamically balanced between machines, so this is actually practical.
Are there ways of scaling an RDBMS architecture? Yes, but they involve giving up ACID (like having read-only replicas, for example).
So I'm not saying RDMBS's are bad, just that there is a real limitation here.
That's quite an interesting point - if you restrict holy wars to the "my imaginary friend is better than your imaginary friend.... fight!" kind then you are probably correct.
I'm trying to think of other real "holy wars" - the 30 Years War is perhaps the only other major one I can think of. I guess most other "holy wars" are really justs lingering fall out from conquests Ottoman invasion of Europe, Ireland, .....
The Ottoman Empire was religiously tolerant and motivated by conquest as well. (The irony of the 20th century is that if the empire could have staved off its breakup for just a little longer, they would have had Iraq's oil wealth to back them up and very well could have developed into a modern superpower.)
A point, re muslim expansion to the Balkans. But still, just the Spain/Persia/Iran expansion makes the Crusades look like a tea party with centenarians.
But where the Ottomans religiously tolerant in all periods?
It seems the Turks where really disliked by their subjects (both in Middle East and in the Balkan), where did that come from, then?
I declare "O rly?" vs "Ya rly" the worst holy war ever.
Neither side will ever give an inch, and vast armies of anonymous have lobbed internets at each other, killing a few StarCraft players in Korea and memeing millions upon millions more, with more arriving every day.
