Will NoSQL replace SQL databases?

Recently, many Web2.0 companies, such as Twitter, Digg, and Reddit, have announced that they have switched from MySQL to non-relational databases (NoSQL) to provide Scalable Data Storage Solutions, attracting developers' strong attention to NoSQL. Does NoSQL replace relational databases? In this regard, former Google Engineer, Ted, founder of Milo (local store search engine)

Recently, a number of Web 2.0 enterprises, such as Twitter, Digg, and Reddit, have announced that they have switched from MySQL to non-relational databases (NoSQL) to provide Scalable Data Storage Solutions, attracting developers' strong attention to NoSQL. Does NoSQL replace relational databases? In this regard, former Google Engineer, Ted, founder of Milo (local store search engine)

Recently, a number of Web 2.0 enterprises, such as Twitter, Digg, and Reddit, have announced that they have switched from MySQL to non-relational databases (NoSQL) to provide Scalable Data Storage Solutions, attracting developers' strong attention to NoSQL.

Does NoSQL replace relational databases?

In this regard, former Google engineer Ted Dziuba, founder of Milo (local store search engine), recently published an astonishing blog titled "I Can't Wait for NoSQL to Die ", the applicability of NoSQL is analyzed. He believes that,NoSQL will also bring about a series of new problems that will not become the mainstream and cannot replace relational databases.

The reason for this is that NoSQL databases such as Cassandra are not easy to use. For example, you need to restart when modifying the column family definition. In addition, NoSQL is more suitable for Google's scale, while general internet companies are not Google. It is a waste of time and there are huge business risks to consider the scalability of Google's scale early.

He also revealed that even key products such as Google and AdWords are implemented based on MySQL.

At the end of the article, he said that NoSQL certainly cannot die,It will eventually be marginalized, just like Rails being marginalized by NoSQL. DBAs do not need to be scared, because the decision makers of companies that have the money to recruit DBAs know what the actual business is.

Dziuba's article has aroused a strong reaction in the community due to fierce rhetoric.

There are a lot of likes in the SQL database camp. Craigslist engineer Jeremy Zawodny, a famous MySQL expert, said that while reading this article, I may smile from time to time. He said,NoSQL is just a normal phenomenon in the process of Software Evolution. Relational databases will continue to develop. The XtraDB, InnoDB plug-ins, PBXT, and Drizzle plug-ins continuously launched by the MySQL Community are evidence. As a result of various technical competitions, we have gained more options to solve the problem.

Eric Day, developer of the drizzle project, also said that NoSQL is worth learning a lot, but currently the best choice for most practical projects is relational databases.

Of course, the NoSQL camp will not be ignored. Eric Evans of the Cassandra project team said that the problem of changing the column family definition of Cassandra mentioned by Dziuba is very easy to solve. Moreover, NoSQL does not replace MySQL. In fact, Twitter still uses MySQL. If the relational database can bear the load, it will be used up; if not, consider NoSQL.

The well-known German Blog Code Monkeyism ridiculed Dziuba for seemingly not using MySQL as a real project, because if MySQL does not have memcache, it is basically unable to cope with website projects. He believes that NoSQL will make sqldatabase marginalized, and an important reason is that it can save DBA overhead.

Joe Stump, former chief architect of digg, who is also a startup, said that his current startup project uses NoSQL and lists a series of problems that challenge the SQL camp. In terms of scalability, speed, and cost, NoSQL has advantages that cannot be achieved by SQL databases.

Have you started using the NoSQL solution for your project? Your opinion on this argument? Welcome feedback.