持续性：备受争议
耶鲁大学计算科学系教授丹尼尔.阿巴迪的博客引发了有关最终持续性的争议。阿巴迪指出在某些情况下，写入到主关键值的新配对可能会在主关键值被切断后丢失。美国哈佛大学计算机科学教授，同时也是甲骨文的员工马格.赛尔查则持不同的观点。她加入了被收购的Sleepycat公司。
赛尔查认为一切都要取决与你对“最终持续性”的理解。数据库所有者会选择利用他们对持续性协议的机会。如果所有者希望确保一个配对不会丢失，他们必须所有写入的数据要等到所有副本被升级以后。
为了测试甲骨文NoSQL数据库的速度，笔者采用给了一种低端测试，将更多的压力放在数据库引擎上而不是网络上。笔者从单节点NoSQL服务器开始，然后尝试了358400个关联到关键值的关键值（恰红包含了大约30个字符的串），在老型号的Mac计算机上的速度是119秒。使用小容量随机存储器的老型号设备是测试有限资源下性能的一种方式。
作为对比，笔者有同样的配对测试了Voldemort的新版本，这是一款来自于Linkedln的用JAVA开发的开源NoSQL数据库。在同款设备上花费了180秒。
由于在甲骨文NoSQL数据库里存储数据看起来会涉及到一些管理费用，因此笔者只进行了一些简单的测试。创建需要构建串序列的关键值，目标实例通常是Java代码的瓶颈。看起来在这些测试都没有构成问题。
总的来说，甲骨文NoSQL数据库很愿意进行尝试，因为它能提供如此丰富的特性，可以进行更加深入的数据管理。工具比简单的NoSQL项目要更加的彻底和久经考验。在面对节点故障时，你有各种不同的选择来提高耐久力。
甲骨文NoSQL数据库可能无法提供给你惊喜，只能积累对于开源NoSQL项目的经验，但是这确实不是它的角色。甲骨文从中吸取了最好的想法来向企业市场传递最佳的性能。
甲骨文NoSQL数据库会从甲骨文悠久的传统中分离出来。笔者发现安装和运行甲骨文主要数据库比较困难。对比之下，开源社区能做的更好。有用户表示最重要的MySQL在测试和重新测试安装配置上要做的更好。
甲骨文NoSQL数据库显然是来自拥有开源传统经验的研发团队。唯一的问题是在将本地主机更改为127.0.0.1时遇到的。这是一个很大的改进。