Justin Sheehy谈Riak

个人简介 Justin Sheehy是Basho Technologies的CTO，该公司是Webmachine和Riak的幕后英雄。在Basho之前，他是MITRE公司的主管科学家以及 Akamai基础架构的资深架构师。在供职于这些公司的经历中，他的主要经验包括健壮的分布式系统，调度算法，基于语言的形式化模型以及弹性伸缩。

Erlang Factory是专注于Erlang的峰会——这是一门为支持分布式高容错以及软实时的应用需求而设计的语言，有着良好的可用性和并发性。该峰会的焦点是 为期两天的会议，有针对不同主题的专题会议，汇集来自了Erlang和网络的使用和应用领域的众多大牛。

   

1. Justin，能为我们简单的介绍以下自己以及最近所从事的工作吗？

好的，我现在是Basho Technologies的CTO。我们的产品是Riak，我想接下来我们会更深入的谈到它以及我们所发布的众多的开源产品。在加入Basho之前我曾于美国政府部门从事研究工作，以及在Akamai工作过几年的时间。

   

2. 那你能跟我们谈谈Riak吗？它是一个怎样的产品？

Riak是受到Amazon Dynamo系统的启发但又自成一体的系统。它是一个分布式，可伸缩的高容错的系统，这意味着它的基础是建立许多的计算系统之上。你可以通过添加计算机获取更强的计算能力或更大的吞吐量，而不用担心其中任何一个独立的系统宕机或服役结束。

   

3. 你能为我们解释一个Dynamo论文的主旨是什么吗？

发表于2007年的Dynamo论文具有深远的影响，开创了现在被称为 NoSQL的运动，尽管这个名字有点古怪。这篇论文里展示了Amazon的技术人员是如何通过一种特定的方法将一系列现有的技术(如Gossip协议以及 Vector Clock算法等等数十年的经验)组合起来，构建了具有非常良好特性的分布式系统。

在Amazon的案例中，原来的目的是为了保存一个购物车，你随时可以加入物品，但一些普遍的性能却良好的支持了许多共通的需求。这篇论文使得很大一部分认 识了运行其核心业务部分的关键，有时候在于选择不使用默认的数据库技术，比如Oracle和MySQL等等。这些系统很好，也能解决许多问题，但它们有时候对于你的业务问题而言并非是唯一的或者说最佳的选择。

   

4. 那么Riak作为你们对Dynamo论文的实现，有着什么特别之处呢？

对于Dynamo论文的一种普遍的误读在于将其视为实现这一系统的指导，而实际上并不是这样的。当人们真正尝试构建类Dynamo或基于Dynamo的系统的时候，他们很快发现该论文是描述Amazon的技术人员出于何种考虑将这些技术组合到一起以及他们所使用的技术。然而这离真正的实现手册还有很远的距离。

就 算是针对Dynamo特定的部分出入也是很大的。过去的几年里有众多的类Dynamo系统出现，对于每个系统来说，就算是属于 Dynamo范畴内的部分，其中很大程度上也不得不自行设计和实现。因为Dynamo只是告诉你哪些是良好的设计决策，但并没有告诉你如何去实现这一系统。即使是Dynamo这一块都会花去你很多的设计精力，也仅仅能做到实现而已。而这正是Riak与Voldemort以及其它的产品的区别之处，即使仅 就Dynamo这部分元素而言。为了达到这一目的，我们在Riak中的一项决策就是尽量简化与Dynamo元素周边相关的软件层次，这样就可以在不改动与 Dynamo相关代码的基础上去实现其它的功能，比如实现一个新的存储引擎等等。

我们进行了多次的修改并把选择权交给了用户，因此我们可以在存储以及客户端API方面作出创新，而这些都不会影响到Riak与Dynamo相关的部分。

   

5. 有没有客户目前在实际地实用Riak实现呢？

当然，我们第一个也是最为人道的客户是Mochi Media，他们的flash游戏使用了Riak技术来搭建一个庞大的广告网络。还有其它的客户——Comcast Interactive Media使用了Riak，而Mozilla也开始着手部署Riak，还有一些其它的用户。Riak现在不仅有着用户群也有着广大的客户群。

   

6. Riak一个有意思的方面是，它是一个key/value存储，但对于你想要存取什么样的value却没有限制。你能就此跟我们讲讲吗？

我认为key/value存储与很多人所说的文档数据库的一个不同之处在于，是否能够支持对所存储的值进行检查。大部分情况下 Riak将所存储的值当成是不透明的二进制数据。你存储键值对，将值放进去。但在某些方面，Riak又提供了一定的功能，让你能够对数据进行一些编程或处理的工作。

