先来说说对象数据库。定义参见维基：http://zh.wikipedia.org/zh/%E5%AF%B9%E8%B1%A1%E6%95%B0%E6%8D%AE%E5%BA%93
一个数据库的持久性整体规划通常都是不成套的。各种ORM（对象关系映射）工具都能更容易地进行对象和数据结构之间的转换，但没有一个是完美的。这就是通常所说的“ORM Impedance Mismatch（阻抗不匹配）”。于是吗，关系型数据库对于程序员的设计始终有相当大的限制，有的人擅长从领域模型去设计程序，有的人喜好从数据存储层面去设计代码。在对象数据库中，可以显式避免了一些传统关系数据库的使用方式，比如连表查询等，对于一些对象系统复杂，对象之间关系层次众多的场合，对象数据库有其独到的优势。
关系型数据库有比我们想的更多的局限性。存储和表示一些相当普通的数据结构也是非常困难的。试想一条公交线路——简单，有序的一组站点。关系型数据库以无序的方式存放表，只有创建一个特殊的索引，才能提取有序的数据。对象数据库就没有这个问题，它有有序的数组，不需要索引——这种索引是因为关系数据结构的局限性而要求创建的人工索引。
从设计的角度来看，很多程序员不得不通过一定的设计，尽量避免过多的级联对象一次从关系数据库中查出，以减少这种低性能的操作；而对于天然的对象，为了把它们放置到数据库中，程序员不得不把它们拆卸得乱七八糟，然后通过一个个关联表把它们再从逻辑上关联起来，这些都是。使用对象数据库，程序员可以更接近天然的认知，减少思维在上层代码到底层数据之间的转换。
再来说说NoSQL。NoSQL有人解释为Not Only SQL，它是在Web2.0的环境下产生的。入门材料可以参看Robbin的文章：http://robbin.javaeye.com/blog/524977
另外，首先在这里找资料：http://nosql-database.org/
关系数据库在应对互联网海量数据时，对于高并发、快读写和易扩展等方面渐渐显得力不从心（例如：Facebook’s 50 TB for inbox search, and eBay’s 2 PB overall data）；而另一方面，关系数据库本身具备的一致性、读写实时性等优势，反而不能施展了（比如我发表了一条评论，某人到了十分钟后才看到，也没有什么不妥）。
对于严谨的银行、医疗等行业，关系数据库还无可替代，但到了宽容和自由的互联网应用，NoSQL就准备好驰骋天下了。“关系型数据库给你强加了太多东西。它们要你强行修改对象数据，以满足RDBMS （relational database management system，关系型数据库管理系统）的需要，”在NoSQL拥护者们看来，基于NoSQL的替代方案“只是给你所需要的”。
据Facebook的工程师Avinash Lakshma介绍，Cassandra仅用0.12毫秒就可以写入50GB的数据，比MySQL快了超过2500倍。NoSQL和对象数据库一样，都能找到适合自己发挥的领域，至少现在看来没有谁能在某一天取代关系数据库。不过从数据库的应用来看，关系数据库已经不再处于垄断地位，也许过两三年，等云计算愈演愈烈的时候，那情况又有谁知道呢？
————————————————
版权声明：本文为CSDN博主「RayChase」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/raychase/article/details/6214347
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/tech/database/282392.html