甲骨文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时遇到的。这是一个很大的改进。 |