显然，如果你一旦决定指定某种操作数据的函数，这就暗示着你的数据就算没有模式也得有一定的前提条件。比如，在Riak中你能 够对存储的数据进行MapReduce的操作，这远远超出了基本的键值存储的范畴。尽管在Riak 中"get"，"put"，"delete"这样的操作不需要关心所存储的值是什么，但要运行MapReduce任务，那么"map"和"reduce” 语句就对于它们所读取的数据有一定的预期。

不同的人可以设置不同容忍度的写入规则。这些函数遇到不理解的数据可以完全失效，或者你可以选择跳过不理解的数据。决定权在你而Riak不会替你决定。

   

7. 当你在Riak中存储键值对的时候，你可以通过一个请求就取出它们的图结构吗？

这是个很棒的问题。我们对最初使用Riak的一些应用进行模型分析的一个发现就是，web本身就是一个非常强大的分布式系统。万维网的一个标志特性就是超文本之间的超链接。在数据和Riak之间表达关系的一个常见操作就是包含进数据的链接。

其中一种方式是通过HTTP链接头文件，这是一个草案标准，但这并不是唯一的方式。你可以配置数据的链接结构。在Riak中可以通过发起链接方式的查询来访问数据，比如“从这个文档出发，追溯到所有这一文档所链接到的满足某种标志规范的文档”。

而这样的命令可以是多级的。比如你可以指定“对于这些下溯的文档中的所有链接，再下溯到它们所链接到的所有满足某种标志规范的文档”。因此你可以查找这一树 型结构的叶子，甚至中从树的中间查找。而这一类链接查询之所以这么容易是因为你可以在简单的HTTP GET请求中做到它。语法简单，所有的语言都支持。

实际上所发生的是当发出get请求的时候，每一个层次的链接查询都被转化成了一个MapReduce的任务。Link Walking只是MapReduce能做的工作里的最简单的子集之一，但却十分有用。很多情况下你甚至都不用编写自己的map函数。

   

8. 你们为Riak提供了什么样的接口呢？

有两个重要的接口。其中一个是使用HTTP连接，我们用到了Webmachine，这也是由Basho开发和发布的一个开源软件，提供了良好的符合标准的 HTTP接口。这里的优势在于大家都知道如何于HTTP打交道。每一门编程语言都有相应的软件包，缓存也能很好的工作，它无所不在，伸缩性强，并且非常健壮。

这是两种方法中的一种。 对于要求更高吞吐率的客户，他们将Riak当成了高吞吐的数据库来使用，使用HTTP不是一种最优的方式，因为它是一种非常冗长的协议。我们还通过TCP 协议的缓冲接口使用Google的protocol buffer序列化和我们所写的简单的协议，将同样的底层接口暴露出来，使用TCP之上的序列化。

对于不需要HTTP所有方便功能的用户，他们更愿意使用能支持更多数据流的管道，他们可以使用protocol buffers。实际上你可以在这两者之间做出交替的选择，你可以通过protocol buffer来输入数据，并通过HTTP来读取，反之亦可。

   

9. Riak主要是由Erlang实现的，是吗？

是的，确实如此。Riak基本上都是Erlang写的。

   

10. Erlang对于实现Riak起到了什么样的帮助呢？

这是最自然的选择，特别当你认真的审视Dynamo模型，看看他们说的关于如何进行各种操作和获取数据的部分，都需要向多个其它的参与方发送消息，于是你需 要经历多轮的等待不同的类型返回，而使用Erlang的话，就已经具备构建这种消息传递的基本部件以及支持更复杂的状态机的能力。

显然， 你可以使用任何语言来写这样的程序。人们已经使用Java来这么做，你也可以，然而使用Erlang的话其语言(有着非常简洁的消息传递语义)以及 OTP库的支持(以及强大的状态机库的支持)，这确实是一种工具不仅能让我们更快的编写软件，同时对于系统中最复杂部分的健壮性也更为有信心。

   

11. 你们供应两种产品。其中一个是开源的，另一个需要花钱购买。可以跟我们描述一下你们的商业模式吗？

我们称其为一种开放核心模式，这与双重许可证的模式截然不同。作为开发者开发和运行所需要的Riak是以Apache 2许可证的方式完全开源的。我们鼓励人们使用它，随心所欲的应用。

我们还写了一些与这一核心良好集成的附加的应用和附加的代码，作为企业级产品的组成部分。如果你购买企业版的 Riak，你不仅能等到开放的核心，同时还有许多辅助的功能。这些功能通常对于进行原型开发的开发者不需要，但对于依赖于此产出利润的业务运营来说通常是 必不可少的。

