最大争论：最终一致性 耶鲁大学计算机科学教授Daniel Abadi在博客提出了自己的质疑。他说，在某些情况下，甲骨文NoSQL数据库向主服务器写入的关键字匹配会丢失。比如在主服务器宕机，同时备份服务器又没有准备好的情况下。 很快，哈佛大学计算机科学教授Margo Seltzer就最初了回应。Seltzer现在是甲骨文的员工，她参与创建了Sleepycat。Seltzer认为这并不是甲骨文NoSQL数据库的问题，如果要达到真正意义上的“最终一致性”，数据中心需要在准备好备份服务器的前提下才开始写入数据。而可以想见的是，要让这一争论有个最终结果是非常困难的。 为了测试甲骨文NoSQL数据库的速度，我们进行了如下测试：在一台低端的Mac计算机上开启了单点NoSQL服务器，然后往里面塞入358400条关键字，都是长度大约30的字符串。在这台老掉牙的Mac电脑上，甲骨文NoSQL数据库共用了119秒的时间。比较而言，把相同的记录插入最新版的Voldermort数据库，在这个LinkedIn症状使用的开源Java NoSQL数据库上，耗时为180秒。 如此看来，甲骨文NoSQL数据库似乎领先不少。创建关键字需要建立字符串数组，而对象的实例化经常成为Java的瓶颈。在这一测试中，甲骨文NoSQL数据库似乎没有碰到这方面的问题。 总体而言，甲骨文NoSQL数据库值得一试。因为它提供了许多严谨的功能，又是来自这样一家严谨的数据库厂商。在许多方面，与简单的NoSQL工具相比，甲骨文NoSQL数据库的设计相当周到并且精巧。此外，当面临节点崩溃，或是面临要速度还是持久性的问题时，你还有许多选择，这些选择都可以增强持久性。文档具有一致性，它们由在企业客户数据存储方面拥有丰富经验的工程师所编写。 甲骨文NoSQL数据库可能不会提供令人兴奋的趣味性，以及许多纯开源NoSQL项目所具有的“随意创建”体验。不过，这并不是它的真正用处。甲骨文从这些团队那里借鉴到了最佳的理念，创建了能够向企业市场最适当的地方提供更佳性能的数据库产品。 |
