NoSQL again--Reasons to stick with SQL

This is my second time for the new project in-depth research NoSQL, but also the second decision to give up NoSQL. Like the conclusion I made last time about why I chose to use nosql so hard, we finally decided to give up NoSQL and use a traditional relational database.

I've come up with a lot of comments from the last post to evaluate NoSQL-the core of the solution is "depending on your needs." But despite the need for clarity, it still takes time to research and find out whether a particular NoSQL engine is exactly what you need. There are too many aspects that you can't evaluate all. To make things worse, you have to wade through the engine-specific documentation to see if it can achieve your goals, most of which are similar to the choice of relational data or acid solutions.

By contrast, if you use a relational SQL database, most of the times, regardless of the particular product, you know how it works, you don't have to do it over and over again, and you're more mature and stable. Choosing an RDBMS can significantly reduce the risk of making a bad decision.

The attraction of NoSQL is the ability to have scalability and ultra-high throughput. Even if its extensibility is really better than an RDBMS, the real world is that 99% of applications do not change the data model. For example, Stock Exchange, which is one of the most visited sites, has a commodity server running on MSSQL. And it's hard to imagine how much storage space nosql needs, and it's impossible to buy a 60-core server up to 6TB of RAM. So what are the real benefits of using NoSQL?

At first I thought NoSQL storage was an advantage, but I've changed my view. At least for relational page applications, modeless is simply adding to the complexity of the code. Besides, I like the structure, especially the data structure. Modeless is useful in data processing such as archiving, file storage, or event logging, but it does not have any advantages for non-social page applications.

Document storage makes each part of a program more complex than a relational database. For the kind of file name as key, file content as value of the parallel files storage (Key-value database), NoSQL is very advantageous, you can store any of the required content in such files, it will be convenient to read, but this storage is very brain-disabled. My conclusion is that NoSQL is very complex in managing and optimizing the stored files, and knows nothing about the stored data content. Relational database all the intelligent actions nosql all have no, you must use the code to implement those SQL self-contained function, this is unreasonable for most applications.

Even people who build NoSQL engines have trouble describing the use cases of their products, and many of NoSQL's comments are selling their products without giving any compelling reasons. Few SaaS applications use relational data, and the reality is that the RDBMS system is much more than the NoSQL system, and once all the hype stops and the number of NoSQL engines drops to a reasonable range, NoSQL will be a useful tool for these reasonable applications. In the future, I think NoSQL can be a component of the SQL system rather than a substitute, and I'm still sticking with SQL.