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里面体现，我们不用关注下面到底存储到那里。