在过去的几年里，NoSQL数据库的世界里充满了各种有趣的新项目，雄心勃勃的声明和大量信誓旦旦的承诺。有传闻称最新的NoSQL数据库软件套装通过调整所有的结构和数据库创建者多年来一直希望增加的三倍校验来实现大幅度的性能提升。可靠性如何呢？据那些没有使用NoSQL数据库来运行大规模企业级应用软件而只是从事一些琐碎交易的华尔街银行编程人员表示，可靠性是被高估了。制表结构如何呢？过于死板和有限了。如果我们将这些问题忽略的话，那么数据库的优势是免费，且运行速度很快。
NoSQL数据库的面世也十分缓慢。甲骨文-高级NoSQL数据库的顶尖研发厂商推出了一款可靠的实用的和与甲骨文非常类似的NoSQL服务器。尽管疯狂的梦想家们还在继续构建着NoSQL数据库的存储库，但认为还是希望能关注甲骨文版本。它不仅能提供很多让NoSQL数据库更加有趣的特性，但是可靠的性能号称来自大型的工程师团队。
这款产品的面世可能会让NoSQL数据库的拥趸者们（那些一直对甲骨文数据库引以为傲的守旧派们）倍感惊喜，但是甲骨文公司会暂时沿着这条路缓慢前进。五年前，甲骨文收购了Sleepycat软件公司，这家公司是开源贝克利数据库的创建者（这是一款为C和后来的JAVA编程人员设计的灵活性关键值存储上有着悠久且丰富传统的工具）。同样的贝克利数据库技术据称是甲骨文NoSQL数据库的核心，虽然看起来还需要全部重新编写代码。
甲骨文NoSQL数据库：实用的ACID
甲骨文NoSQL数据库的有趣之处是关键值结构。你不需要定义一个计划或者拘泥于大型的表格式体系结构中。你只需创建关键值并关联到字节上。你可以将你的关键值连接到字符串或者映像文件或者任何东西上。数据库可以接收字节而且无需考虑太多内容。
甲骨文公司将关键值划分为主要部分和次要部分。你可以将主要部分看做是目标指示器，将次要部分看做是记录里的域。这样你可以将名字和社会保障号码放在关键值的主要部分里，像街道地址和邮政编码这样的其他字符串放在次要部分里。和其他的一些NoSQL工具是可以进行对比的，帮助用户将多个域的目标物体的价值对比考虑。甲骨文只是使用“次要关键值”这个数据来作为域的名称。
甲骨文NoSQL数据库重要的部分是实用的ACID，NoSQL数据库可能提供的标准版。ACID指的是“细微的，相容的，独立的，持久的处理”，对于这方面的细节展开了一场激烈的争论。多数NoSQL数据库承诺是“BASE”，即“基本的可用性，软状态和最终的一致性”的首字母缩写。换句话说，你可以得到正确的答案，除非你不需要的时候。
对于甲骨文NoSQL数据库是否能提供真正的ACID存在着大量的争论。当你编写关联到同一个关键值的主要部分的数据时你只能得到ACID的承诺。举例来说，由于两部分都被存储在同一个主要关键值里，所以你可以更改同一个人的地址和邮政编码并得到ACID的保证。但是不担保两个独立人的改变将保持一致。换句话说，已将银行可以使用甲骨文NoSQL数据库来存储个人记录，但是不会用于账户间现金的安全交易，因为没有不会导致金钱损失的ACID担保。
甲骨文NoSQL数据库能够做出这种承诺，因为它可以保证一台主机能存储所有关联到主要关键值的次要关键值。将任何域的集合关联到定义一个人的主要关键值上，这个数据的所有将集中在集群的同个节点上。但是来自不同主要关键值的数据会放置在不同的服务器上，甲骨文NoSQL数据库没有一个机制来确保数据被同时写入主要关键值和次要关键值。
你还能增加复制和碎片，甲骨文将其称为“分区”。本质上来说就是安排矩阵中发生碎片的节点。如果你需要更多的可靠性和更快的读取速度，你需要沿着复制轴增加更多的系统。如果你希望减少争议，你可以沿着分区轴增加更多的系统。甲骨文NoSQL数据库能为你应对更多此类配置。
这不止是个二进制的判断。你可以让甲骨文NoSQL数据库终止写入，或者多数节点已经完成了数据到硬盘的发送。文件将这个特性称之为持久力协议。
这种灵活性也可以供编程人员使用，如果你有时间来为此担心的话。所有的关键值配对都伴随着一个版本号。如果你想在修改记录时提高性能这种方式是有帮助的。
持续性：备受争议
耶鲁大学计算科学系教授丹尼尔.阿巴迪的博客引发了有关最终持续性的争议。阿巴迪指出在某些情况下，写入到主关键值的新配对可能会在主关键值被切断后丢失。美国哈佛大学计算机科学教授，同时也是甲骨文的员工马格.赛尔查则持不同的观点。她加入了被收购的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时遇到的。这是一个很大的改进。
