【文档数据库】数据库深度探索:CouchDB

语言 Chinese, Simplified

SEO Title

欢迎来到数据库深度挖掘，这是一系列的采访，在这里我们将与数据库世界的建设者、工程师和领导者进行交谈。

Database Deep Dives: CouchDB

最近，我们有幸与Apache CouchDB项目管理委员会的Adam Kocoloski (@kocolosk)和Jan Lehnardt (@janl)进行了交流。查看下面的采访，了解更多关于Apache CouchDB的优点和缺点、项目的发展方向，以及他们对希望在Kubernetes上运行CouchDB的人的专家建议。

跟我们谈谈你自己和你今天在做什么?

Adam Kocoloski (AK):当然，我的名字是Adam Kocoloski，这些天我在做的是IBM云中的数据库和数据服务的技术策略。我们有一整套数据库和相关的东西来搬运数据，分析数据，并从中提取见解。我的工作是尝试并引导他们形成一个连贯的投资组合，以满足我们客户的需求，并使我们与市场上的其他公司处于一个强有力的竞争地位。

简·莱纳特(左壹):我是简·莱纳特。我做开源工作已经有20年了，CouchDB做了12年。大约五年前，我和我的公司睦邻hoodie一起，开始使我的Apache CouchDB工作服务和支持变得专业化。当我不运行它的时候，我正在开发CouchDB 3.0和4.0，我们决定同时进行，这非常令人兴奋。另外，我们正在开发opservator(我们最近宣布了它)，这是一个用于CouchDB安装的连续观察工具。

您是如何加入CouchDB的?

AK:我之所以加入CouchDB，是因为我和我在麻省理工学院的同事们有开公司的想法。我们的一个想法是在数据库空间。我们看到，在2007年和2008年，有各种各样的人在探索不同类型的数据库，而不是传统的用于支持LAMP堆栈应用程序的通用数据库。作为实践中的物理学家，我们有很多处理非传统数据集和非传统管理方法的实用经验。我们认为这可能是一个有趣的方式来应用我们的技能。

我们遇到CouchDB因为它似乎有着很多相同的原则我们的数据分布方法,关注数据的安全性和耐久性,的拥抱网络与数据交互的媒介如您构建您的应用程序。我们认为，与其坐下来构建一个看起来和感觉上像CouchDB的东西，不如更有效地参与到社区中，看看我们是否能在那里做出贡献。这就是我们想要建立的公司的基础。

JL:我当时主要是做LAMP的顾问。我最终擅长于让团队思考“可伸缩”，利用PHP无共享架构的所有优点和基本的最佳实践。我在某个地方的博客上发现了CouchDB，并对它做了一些研究。不到一个星期，我就开始恐慌了，因为如果CouchDB流行起来，我很快就会失业。我想我最好弄清楚如何熟练地使用它，看看它会发展成什么样子。CouchDB取代了所有东西，但结果并没有像我想象的那样。但是我没有错，一些看起来和感觉上像CouchDB的东西现在是数据库领域的主要参与者。我就是这样开始的，从来没有离开过。

您认为CouchDB的优势和劣势是什么?

JL:有一件事使CouchDB独一无二，[这]就是如果您按照动作构建数据库系统，您会被问到“为什么要这样做?”CouchDB存在的原因是其独特的复制功能，它可以从低级点对点(像物联网或移动设备收集数据并相互通信)到完全的多区域集群到集群复制同步数据。正是这种技术允许使用CouchDB的这些用例，而其他数据库实际上没有这种形式或形式。具体来说，CouchDB的复制更像Git而不是MySQL复制。

与其他数据库相比，它的主要优势在于数据的持久性;就像前面提到的Adam一样，它从来不会丢失任何数据!很难搞砸。在设计CouchDB时，我们默认选择安全和可靠，这使得操作非常简单。使用CouchDB很容易启动和运行，如果您不想了解太多的话，它可以完成您需要它完成的工作。

我们还花了几年时间思考REST API。从平易近人、长期有用的角度来看，这仍然是有回报的，而且它对我们来说很有效。我个人认为，使用文档数据库编程比使用其他SQL数据库编程更自然。这可能只是我的观点。