比如通过JMX和SNMP监控，web管理员控制台，远程的多数据中心复制——这些都包括进了企业版本。但它们都是基于同样的人人都可以获取的核心开源产品。

   

12. 在你们的客户中，有什么样的反馈或者案例故事你愿意在这里跟我们分享的吗？

我们从几个客户那里学到了很多，首先是Mochi Media。他们帮助我们将Riak打造成运维灵活的产品，方便了那些在运维上与我们想法不同的人。Comcast同样在几个不同的方面推进了Riak的 发展。其中一个非常有趣的研究是来自于Mozilla团队的Test Pilot项目，他们甚至就此写了一篇博客。

来自该团队的 Daniel作为成员之一，评测了如何管理和存储在test pilots项目高峰时刻传输的大量的短语数据以及使用怎样的存储。他们分析了一些不同的数据存储方案：Riak，Cassandra，HBase等等， 评测的项目包括软件的健壮性，使用HTTP的接口类型，整体的模型等等，并最终选择了Riak。

但我认为这里真正让我们认识到的一点，不是关于如何超过了其它的竞争的系统，而是更好的帮助人们认识到(就像Dynamo论文帮助人们认识一样)，不同的业务需求的是不同的系统。

通常，一个复杂的业务系统最终会使用混合的系统。对此我们并不奇怪。实际上这也正是Mozilla，Comcast，Mochi Media以及其它客户的实际情况。人们通常运行一个以上的系统来存取数据。我们欣赏Mozilla这种方式的其中一点是，他们对于特定的项目和应用做了 实际的分析。初始阶段我们帮助他们学习如何建立集群等等，但他们学习的很快，并且这也很简单，后来就不需要我们的帮助了。

他们进行了许多天的高强度高吞吐率的基准测试，并学习了解应用的需求。Riak正是符合这种需求的数据存储。帮助人们更为严谨的认识业务的需求有着很好的回报。过去你都是选择Oracle(如果你有Oracle的许可证)或是MySQL等等来构建可以被它们所支持的应用。

最为值得的一件事是，我们给予人们的工具不仅能够以不同的方式解决问题，同时还能对他们的问题进行评估，从而找出怎样的解决方案才是真正适合他们的。

   

13. Basho公司的下一步计划以及项目会是什么？

我们在开发Riak的过程中学到的一件事，如同我之前所说的一样，我们构建分布式系统的核心和在此之上的简单的key/value存储。长久以来的一种认识 就是，如果你要开发一个大型的分布式系统来解决你的业务问题，那可能就会是一个一次性的解决方案，因为这些问题的特点就是如此。

我们试图淡化这种观点，并且认为它已经不像从前所认为那样的正确了。现在，我们正在开发下一个产品Riak Search，使用和Riak同样的分布式系统核心和基础。只需要减去其它所有和key/value存储以及数据库相关的部分。

然而我们使用从Riak中的所学，以及如何解决这一类分布式问题，如何管理节点失效，节点增加等动态运营问题等等经验，开发了一个可以让人们像使用Lucene或Solr一样使用的产品，却保留了Riak同样的运营和伸缩的性能。

搜索不会是我们在朝着这个方向上的最后一步。这只是我们的下一步而已。

   

14. Riak与市面上的其它类似的产品相比如何？

有两种直接的方式可以对比不对的数据存储系统。你可以比较它们的数据模型或者是分布模型。从数据模型的方面来说，Riak属于key/value或者是文档 存储系统的分类，取决于你如何看待，同时还有大量这一类的产品。在key/value存储的领域，有些产品有着悠久的历史，比如Berkeley DB等等。

这是非常简洁而强大的数据模型，但同时也有很多其它的不同类型数据模型的丰富而强大的系统。MongoDB有着深层嵌套的文档 模型而Cassandra使用的列数据模型更多的关注于自动交替的数据。在比较这些系统的时候人们首先应当注意的是这些系统适合什么样的数据模型，是 key/value的文档模型还是列交替的模型，或是模式驱动的关系数据库模型——它们应当说是等价的。

你应当分别独立地研究这些产品，看哪一些最适合你的问题。人们出于自身的比较目的而不断的缩小范围，研究哪一个数据存储从数据模型的方面最适合他们的问题，这正是最主要的方式之一。

而将这些数据存储方式区别开来的另一个基本的方面是分布模型。有好几种不同的类别。可以是单中心服务的，只运行一个中心节点可以获得很好的简洁性和效率。这 方面的例子是Redis，现在它也着手准备加入集群了。但现在它的形式还是一个单系统，单线程的数据存储，但是却非常棒。

