Apache CouchDB 2.0.0：技术概述与入门

需积分: 10 49 浏览量更新于2024-07-20 收藏 2.77MB PDF 举报

"CouchDB 是一个开源的、基于文档的分布式数据库系统，由Apache基金会维护。该系统设计用于在不稳定的网络环境中提供高可用性和数据一致性。CouchDB使用JSON格式存储数据，并通过JavaScript进行查询和处理。其特点包括事件视图一致性和内置的Web界面Futon用于管理和操作数据库。此外，CouchDB还支持cURL命令行工具进行交互，便于开发者使用。本资料涵盖了CouchDB的安装、配置、复制和维护等多个方面，旨在为初学者和开发者提供全面的指南。" CouchDB是一个强大的非关系型数据库管理系统（NoSQL DBMS），它采用了文档存储模型，将数据以JSON格式存储。技术概述部分介绍了CouchDB的核心特性，包括它的分布式架构和事件视图一致性（Eventual Consistency）原则，这使得CouchDB能在多个副本间延迟同步数据，从而提高了系统的可用性。为何选择CouchDB？其主要优点在于它的灵活性、可扩展性和离线支持。CouchDB适用于需要处理大量非结构化数据的应用，如Web应用、物联网设备或移动应用。它支持多种平台的安装，包括Unix-like系统、Windows、MacOS X和FreeBSD。安装部分详述了在不同操作系统上安装CouchDB的步骤，确保用户能根据自己的环境顺利设置数据库。配置章节则深入讲解了如何定制CouchDB的行为，包括基础配置、HTTP服务器设置、认证与授权、压缩配置、日志记录以及复制器等。 CouchDB的复制功能是其一大亮点，它允许数据在多个服务器之间自动同步，增强了系统的容错性和灾难恢复能力。复制协议部分详细解释了这一过程，包括复制数据库、处理冲突模型等内容。维护章节则涵盖了数据库的日常管理任务，如数据压缩，这是为了优化存储空间和提高性能。这些全面的文档为开发者提供了从入门到高级使用的全面指导，帮助他们更好地理解和利用CouchDB的功能。

Apache CouchDB, Release 2.0.0-git

Can you really use CouchDB on a phone? Erlang, CouchDB’s implementation language has been designed to run

on embedded devices magnitudes smaller and less powerful than today’s phones.

1.2.7 Wrapping Up

The next document Eventual Consistency further explores the distributed nature of CouchDB. We should have

given you enough bites to whet your interest. Let’s go!

1.3 Eventual Consistency

In the previous document Why CouchDB?, we saw that CouchDB’s ﬂexibility allows us to evolve our data as our

applications grow and change. In this topic, we’ll explore how working “with the grain” of CouchDB promotes

simplicity in our applications and helps us naturally build scalable, distributed systems.

1.3.1 Working with the Grain

A distributed system is a system that operates robustly over a wide network. A particular feature of network

computing is that network links can potentially disappear, and there are plenty of strategies for managing this type

of network segmentation. CouchDB differs from others by accepting eventual consistency, as opposed to putting

absolute consistency ahead of raw availability, like RDBMS or Paxos. What these systems have in common is an

awareness that data acts differently when many people are accessing it simultaneously. Their approaches differ

when it comes to which aspects of consistency, availability, or partition tolerance they prioritize.

Engineering distributed systems is tricky. Many of the caveats and “gotchas” you will face over time aren’t

immediately obvious. We don’t have all the solutions, and CouchDB isn’t a panacea, but when you work with

CouchDB’s grain rather than against it, the path of least resistance leads you to naturally scalable applications.

Of course, building a distributed system is only the beginning. A website with a database that is available only

half the time is next to worthless. Unfortunately, the traditional relational database approach to consistency makes

it very easy for application programmers to rely on global state, global clocks, and other high availability no-nos,

without even realizing that they’re doing so. Before examining how CouchDB promotes scalability, we’ll look

at the constraints faced by a distributed system. After we’ve seen the problems that arise when parts of your

application can’t rely on being in constant contact with each other, we’ll see that CouchDB provides an intuitive

and useful way for modeling applications around high availability.

1.3.2 The CAP Theorem

The CAP theorem describes a few different strategies for distributing application logic across networks.

CouchDB’s solution uses replication to propagate application changes across participating nodes. This is a fun-

damentally different approach from consensus algorithms and relational databases, which operate at different

intersections of consistency, availability, and partition tolerance.

The CAP theorem, shown in Figure 1. The CAP theorem, identiﬁes three distinct concerns:

• Consistency: All database clients see the same data, even with concurrent updates.

• Availability: All database clients are able to access some version of the data.

• Partition tolerance: The database can be split over multiple servers.

Pick two.

When a system grows large enough that a single database node is unable to handle the load placed on it, a sensible

solution is to add more servers. When we add nodes, we have to start thinking about how to partition data between

them. Do we have a few databases that share exactly the same data? Do we put different sets of data on different

database servers? Do we let only certain database servers write data and let others handle the reads?

10 Chapter 1. Introduction