AK:我想我必须回应Jan的大部分评论。2009年，有人胆敢用这种技术创办了一家“数据库即服务”公司，我很感激我们对数据安全性和持久性的重视。在100次中，CouchDB只有99次能够自己解决如何让事情恢复正常运行的问题，我们真的很欣赏这一点。显然，当您遇到CouchDB考虑世界的方式以及在对等点之间复制和同步数据的方式所形成的问题时，复制支持一组用例，这些用例显然是用于该工作的正确工具。

这些绝对是系统的优点。说到缺点——要使CouchDB成为开箱即用的低延迟系统并不容易。您必须了解与web服务的性能访问相关的所有事情。我们看到一些客户端对每个请求都建立一个新的TLS连接。这里有很多来回的握手，这确实没有必要，但是因为它是一个web服务，如果您希望它这样做，CouchDB将很乐意与您协商这些连接。它将继续运行并保持可用性，但很难做到那么快。

我还想说，作为一个社区，我们在客户端库上的投入可能比其他一些项目要少一些。部分原因是我们说:“嗨，我们有这个很好的REST API。它是一种web服务，如果你知道如何与web服务对话，你就知道如何与数据库对话。”

虽然这是真的，但我们不时地看到，它让学习曲线变得比原本更陡峭。一些数据库投入了大量的时间、金钱(和人员)来构建一组不同的客户端库，这些库掩盖了来自最终用户的API的一些细节，并在每个流行框架和生态系统中提供了一个更惯用的编程模型。我认为这是我们近年来学到的东西，并投入了更多的精力。不过，我要说的是，在这一点上，我们还没有那么强大。

你见过的有关Couch的最酷或者最有趣的用例有哪些?

AK:在谈到这些新奇的东西之前，我应该说一件事，那就是我们很高兴CouchDB成为IBM Cloud中大量用例的基础。它为IBM云提供了基础级的支持，如果CouchDB有朝一日垮掉了，云也会垮掉。我认为这很酷，即使大多数用例可能是普通的、无聊的、数据库前的应用程序。它可以工作，可以扩展，可以满足我们的需求。

我们看到人们开发了很多手机游戏和手机钱包。我们看到一些人拿着一堆关系数据库和一大堆存储过程说:“天哪，我们不能再对这个堆栈做任何更改了，我们的存储过程涉及的是一家20年前就倒闭了的公司!”我们如何把这些都拿出来，并给我们的团队一个开发环境，让我们能够以业务所需的速度移动?像CouchDB这样的文档数据库非常适合。它简化了数据模型，并能够适应多年来在不同系统中可能出现的怪癖。

JL:我不得不附和亚当。我对Couch的评价是:“这是一个很好的通用数据库，80%的应用程序可以使用任何数据库，那么为什么不使用Couch呢?”“不过我们也看到了一些很酷的东西。

有一个公司在全球范围内运送货物。任何超出人手可携带范围的内容都通过多区域CouchDB集群进行管理。另一家公司是一家提供飞行娱乐系统的公司，在任何给定时间都有3000架飞机在飞行中使用CouchDB。我们还参与了人道主义危机，比如2016年的埃博拉救援工作，大约有四五个西非国家因为疫情爆发而基本停止了行动。

我们碰巧建立了一个离线的，第一个响应工具来帮助他们比在纸和笔上更快地处理危机，这是在没有电力、边缘网络或3G等基础设施的情况下做事情的通常方法。如果没有CouchDB，这一切都不可能实现。

我们还帮助开发了一款针对该环境的疫苗接种试验软件，从而研制出了第一款埃博拉疫苗。从个人角度来说，这是非常令人羞愧的。如果我们看看过去100年人类取得的重大成就，第一种埃博拉疫苗肯定在其中。就个人而言，或者即使我只是在CouchDB上工作，这都是非常棒的

你对CouchDB 3.0和4.0有什么期待?

JL:我们决定同时做CouchDB 3.0和4.0是有原因的。它们将按顺序发布，但我们正在同时考虑和工作。4.0的主要变化是以CouchDB为基础的重大技术转变。但在此之前，3.0中现有的基础将是我们所做过的最好的CouchDB。不是用“最新最伟大”的营销术语，而是从人们碰到、抱怨或马上询问的10件事的角度来看。CouchDB 3.0将简单地解决所有这些问题。

