1.2. 为什么是CouchDB？¶
apachecouchdb是一种新型的数据库管理系统。本主题解释了为什么需要新系统以及构建CouchDB背后的动机。
作为CouchDB开发人员，使用CouchDB自然非常兴奋。在本主题中，我们将与您分享我们热情高涨的原因。我们将向您展示CouchDB的无模式文档模型如何更适合普通应用程序，内置查询引擎如何是使用和处理数据的强大方式，CouchDB的设计如何使其具有模块化和可伸缩性。
1.2.1. 放松¶
如果有一个词可以形容CouchDB，那就是 放松 . 这是CouchDB官方徽标的署名，当您启动CouchDB时，您会看到：
Apache CouchDB has started. Time to relax.
为什么放松很重要？在过去的五年里，开发者的生产力大约翻了一番。这一增长的主要原因是功能更强大、更易于使用的工具。以rubyonrails为例。这是一个极其复杂的框架，但是很容易开始。Rails是一个成功的例子，因为它的核心设计注重易用性。这是CouchDB放松的原因之一：学习CouchDB并理解它的核心概念对于大多数在Web上做过任何工作的人来说都应该感到很自然。向非技术人员解释这一点还是相当容易的。
当有创造力的人试图构建专门的解决方案时，避开障碍本身就是一个核心特性，也是CouchDB的目标之一。我们发现现有的工具太麻烦了，以至于在开发或生产过程中无法使用，因此决定将重点放在使CouchDB易于使用，甚至是一种乐趣上。
CouchDB用户的另一个放松领域是生产设置。如果您有一个实时运行的应用程序，CouchDB再次特意避免了麻烦。它的内部结构是容错的，故障发生在受控环境中，并且处理得很好。单个问题不会级联到整个服务器系统，而是孤立在单个请求中。
CouchDB的核心概念很简单（但是很强大）并且很容易理解。运营团队（如果你有一个团队，否则就是你自己）不必担心随机行为和不可追踪的错误。如果出了什么问题，你可以很容易地找出问题所在，但这种情况很少发生。
CouchDB还可以优雅地处理不同的流量。例如，如果一个网站的流量突然激增，CouchDB通常会吸收大量并发请求而不会崩溃。每一个请求可能需要更多的时间，但它们都会得到响应。当冲刺结束后，库奇德将再次以正常速度工作。
放松的第三个方面是增加和缩小应用程序的底层硬件。这通常被称为缩放。CouchDB对程序员实施了一组限制。乍一看，CouchDB可能看起来不灵活，但有些特性被设计忽略了，原因很简单：如果CouchDB支持它们，它将允许程序员创建无法处理伸缩的应用程序。
注解
不能让你以后再惹麻烦。这有时意味着你必须忘记你在当前或过去的工作中可能学到的最佳实践。
1.2.2. 数据建模的另一种方法¶
我们相信CouchDB将彻底改变您构建基于文档的应用程序的方式。CouchDB将一个直观的文档存储模型与一个强大的查询引擎结合在一起，这种方式非常简单，您可能会问：“为什么以前没有人构建过这样的东西？”？”
Django可能是为Web构建的，但是CouchDB是基于Web构建的。我从来没有见过这样完全包含HTTP背后的哲学的软件。CouchDB让Django看起来很老派，就像Django让ASP看起来过时一样。
—Jacob Kaplan Moss，Django开发者
CouchDB的设计大量借用了web架构和资源、方法和表示的概念。它通过强大的查询、映射、组合和过滤数据的方法来增强这一点。添加容错、极端可伸缩性和增量复制，CouchDB为文档数据库定义了一个最佳位置。
1.2.3. 更适合普通应用¶
我们编写软件来改善自己和他人的生活。通常，这需要获取一些普通信息，如联系人、发票或收据，然后使用计算机应用程序对其进行操作。CouchDB非常适合这种常见的应用程序，因为它将不断发展的、自包含的文档作为其数据模型的核心。
1.2.3.1. 独立数据¶
发票包含有关单个交易的所有相关信息-卖方、买方、日期，以及所售项目或服务的列表。如所示 图1。独立文件 ，在这张纸上没有抽象的参考，它指向另一张写有卖家姓名和地址的纸。会计师喜欢把所有东西放在一个地方的简单性。如果有选择，程序员也会很感激。
图1。独立文件
然而，使用引用正是我们在关系数据库中对数据建模的方式！每个发票作为一行存储在一个表中，该行引用其他表中的其他行—一行用于卖方信息，一行用于买方，一行用于每个已开票项目，还有更多行仍用于描述项目详细信息、制造商详细信息等。
这并不是对关系模型的贬低，关系模型具有广泛的适用性和非常有用的原因。不过，希望它能说明这样一点：有时您的模型可能无法以真实世界中出现的方式“拟合”数据。
让我们看一看简陋的联系人数据库，以说明一种不同的数据建模方法，一种更接近于真实世界的建模方法——一堆名片。很像我们的发票示例，名片包含所有重要信息，就在卡片上。我们称之为“自包含”数据，它是理解像CouchDB这样的文档数据库的一个重要概念。
1.2.3.2. 语法和语义¶
大多数名片包含的信息大致相同——某人的身份、隶属关系和一些联系信息。虽然这些信息的确切形式可能因名片而异，但传达的一般信息保持不变，我们很容易将其识别为名片。在这个意义上，我们可以把名片描述为 real-world document .
简的名片上可能有电话号码，但没有传真号码，而J·克里斯的名片上既有电话号码，也有传真号码。简不必在名片上写上“传真：无”这样可笑的话，来说明他没有传真机。相反，简单地省略一个传真号码就意味着他没有传真号码。
我们可以看到，同一类型的真实文档（如名片）在 语义学 --它们所携带的信息类型，但在 句法 ，或该信息的结构。作为人类，我们很自然地适应这种变化。
而传统的关系数据库需要您对数据进行建模 在前面 ，CouchDB的无模式设计为您提供了一种强大的聚合数据的方法 事后 ，就像我们处理真实世界的文档一样。我们将深入研究如何使用这种底层存储模式设计应用程序。
1.2.4. 大型系统的构建块¶
CouchDB是一个单独使用的存储系统。您可以使用CouchDB提供的工具构建许多应用程序。但CouchDB的设计考虑的是更大的范围。它的组件可以用作构建块，以稍微不同的方式为更大和更复杂的系统解决存储问题。
无论您需要一个速度极快但不太关注可靠性的系统（比如日志记录），还是一个能够保证存储在两个或多个物理分离位置以保证可靠性的系统，但您愿意承受性能损失，CouchDB都允许您构建这些系统。
有许多旋钮可以让系统在一个区域更好地工作，但这样做会影响到另一个区域。其中一个例子是中讨论的CAP定理 最终一致性 . 要了解影响存储系统的其他因素，请参阅 Figure 2 和 Figure 3 .
通过减少给定系统的延迟（不仅对存储系统而言如此），您将影响并发性和吞吐量能力。
图2。吞吐量、延迟或并发性
图3。缩放：读请求、写请求或数据
当您想要横向扩展时，有三个不同的问题需要处理：扩展读请求、写请求和数据。与所有三个和中显示的项目正交 Figure 2 和 Figure 3 更多的属性，比如可靠性或简单性。你可以画出许多这样的图表来展示不同的特性或属性如何拉向不同的方向，从而塑造它们所描述的系统。
CouchDB非常灵活，为您提供了足够的构建块来创建一个适合您具体问题的系统。这并不是说CouchDB可以致力于解决任何问题——CouchDB并不是万能的子弹——但在数据存储领域，它可以让您走上一段很长的路。
1.2.5. CouchDB复制¶
CouchDB复制就是这些构建块之一。它的基本功能是同步两个或多个CouchDB数据库。这听起来可能很简单，但简单性是允许复制解决许多问题的关键：在多台机器之间可靠地同步数据库以进行冗余数据存储；将数据分发到CouchDB实例集群，这些实例共享命中集群的请求总数的一个子集（负载平衡）；以及分发数据在物理上相距较远的地点之间，例如一个在纽约的办公室和另一个在东京的办公室。
CouchDB复制使用所有客户机使用的相同restapi。HTTP是无所不在的，而且很容易理解。复制是以增量方式工作的；也就是说，如果在复制过程中出现任何问题，例如断开网络连接，它将在下次运行时恢复到中断的位置。只需要同步数据传输。
CouchDB的一个核心假设是，可能会出问题，比如网络连接故障，它的设计目的是为了优雅地恢复错误，而不是假设一切都会好起来。复制系统的增量设计显示了这一点。“可能出错的事情”背后的思想体现在 Fallacies of Distributed Computing ：
- 网络是可靠的。
- 延迟为零。
- 带宽是无限的。
- 网络是安全的。
- 拓扑结构不变。
- 有一个管理员。
- 运输成本为零。
- 网络是同质的。
现有的工具经常试图隐藏这样一个事实，即存在一个网络，并且对于某个特定的系统来说，前面的任何或所有条件都不存在。这通常会导致当某些事情最终出错时出现致命错误。相比之下，CouchDB并不试图隐藏网络；它只是优雅地处理错误，并让您知道何时需要您端上的操作。
1.2.6. 本地数据为王¶
CouchDB从Web中吸取了不少经验教训，但是Web有一点可以改进：延迟。无论何时你必须等待一个应用程序响应或一个网站呈现，你几乎总是在等待一个没有你想要的那样快的网络连接。等待几秒钟而不是毫秒会极大地影响用户体验，从而影响用户满意度。
离线时你会做什么？这种情况经常发生——你的DSL或有线电视提供商有问题，或者你的iPhone、G1或Blackberry没有网线，没有连接意味着无法访问数据。
CouchDB也可以解决这个问题，这也是伸缩性很重要的地方。这一次它正在缩小规模。想象一下CouchDB安装在电话和其他移动设备上，这些设备可以在网络上与集中托管的CouchDB同步数据。同步不受用户界面约束（如次秒级响应时间）的限制。与低带宽和非常低的延迟相比，针对高带宽和高延迟进行调整更容易。然后，移动应用程序可以使用本地CouchDB来获取数据，由于不需要远程网络，所以默认情况下延迟很低。
你真的能在电话上使用CouchDB吗？Erlang，CouchDB的实现语言被设计成运行在比现在的手机更小、更不强大的嵌入式设备上。