Apache CouchDB, Release 2.0.0-git

Fig. 1.4: Figure 1. The CAP theorem

Regardless of which approach we take, the one problem we’ll keep bumping into is that of keeping all these

database servers in sync. If you write some information to one node, how are you going to make sure that a read

request to another database server reﬂects this newest information? These events might be milliseconds apart.

Even with a modest collection of database servers, this problem can become extremely complex.

When it’s absolutely critical that all clients see a consistent view of the database, the users of one node will have

to wait for any other nodes to come into agreement before being able to read or write to the database. In this

instance, we see that availability takes a backseat to consistency. However, there are situations where availability

trumps consistency:

Each node in a system should be able to make decisions purely based on local state. If you need to

do something under high load with failures occurring and you need to reach agreement, you’re lost.

If you’re concerned about scalability, any algorithm that forces you to run agreement will eventually

become your bottleneck. Take that as a given.

—Werner Vogels, Amazon CTO and Vice President

If availability is a priority, we can let clients write data to one node of the database without waiting for other nodes

to come into agreement. If the database knows how to take care of reconciling these operations between nodes,

we achieve a sort of “eventual consistency” in exchange for high availability. This is a surprisingly applicable

trade-off for many applications.

Unlike traditional relational databases, where each action performed is necessarily subject to database-wide con-

sistency checks, CouchDB makes it really simple to build applications that sacriﬁce immediate consistency for the

huge performance improvements that come with simple distribution.

1.3.3 Local Consistency

Before we attempt to understand how CouchDB operates in a cluster, it’s important that we understand the inner

workings of a single CouchDB node. The CouchDB API is designed to provide a convenient but thin wrap-

per around the database core. By taking a closer look at the structure of the database core, we’ll have a better

understanding of the API that surrounds it.

The Key to Your Data

At the heart of CouchDB is a powerful B-tree storage engine. A B-tree is a sorted data structure that allows

for searches, insertions, and deletions in logarithmic time. As Figure 2. Anatomy of a view request illustrates,

CouchDB uses this B-tree storage engine for all internal data, documents, and views. If we understand one, we

will understand them all.

1.3. Eventual Consistency 11

Apache CouchDB, Release 2.0.0-git

Fig. 1.5: Figure 2. Anatomy of a view request

CouchDB uses MapReduce to compute the results of a view. MapReduce makes use of two functions, “map”

and “reduce”, which are applied to each document in isolation. Being able to isolate these operations means that

view computation lends itself to parallel and incremental computation. More important, because these functions

produce key/value pairs, CouchDB is able to insert them into the B-tree storage engine, sorted by key. Lookups

by key, or key range, are extremely efﬁcient operations with a B-tree, described in big O notation as O(log N)

and O(log N + K), respectively.

In CouchDB, we access documents and view results by key or key range. This is a direct mapping to the underlying

operations performed on CouchDB’s B-tree storage engine. Along with document inserts and updates, this direct

mapping is the reason we describe CouchDB’s API as being a thin wrapper around the database core.

Being able to access results by key alone is a very important restriction because it allows us to make huge perfor-

mance gains. As well as the massive speed improvements, we can partition our data over multiple nodes, without

affecting our ability to query each node in isolation. BigTable, Hadoop, SimpleDB, and memcached restrict object

lookups by key for exactly these reasons.

No Locking

A table in a relational database is a single data structure. If you want to modify a table – say, update a row –

the database system must ensure that nobody else is trying to update that row and that nobody can read from that

row while it is being updated. The common way to handle this uses what’s known as a lock. If multiple clients

want to access a table, the ﬁrst client gets the lock, making everybody else wait. When the ﬁrst client’s request is

processed, the next client is given access while everybody else waits, and so on. This serial execution of requests,

even when they arrived in parallel, wastes a signiﬁcant amount of your server’s processing power. Under high

load, a relational database can spend more time ﬁguring out who is allowed to do what, and in which order, than

it does doing any actual work.

Note: Modern relational databases avoid locks by implementing MVCC under the hood, but hide it from the end

user, requiring them to coordinate concurrent changes of single rows or ﬁelds.

Instead of locks, CouchDB uses Multi-Version Concurrency Control (MVCC) to manage concurrent access to the

database. Figure 3. MVCC means no locking illustrates the differences between MVCC and traditional locking

mechanisms. MVCC means that CouchDB can run at full speed, all the time, even under high load. Requests are

run in parallel, making excellent use of every last drop of processing power your server has to offer.

Documents in CouchDB are versioned, much like they would be in a regular version control system such as

Subversion. If you want to change a value in a document, you create an entire new version of that document and

12 Chapter 1. Introduction

Apache CouchDB, Release 2.0.0-git

Fig. 1.6: Figure 3. MVCC means no locking

save it over the old one. After doing this, you end up with two versions of the same document, one old and one

new.

How does this offer an improvement over locks? Consider a set of requests wanting to access a document. The

ﬁrst request reads the document. While this is being processed, a second request changes the document. Since

the second request includes a completely new version of the document, CouchDB can simply append it to the