我们非常感谢IBM将他们在IBM与Cloudant公司合作开发的产品开源，我们也可以将其作为开源产品添加进来，同时我们也在开发其他一些产品，以确保我们能够提供最好的沙发平台。它包含了我们在过去10-15年使用CouchDB的所有经验教训，为需要长期使用该平台的人们提供了一个非常坚实的基础。对于CouchDB 4.0, Adam你可能想谈谈这个。

正义与发展党:是的,当然。因此，4.0版本包含了一个被称为FoundationDB的分布式事务键-值存储系统。这是我个人非常兴奋的事情，对于任何一个足够接近这个项目的人来说，也会对这里的潜力感到兴奋。

FoundationDB是一个商业软件，被苹果收购后关闭了。几年后，它被开源。这为我们提供了运行CouchDB环境的能力，这些环境能够向外扩展到单个区域，同时仍然为更新提供完全强大的一致性。如果你看看我们在Couch 2.0中所做的事情和我们将在3.0中保留的事情，就会发现我们在处理更新的方式和让各个副本相互协调的方式上是不同的。

而且，尽管这是一种持久且可适当扩展的设计，但它也给我们留下了一些难以编程的缺点。有可能让你的数据库在一个区域中出现编辑冲突，尽管你在编辑器中只是循环和写入数据库。我们希望通过使用Couch 4.0和使用FoundationDB来消除这种行为。

另一个是我们在CouchDB中使用分散-聚集机制执行视图索引的方式。它让人们通过高写入数据库提供了大量的索引吞吐量——将这些东西分片，然后每个索引将并行地构建其分片的视图。但查询这些东西是一个相当昂贵的主张。随着数据库变得更大，查询的成本将继续上升。

相反，当我们让视图在FoundationDB上运行时，我们将让它们在一个机器集群中重新组织和重新分发，这样大规模查询视图就像检索单个文档一样便宜。我认为这为采用CouchDB的人们打开了一大堆额外的高吞吐量/高规模用例。这是一个巨大的转变。这实际上意味着现在CouchDB逻辑是部署在FoundationDB之上的无状态应用程序层，它负责数据的所有有状态性、持久性和物化。

这不是我们掉以轻心的事情。我们总是非常重视数据的安全性、持久性以及正确处理人们的数据。我们在分析FoundationDB时也采用了同样的视角，我们很高兴地说，他们的项目与CouchDB有着相同的重点和关注点。

JL:我花了很多时间在台上谈论CouchDB，并向人们解释什么是CouchDB。问题经常出现在最终的一致性和复制，在2.0或3.0中的Dynamo模型集群。这样做的缺点是值得的，因为如果你想要创建一个分布式的、一致的数据库，你就需要找10个世界上最顶尖的分布式系统工程师，给他们5-10年的时间来做正确的事情。没有人有那样的时间。

它是被苹果收购之前的公司，而苹果的需求与之一致。我们面临的[开放]问题是:“我们是应该将我们的CouchDB转换成类似于FoundationDB的东西，还是仅仅在FoundationDB之上构建CouchDB，实现跨行业发展?”

基本上，他们做了一件不可思议的事情，而且做得很好。野外有足够的证据证明他们的做法是正确的。非常非常高兴看到它，而且我们很幸运它是开源的。

最后需要注意的是，这是一个过程问题，但是CouchDB项目并没有正式宣布4.0就是我们刚刚讨论的内容。它很可能很快就会这样做。如果任何CouchDB开发人员正在阅读，那么要使其正式运行需要一些过程。

听到核心代码库的改进是令人兴奋的，但是围绕CouchDB的生态系统并没有停滞不前。随着Kubernetes和它的朋友的出现，您会给想要在容器上部署CouchDB的人们什么建议?

AK:所以，我想我要说的是选择在容器上部署CouchDB，特别是将CouchDB与Kubernetes环境协调在一起，这是一个决定，它将使您能够获得进一步的改进。

我们在这里投入了时间和精力，以确保它是一种开箱即用的体验，能够满足各种应用程序的需求。这是一个不断变化的目标，不仅因为CouchDB支持Kubernetes和基于容器的部署，而且因为整个行业都是这样。

