Riak 2.0:数据类型\强一致性\全文搜索等等

　　让我们看看 Riak 2.0主要有那些改进：

• Riak 数据类型. 在最终一致计数器（Riak 1.4中引入）基础之上，Riak 2.0 添加了set和map作为新的分布式数据类型。这些Riak数据类型简化应用开发而不用牺牲Riak的可用性和分区耐受性的特性。
• 强一致性. 开发者根据数据需求可以选择哪个bucket应该拥有最终一致性（如今的默认Riak配置提供了高可用性）或强一致性。
• 集成Apache Solr全文搜索.Riak 搜索在Riak 2.0已经被完全重新设计，以充分利用Apache Solr引擎。Riak 2.0中的搜索支持Solr 客户端查询API，能够集成目前主要的软件和商业解决方案。
• 安全性. Riak 2.0添加了管理员访问权限并且使用插件验证模型。通过客户端API提供身份验证和授权。
• 简化配置管理. Riak 2.0继续改善了操作简便性，通过改变配置信息的存储方式和位置，以一种易于解析和透明格式存储。
• 减少多数据中心的副本.Riak 2.0企业版可以在多个数据中心中选择存储一些数据副本，以在存储开销和可用性之间维持更好的平衡。

　　准备好了吗？下载技术预览吧。

　　请注意这只是Riak 2.0的一个技术预览版本。这意味着它已经被广泛测试，虽然我们已经对所有的候选发布版本进行了处理，但是要确保生产硬化任然有许多工作要做。从现在到最 终版本发布，我们将继续进行手动和自动测试，制定详细的使用案例，收集性能统计数据，并更新使用和部署的文档。

　　我们将最终敲定Riak 2.0，我们欢迎您的对于技术预览版本的意见反馈。我们会一直开放讨论，你可以通过Riak 的用户邮箱列表，IRC（riak上的免费节点）来进行讨论，或者联系我们。

　　Riak 2.0技术预览版：深度剖析

　　Riak数据类型

　　在分布式系统中，我们不得不牺牲一致性来换取可用性（参见：CAP定理），这将会使得应用设计的某些方面变得复杂。在Riak 2.0版本中，我们整合了最前沿的数据类型研究——CRDTs（无冲突复制数据类型），率先创造了Riak的数据类型。通过添加计数器，集合，map，寄 存器和flag这些Riak数据类型，(Riak)能够让开发者在矢量时钟复杂度和解决冲突等方面上花费更少的时间，相反(让他们能够)专注于他们所熟悉 的分布式数据类型来支持他们应用的数据访问模式。

　　Riak的数据类型检查实施以及注意事项和基本用法，这里提供更详细的概述。

　　强一致性

　　在之前的所有版本中，Riak 被定性为一个最终一致性的系统。随着2.0版本的发布，Riak 现在允许开发者选择操作什么时候应该是强一致或最终一致的。这给开发者在这些不同数据类型语义中提供了一个选择。同时运营商也可以继续享受Riak的操作 简便性。在同一集群中的每一个bucket基础类型上都定义了一致性偏好。

　　RICON West 2012会议上的一个讨论叫做“为Riak添加一致性”，在这一讨论的基础之上，我们吸收了其中许多的原始想法。此外，(github上)为riak_kv添加一致性的pull request提供了相关资料库和实现方法的详细信息。

　　重新设计的全文搜索

　　Riak是一个键/值存储库，并且值简单的以二进制存储在磁盘上。在之前Riak 搜索的版本中，Riak开发者早就能够对这些这些存储数据内容进行索引。在Riak 2.0中，Riak搜索功能（代号：Yokozuna） 已经被完全重新设计，现在直接使用Apache Solr 全文搜索引擎。Riak 和Solr提供了一个可靠的全文内容索引解决方案，高可用并易于扩展。此外，Riak搜索2.0版本也支持全部的Solr 客户端查询APIs，这允许（客户能够）集成现有的软件解决方案（即可以是自产的也和可以是商业的）。

　　负责Yokozuna工程师已经创建一个资源页面，其中包含了谈话记录，Solr 文档链接，以及这种话题的书籍。

　　安全性

　　Basho在设计Riak时候采用了一种临界数据的思想。 无论是它的数据遭受到影响，用户经验，甚至病人的健康（万一出现NHS情况），Riak都会确保关键数据的可用性。然而，这些临界数据也是非常重要的数 据。Riak 2.0对这些数据添加了安全性，使用今天常用的管理权限和插件的安全验证模式。

　　最初的RFC,描述了安全点,包括相关拉请求,可以在github.com/basho/riak/issues/355查看到。

　　简化配置管理

　　在Basho中，我们对提供了操作友好的软件，可以在处理 分布系统时平滑运行而感到骄傲。在过去，Riak的配置在两个文件里：app.config和vm.args。Riak 2.0变化了配置信息存储的方式和地点。它不再使用Erlang特定的语法，但，提供了一个更加适合所有操作的布局和自动部署的工具。这个布局容易理解， 对管理员透明。

　　对于愿景和具体实现注意事项的更多信息包含在仓库github.com/basho/cuttlefish中。

　　Bucket类型

　　在Riak 2.0版本之前，键是由两部分组成：它们属于的bucket和在bucket内的独特标记。Bucket像一个命名空间，允许相似的键合并成集合。而且，它们提供了一个配置Riak旧版本处理数据的方法。

　　在Riak 2.0里，一些新特性（尤其是安全和强一致性）需要与bucket集合交互。为了这个目的，Riak 2.0包含了Bucket类型的概念。而且允许新特性在Bucket名字没有特殊的前缀，Riak开发者和操作者可以定义共享相同性质的bucket集 合，仅仅存储每个Bucket类型的信息，而不是单个bucket。

　　更多关于Bucket类型的信息可以在Github Issuegithub.com/basho/riak/issues/362上找到。这个issue描述了计划的功能、关于实现的讨论和相关的pull请求。

　　更改同级冲突解决方案的默认值

　　Riak通常既支持应用端结合时间戳这样的解决方案，也支 持服务端的基于时钟向量的最后一次写入者获胜的解决方案。在Riak 2.0之前，基于时钟向量的最后一次写入者获胜方案是默认的解决方案。后来，新的集群把解决同级冲突的默认方案交给应用处理。Riak运行这种方式最安 全，不过，这需要开发人员自己开发同级冲突的解决方案。

　　在题目为《理解Riak的可配置行为》的系列博客日志里，Basho上的支持者John Daily非常详细的讨论了最后一次写入者获胜的配置和许多其他选项。

　　更加高效的使用物理内存

　　Riak节点被设计用来管理一个变化需求的集群，如经历网络、硬件和其他故障。为了达到这个目的，Riak相应的平衡了各个节点的资源。Riak 2.0通过允许局部数据库随着集群负载波动来动态变化缓存大小，使得LevelDB的可用物理内存（RAM）显著的提高。

　　在过去，为不同的LevelDB缓存独立分配RAM是必须的。现在不再是这样了。在Riak 2.0里，管理键/值或者活跃反熵数据的LevelDB数据库共享一个单独的内存池，管理员可以根据他们部署的需要来给LevelDB分配可用的RAM。详细的实现文档可以在basho/leveldb维基上找到。