database without having to wait for the read request to ﬁnish.

When a third request wants to read the same document, CouchDB will point it to the new version that has just

been written. During this whole process, the ﬁrst request could still be reading the original version.

A read request will always see the most recent snapshot of your database at the time of the beginning of the

request.

1.3.4 Validation

As application developers, we have to think about what sort of input we should accept and what we should reject.

The expressive power to do this type of validation over complex data within a traditional relational database

leaves a lot to be desired. Fortunately, CouchDB provides a powerful way to perform per-document validation

from within the database.

CouchDB can validate documents using JavaScript functions similar to those used for MapReduce. Each time you

try to modify a document, CouchDB will pass the validation function a copy of the existing document, a copy of

the new document, and a collection of additional information, such as user authentication details. The validation

function now has the opportunity to approve or deny the update.

By working with the grain and letting CouchDB do this for us, we save ourselves a tremendous amount of CPU

cycles that would otherwise have been spent serializing object graphs from SQL, converting them into domain

objects, and using those objects to do application-level validation.

1.3.5 Distributed Consistency

Maintaining consistency within a single database node is relatively easy for most databases. The real problems

start to surface when you try to maintain consistency between multiple database servers. If a client makes a

write operation on server A, how do we make sure that this is consistent with server B, or C, or D? For relational

databases, this is a very complex problem with entire books devoted to its solution. You could use multi-master,

single-master, partitioning, sharding, write-through caches, and all sorts of other complex techniques.

1.3.6 Incremental Replication

CouchDB’s operations take place within the context of a single document. As CouchDB achieves eventual con-

sistency between multiple databases by using incremental replication you no longer have to worry about your

database servers being able to stay in constant communication. Incremental replication is a process where doc-

ument changes are periodically copied between servers. We are able to build what’s known as a shared nothing

cluster of databases where each node is independent and self-sufﬁcient, leaving no single point of contention

across the system.

1.3. Eventual Consistency 13

Apache CouchDB, Release 2.0.0-git

Need to scale out your CouchDB database cluster? Just throw in another server.

As illustrated in Figure 4. Incremental replication between CouchDB nodes, with CouchDB’s incremental repli-

cation, you can synchronize your data between any two databases however you like and whenever you like. After

replication, each database is able to work independently.

You could use this feature to synchronize database servers within a cluster or between data centers using a job

scheduler such as cron, or you could use it to synchronize data with your laptop for ofﬂine work as you travel.

Each database can be used in the usual fashion, and changes between databases can be synchronized later in both

directions.

Fig. 1.7: Figure 4. Incremental replication between CouchDB nodes

What happens when you change the same document in two different databases and want to synchronize these

with each other? CouchDB’s replication system comes with automatic conﬂict detection and resolution. When

CouchDB detects that a document has been changed in both databases, it ﬂags this document as being in conﬂict,

much like they would be in a regular version control system.

This isn’t as troublesome as it might ﬁrst sound. When two versions of a document conﬂict during replication,

the winning version is saved as the most recent version in the document’s history. Instead of throwing the losing

version away, as you might expect, CouchDB saves this as a previous version in the document’s history, so that

you can access it if you need to. This happens automatically and consistently, so both databases will make exactly

the same choice.

It is up to you to handle conﬂicts in a way that makes sense for your application. You can leave the chosen

document versions in place, revert to the older version, or try to merge the two versions and save the result.

1.3.7 Case Study

Greg Borenstein, a friend and coworker, built a small library for converting Songbird playlists to JSON objects

and decided to store these in CouchDB as part of a backup application. The completed software uses CouchDB’s

MVCC and document revisions to ensure that Songbird playlists are backed up robustly between nodes.

Note: Songbird is a free software media player with an integrated web browser, based on the Mozilla XULRunner

platform. Songbird is available for Microsoft Windows, Apple Mac OS X, Solaris, and Linux.

Let’s examine the workﬂow of the Songbird backup application, ﬁrst as a user backing up from a single computer,

and then using Songbird to synchronize playlists between multiple computers. We’ll see how document revisions

turn what could have been a hairy problem into something that just works.

The ﬁrst time we use this backup application, we feed our playlists to the application and initiate a backup. Each

playlist is converted to a JSON object and handed to a CouchDB database. As illustrated in Figure 5. Backing

up to a single database, CouchDB hands back the document ID and revision of each playlist as it’s saved to the

database.

After a few days, we ﬁnd that our playlists have been updated and we want to back up our changes. After

we have fed our playlists to the backup application, it fetches the latest versions from CouchDB, along with

14 Chapter 1. Introduction

剩余412页未读，继续阅读

muyu_525

粉丝: 2
资源: 19

Apache CouchDB 2.0.0：技术概述与入门

Beginning CouchDB.pdf

CentOS7安装CouchDb

peer 如何访问couchdb

fabric 如何使用couchdb数据库

couchdb存储历史数据

CouchDB linux 安装

leveldb和couchdb区别

CouchDB常用的漏洞利用方法

couchdb登陆界面进不去

java po文件和couchdb数据库

最新资源