我们看到，今天每个人都在构建掌舵图表来支撑数据库，明天每个人都在构建操作符来管理这些数据库的生命周期。因为空间移动得非常快，所以要记录的东西很多。如果你想在生产中做这些事情，你就必须关注并与社区保持联系。但是，我们对推动支持感兴趣。我认为它提供了一种潜在的体验，在这种体验中，大多数配置在第一次就正确地完成了。

设置分布式系统的一些复杂性是我们可以在Kubernetes这样的受限环境中更好地进行自动检测和自动化，而不是在VMware环境中的虚拟机。

JL:是的，我绝对同意潜在的部分。但是，我要提一下，我们为Couch提供专业的服务，我们现在赚钱的一个领域就是让人们不再用Docker运行CouchDB。我认为这就是缺点所在。

对于某些工作负载，这项技术还不够成熟。并不是说Docker是唯一的容器解决方案，也不是说Kubernetes是我们能进入的唯一的分布情况，但是couchdb——作为一个分布式数据库——充分利用了低延迟、高带宽的网络以及极快的IO吞吐量和磁盘访问。

在某些越来越小的情况下，Kubernetes和Docker都阻碍了这一点。此时，CouchDB会变慢，或者会出现无法解释的超时错误。总的来说，如果你创建了一个知道如何重试的应用，这不是一个大问题，但它是一个不断变化的目标。

我建议，除非您有一个专门的团队负责保持Kubernetes集群上的服务正常运行(尤其是数据库)，否则它已经超出了目前大多数用例的范围。在IBM cloud、Microsoft或谷歌上的云虚拟机周围安装一些自动化就可以达到这个目的。

通常，从工作负载的角度来看，移动数据是比较昂贵的部分。因此，增加更多的工作人员在一个小时内处理数据库事务——在数据到达新节点之前，您需要等待半天才能处理这个峰值。所以在[向外扩展]场景中，它的用途有限，这就是为什么许多人从应用程序的角度对它感兴趣的原因(它在今天工作得非常好)。

当涉及到Adam刚才所说的内容时，请确保部署和集群管理或分发管理工作良好，并以声明的方式而不是功能的方式完成。这就是你要使用它的地方。如果您对资源的需求较低，但是想要获得在容器或kubernet中运行的好处——当然，尽管去做吧，只要知道[某些指标的限制]，并且如果没有一个专门的团队，您可能会更好地离开。今天的情况有好有坏，但我等不及这一切什么时候结束，什么时候方向很明确。并不是说这永远不会发生，只是等待底层技术赶上现实。

对于那些想要加入社区但以前没有使用过Erlang的人，您有什么建议?

AK:学习Erlang当然不是加入CouchDB社区的先决条件。我们希望在JavaScript层、文档系统和Elixir(我们现在正在移植测试套件以在Elixir中运行)上做出贡献。Elixir是一种极好的方式，可以让您深入了解基于erlang的、基于Beam的vm的系统，这些系统具有吸引开发人员的社区、采用、吸引力，并且与CouchDB的世界很好地结合。

但我认为，总的来说，这是关于参与开源项目的评论。人们会认为，有时候你需要弄清楚这个系统中最深、最黑暗的部分是如何运作的，并进行疯狂的公关才能参与其中。这不是真的。即使没有别的，我们也可以从各个领域的贡献中受益。作为项目管理委员会的成员，我们工作的一部分就是鼓励多样性的贡献，以确保我们有一个全面、包容的社区，让人们参与进来。这里的建议是举起你的手。我们绝对会找到包括你在内的方法，并充分利用你所能带来的:

JL:这都是非常好的建议，我只是想补充一点，虽然一开始可能会让人望而生畏，但Erlang并不像乍一看那样糟糕或困难。它可能看起来很奇怪，但是如果您愿意接受它，您可以在浏览一堆教程之后立即提交富有成效的补丁。有一件事很有帮助——我们基于web的HTTP JSON API可以在一个小时内学会。

然后，您所要做的就是在后台查看HTTP请求是如何处理的，这个JSON是如何解析的，然后就可以开始深入到堆栈中去了。我们帮助没有任何Erlang经验的用户在一个下午就完成了一个小的CouchDB功能。当然，我们引导他们，但如果你有更多的耐心，可能需要一个周末。

AK:说得好，jan。我不知道你是怎么想的，但是我是通过阅读CouchDB源代码和使用Couch来学习Erlang的。

莱托:相同。