这是一种性能强大速度卓越的管理数据的方式，但这不是分布式的系统。在它的领域里非常出色，但如果你看看Riak，Cassandra以及Voldemort等等，虽然在某些方面截然不同，但有一个共通点是，它们本质上都是分布式系统。

通过增加节点，它们可以获得更多的计算能力，并且它们的容量和处理能力是基于集群而不是单一节点的。在这两者之间还有其它的方案。比如MySQL以及许多其它的系统，可以构建一个非集群式的分布式系统，但可以进行主从复制。

有一些例子，比如CouchDB，你可以进行点对点，主对主的复制。所以，分布式模型是多种多样的。开发应用的开发者需要审视这些数据模型，以决定什么才能 最好的适合他们的需求，作出运维和业务决策的决策者也需要从健壮性，伸缩性，成本等等多方面综合考虑以找到需求的不同部分分别是什么样的分布式模型。

只有将这两者综合起来，你才不能不断缩小目标范围，在这些不同的系统中间找到最符合你需要的系统。

   

15. 如今我们已经随处可以听见NoSQL。很多人对此感兴趣。你能告诉我们它是如何演化，以及在这场运动中还会发生什么吗？

直到过去几年，当你开始一个需要存储并以各种方式使用数据的项目时，普遍的情况是首先就考虑标准的基于表的，模式驱动的关系型数据库，不管是MySQL，Postgres或者Oracle。这些技术对于许多人来说都能很好的解决很多的问题。

首先，NoSQL在数据访问上与SQL语言没有任何的关系。所以这个名字非常奇怪，但无论如何已经是这样了。我的观点是，对这一运动或者说现象的定义不是关于数据访问语言比如SQL，甚至其定义也根本不是关于任何特别的技术方案。

有的人认为这一定是关于文档型数据库，高伸缩性等等等等。但我认为这是关于对这一领域所有的方面都在帮助进步这一点的逐渐认识。这是关于这个事实，那就是就 像你选择你的web框架，选择你的编程语言一样，所有的这些都是基于你所构建系统的业务需求，而对数据存储方面，也理应如此。

而对于存储和管理数据，有着多种多样的选择。NoSQL运动正是要更明确更直接的告诉那些对系统作出业务决策的人们，这里存在着如此的多样性。你可以选择，你可以使用列数据库，你可以使用Riak，类Dynamo的key/value存储。

只 要它比Oracle，MySQL，或者说你之前任何的默认选择更加适合你的业务需求，你就可以去使用。它并不是取代任何已存在的技术；而是要明确的告诉人 们，应当投入跟分析软件中其它需求同样的精力来分析他们的数据存储需求。他们应当拥有对他们的需求产生价值的多种的选择。

   

16. NoSQL现象的一个特点是它一般都大型的web应用联系在一起。对于这些应用你认为还有哪些方面是必需的？

我个人认为这非常有趣，因为一些最为庞大的网站对NoSQL起了最大的推动作用，但我不认为这是因为这些技术相较其它的方面更适合于web。我认为整个NoSQL运动是关于为每个需要软件和数据存储等等的人提供各种各样的选择。

之所以我们最先在大型的web组织见证它的应用是因为这些公司(不管你说的是Amazon或是twitter之类的)有着非常不同的业务，但却有几点共通之处。其中一点是web运维。这里关于管理你整个系统，也包括你的数据。

为了对用户web交互的各种行为作出响应，同时由于向整个互联网开放你的web服务，因此就将这些业务需求更为快速更为深刻地暴露了出来，要求你比其它的行业要更早地做出一些相关的决策。

当然同样也有可能是出于竞争压力或者观念态度等等其它的原因，许多的web公司比起其它的行业来说更愿意去尝试一些新兴的有风险的选择。有的时候也许这并非出于需要。

Amazon需要一个可以一直支持写入的购物车，而这一定程度成为了这一切的起点。他们所学到的经验同时也是我们每一个人应该学习的是“永远别阻碍用户向你付费”。但每个人有着这样那样不同的需求，而他们中的一些正是通过各种分析的驱使而转向了NoSQL的解决方案。

有一些web业务之所以走在前面，尽管他们的需求与开发完全不同类型软件的人们几乎是等价的，是因为总是想尝试尽快的拾起新的语言新的技术等等。你几乎可以肯定很快就能看到web公司采用这些新的数据库。

   

17. 谢谢接受这次采访Justin。

谢谢，这是我的荣幸。