这篇文章是用英文写的，由于某种原因，这篇文章可以很直接的说是Anti-MongoDB一个和谐的DB（一）。写一的时候其实有很多问题，还是不很清楚的。所以有了以下的问题：
I has some questions about the nosql and the document database solutions because I just touch the nosql solutions these days,
I tried to understand and find the benefit of the NOSQL solutions (performance and scalability), but I cannot convince myself for the reasons, specially for the complex business related cases,
After read a lot of the articles and find the CAP, relational and Scalability are the three points for the NOSQL solutions,
CAP : only can pickup two of the three factors, and the NOSQL solutions pickup the AP, and use the eventually consistency to handle the consistency, now, let's check the RDBMS, if we have a lot of database servers, we also cannot have a good Consistency because of the performance issues, so we can choose the Master/Slave and asynchronize copy to handle the consistency (Similar with Eventually Consistency) which is similar with the NOSQL, so what is the benefit of the NOSQL (specify document database) from the CAP theory?
No-Relational object : the NOSQL is good at the no-relationship objects, for example, log. but log also can save to the RDBMS without relationship, so for the no-relationship objects, I think the mongo solution and the RDBMS solutions should be have the same performance and scalability. right?
Relational : in the mongodb.org there is a good example as following,
the address is embedded into the student which is reasonable and will make the performance better if we need load the address from the student in the UI, but the RDBMS also can do it for the 1-1 relationship, and the scores need ref to the another collection and which is also similar with the RDBMS and also need touch database two times when we load the course which also similar with RDBMS. so what is the benefit.
Partition and Sharding : RDBMS also provide the solutions (although need change some codes), and RDBMS also can handle them.
NOSQL数据库经过了风风火火的一年，各个解决方案做的一个比一个有个性，并且大部分都有了商业应用，总体来说自己创造出来并且可以进行自行优化的东东还是经得起历练的。
MongoDB在过去的一年中，变化非常之大，刚开始关注它的时候，它只是一个没有1.0版本的东东，但是现在已经加上太多太多的功能了，其中包括 MapReduce，Auto Sharding，等。
经过了比较深入的研究（还会继续研究），发现这个最像关系型数据库的数据确实做的很强大。有很多东西还是非常值得探讨的。我们先从以下方面进行研究关系型数据库和非关系型数据库的区别，以及为什么要在某种条件下摈弃关系型数据库。
1. 关系型数据库的产生就是为关系所生，如果一条条的都不是关系型的数据，需要进行关系型数据库吗？ 答案很简单：不需要
经典应用：Log的存储 （存储到关系型数据库的话，耽误了我们可怜的不好扩张的数据库呀，如果存储在文件里面，那又不好进行管理，所以非关系型数据库是一个很好的解决方案）
2. 关系型数据库过多的强调了关系，关系型数据库的目标是把我们的数据库打造成一个第三范式遍布的数据结构（无传递函数依赖和部分函数依赖）。但是这种拆解变相的多了一次数据库操作，也就是一次IO，性能也就会下降了。 例子如下：当我们想打开一个帖子的时候，我们肯定还是想把下面的Comments都拿到的，如果我们直接能把Comments存在这个帖子之下就很容解决了吧。
3. 关系型数据库过的关注consistency，其实我们很多的系统中并不需要这么好的consistency，起码很多的Web2.0或者是普通的网站来说，只要把Support，维护，alert机制做好，不需要太多的consistency一样可以做出很好的系统。当然我们也可以通过一些机制实现 eventually consistency （没有很深入的研究过）。太多的consistency的关注必然导致最后的available不会做到很好。进而关系型数据库很难scaling out。为了scaling out read，我们只能去做partition，但是partition很难做呀，一半都会牵扯到很多代码的改动。这些代码的改动会严重影响项目的稳定性而且风险性很大。而为了scaling out write 只能去做master-slave的解决方案（async和sync每种都有自己的问题）。很多NOSQL都解决了这个问题，无论是auto- sharding（因为是key做主的东西，可以很好的拆分）还是replication。（这一块要进一步研究）
4. Schema问题。关系型数据的schema都是一定的，如果增加或减少一个column那可是一个大动呀。但是NOSQL却是能很容易的解决这个问题，因为他们就是key-value而已。
NOSQL的提出是一个思想的进步，是一种编程理念的进步，数据库只是一个存储的库而已，他不应该过多的关注于其他的business相关的东西。将来发展的前景是我们所有的business的逻辑都应该在Domain里面体现，我们不用关注下面到底存储到那里。