对NoSQL的先行者而言，甲骨文推出NoSQL数据库可以被解读为：“模仿是最真诚的赞赏”。
　　过去几年间，NoSQL数据库领域充满了令人兴奋的新项目、雄心勃勃的声明，当然也有盲目的自信。NoSQL的支持者称，通过抛弃传统的结构和偏执的三次检测，新的NoSQL软件包可以提供大量性能优势。那么可靠性呢？即便是那些并不是为华尔街银行运行重要业务应用，而只是处理人们生活中琐碎而易忘数据的新程序员也认为，NoSQL的可靠性被高估了。表结构呢？它们又过于死板且局限性太大。如果我们忽略这些事情，我们的数据库将更为自由，并且速度更快。
　　甲骨文NoSQL数据库的出现绝对让NoSQL粉丝感到吃惊，因为他们经常听到资深的数据库工程师在自豪地谈论甲骨文数据库。不过，甲骨文已经悄悄的在NoSQL数据库这条路上走了一段时间了。五年之前，甲骨文收购了开源伯克利数据库（BerkeleyDB）的开发商Sleepycat，为C语言和后来的Java程序员提供了灵活的键值存储。而Berkeley DB的技术据说就是甲骨文NoSQL数据库的核心，虽然看上去像是被完全重写了一遍。
　　甲骨文NoSQL：实用的ACID
　　甲骨文NoSQL数据库最有趣的地方就是它的键值结构。你不需要再去定义大纲，或者把自己锁在表结构中。你只需要创建关键字，然后把数据关联给它们就可以了。你可以给关键字连上一个字符串，也可以连上一个图像文件。什么都可以，数据库接受字节码，不去理会内容是什么。
　　甲骨文把关键字分为主次两个部分，你可以认为主部分是对象的指针，次部分是记录的各种字段。例如，你可以把姓名和社会保障卡号放在主部分里，把住址和邮编等等其他的字符串放在次部分里。这和一些NoSQL数据库工具使用一个对象多个字段的做法不同。
　　不过，目前对于如何解释其具体含义还存在着很大的争议。而大多数的NoSQL系统走的是另一条路：BASE，即基本可用（Basically Available）、软状态（Soft State）和最终一致性（Eventually Consistent）。换句话说，你可能会得到正确的答案，除非你不做。关于甲骨文NoSQL数据库是否真正提供ACID遵从还有不少争论，但甲骨文NoSQL数据库确实可以做出这样的承诺。
　　最大争论：最终一致性
　　耶鲁大学计算机科学教授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项目所具有的“随意创建”体验。不过，这并不是它的真正用处。甲骨文从这些团队那里借鉴到了最佳的理念，创建了能够向企业市场最适当的地方提供更佳性能的数据库产品。
　　LUPA开源社区