Recently I was asked:
Why is NoSQL faster than SQL?
I didn't agree with the premise of the question... it's just nonsense for me personally. I can't see any performance boost by using NoSQL instead of SQL. Maybe SQL over NoSQL, yes but not in that way.
Am I missing something about NoSQL?
There are many NoSQL solutions around, each one with its own strengths and weaknesses, so the following must be taken with a grain of salt.
But essentially, what many NoSQL databases do is rely on denormalization and try to optimize for the denormalized case. For instance, say you are reading a blog post together with its comments in a document-oriented database. Often, the comments will be saved together with the post itself. This means that it will be faster to retrieve all of them together, as they are stored in the same place and you do not have to perform a join.
Of course, you can do the same in SQL, and denormalizing is a common practice when one needs performance. It is just that many NoSQL solutions are engineered from the start to be always used this way. You then get the usual tradeoffs: for instance, adding a comment in the above example will be slower because you have to save the whole document with it. And once you have denormalized, you have to take care of preserving data integrity in your application.
Moreover, in many NoSQL solutions, it is impossible to do arbitrary joins, hence arbitrary queries. Some databases, like CouchDB, require you to think ahead of the queries you will need and prepare them inside the DB.
All in all, it boils down to expecting a denormalized schema and optimizing reads for that situation, and this works well for data that is not highly relational and that requires much more reads than writes.
The thing you are missing about NoSQL is that NoSQl cannot be compared to SQL in any way. NoSQL is name of all persistence technologies that are not SQL. Document DBs, Key-Value DBs, Event DBs are all NoSQL. They are all different in almost all aspects, be it structure of saved data, querying, performance and available tools.
So if someone asks you such question on interview, this should be the answer.
'NoSQL' (or more precisely: non-relational) databases give up some features of the traditional databases for speed, but more importantly for horizontal scalability.
The missing features depend on the concrete product, in general full ACID properties or even join operations are not supported. That is the price for the increased performance.
You're right, it would be nonsense to state that in a blanket statement. Which is probably the whole point; instead of a single answer, the interviewer is probably expecting you to reply with questions to help you figure out what the context of the problem is (what kind of data, how much of it, in what operating environment etc), the particular NoSQL solution. They'll try to find out how you analyse problems and along the way get an idea how much you know about the different solutions that are out there.
NoSQL databases normally only make sense if you design your data around them.
If you intend to simply use them as a RDBMS replacement, then you might get less performance rather than more, especially if you don't have enough budget to pay for servers with high amounts of RAM.
Look at this article which compares MySQL disk space usage with that of MongoDB: http://blog.trackerbird.com/content/mysql-vs-mongodb-disk-space-usage
Which NoSQL database? Which SQL database? If someone tells you that NoSQL is faster than SQL then you should walk away. Or better yet watch this video:
http://www.youtube.com/watch?v=b2F-DItXtZs
I won't say half the things claimed about NoSQL are wrong, but I will say that there is a lot of NoSQL fanboyism out there from people who really don't understand it very well.
SQL has its limits (of course) but it also is a very mature technology, which is well understood, and has a large pool of developers who understand how to use it well. I can not say the same for all forms of NoSQL.
NoSql supported by column oriented databases where RDBMS is row oriented database... And say for example we have a Employee table with Name, Age, Salery, Address, EmployeeId etc... we put same table in MySql (RDBMS support) and HBase (NoSQL support). If a customer/client writes a query to get the average Age or Salery details from 1Lakh employees records... what happens?
In RDBMS it will go around each row and collects the value and sum & divide for resulting. When it comes to Columnar database no need to worry about all one lakh row iterations. But deal with only one Row which is faster to compute. So this way sometimes NoSQL is faster than SQL. This case NoSQL don't care about ACID complaints are worth!
Forget theory around databases.... the point once you understand your querys, you can save data in nosql databases in an exact way in which they are actually used in your application....
For example take this example, u have a customer model with many orders and many items associated with each order, then they also have many saved items for later purchases... if you are a large ecommerce store with let's say 10 million customers and 50 million orders. And that customer logs into their dashboard which displays this exact data, how much work is a sql database going to need to do to find the customer, join the orders and each line item and saved items. In a sql database all this data will likely need to be joined in some way... or u can create a collection in ur database called usercache and save this data exactly how you use it in real life. So this can truely be a single query on a single field [id] to get all of this data back. On top of that the nosql database doesn't need to send the query to all 40 database servers to retrieve the information just the ones that actually have the data.
So can a sql db query a single Id field just as fast if not faster than nosql? Yes but can a sql database return all of the data you need by querying one table and one field? No, unless you do something like save the data in Json inside a large text field. But now that data is not query-able for potential future use.
