Couchbase Server开发指南：实战教程

5星 · 超过95%的资源需积分: 10 119 浏览量更新于2024-07-23 2 收藏 8.36MB PDF 举报

《Developing with Couchbase Server》是一本由MBrown编写的关于Couchbase Server的指南，专为IT专业人士设计。该书的ISBN为978-1-449-33116-0，版权属于2013年的Couchbase, Inc.，并享有所有权利。这本书由著名的O'Reilly Media出版，位于美国加利福尼亚州塞巴斯托波尔。本书是O'Reilly系列的"Nutshell Handbook"之一，以其简洁明快的风格向读者传授Couchbase Server的开发知识。封面设计由Randy Comer负责，内部设计则由David Futato操刀，插图由Rebecca Demarest绘制，确保了内容的专业性和视觉吸引力。首次发行日期为2013年2月，它标志着第一版的发布。作为一本技术手册，书中涵盖了Couchbase Server的核心概念、安装、配置、数据模型、查询处理、以及与之相关的生态系统集成等内容。作者MBrown以其深入浅出的方式，帮助读者理解Couchbase在现代分布式数据库中的角色，特别是在NoSQL领域中的应用优势。书中不仅提供理论知识，还包含实用的代码示例和最佳实践，以便开发者能够迅速上手并在实际项目中运用。对于那些希望在分布式、高可用性、实时数据分析方面寻求性能提升的团队和个人，本书是一份宝贵的参考资料。无论是初次接触Couchbase的新手，还是有一定经验的开发者，都能从中找到有价值的信息和学习资源。同时，O'Reilly在线版也为持续学习者提供了便利，让读者随时随地都能查阅最新更新和资料。此外，值得注意的是，书中提到的"LSI"可能是"Learning Series Index"（学习系列索引）的缩写，这是O'Reilly出版社的一个特色，用于组织和分类其专业书籍系列。而Nutshell Handbook和O'Reilly logo作为注册商标，代表了O'Reilly品牌对高质量技术教育的一贯承诺。《Developing with Couchbase Server》是一本全面且实用的Couchbase Server开发指南，对于任何希望在这个现代数据存储系统中开展高效开发工作的技术人员来说，都是一本不可或缺的参考书籍。

CHAPTER 1

Couchbase Overview

Couchbase Server is a NoSQL document database for interactive applications that has

a flexible data model, is easily scalable, provides consistently high performance, and is

“always on”, 24*7*365. From a developer perspective the key aspects are the flexible

data structure and the always-on nature. The data model is flexible because at the core,

Couchbase stores streams of bytes associated with a document ID. For additional fea‐

tures and practicality, that information can also be JSON-formatted (which brings ad‐

ditional functionality and benefits).

The scalability, performance and always-on nature are primarily focused on the ad‐

ministration and operations side, but they have one key impact on the developer expe‐

rience. Couchbase supports applications and data loads with a very high level of con‐

currency. It is not uncommon to find applications with millions of active users, thou‐

sands (and more) of data operations per second, and working with some very large

datasets.

The application Draw Something is a good example of a highly-concurrent application

built on top of Couchbase Server. Draw Something was a smartphone application that

allowed people to draw pictures, share it with friends, and let them guess what the picture

depicted. As is often the case with such a simple premise, the game became very popular,

very quickly. Within 6 weeks the game had gone from launch to an exceedingly popular

application with:

•

15 million daily active users

•

3,000 new pictures generated every two seconds

•

Over two billion stored drawings

To just about anybody, those are some staggering numbers. To an administrator, it be‐

comes more staggering when you appreciate that they managed this without taking the

site down, and grew from a fairly small 3 node cluster to more than 90 nodes (across

three clusters). All without taking the system offline, redeploying or architecting the

core application and the database service, and still while serving those millions of

picture-hungry users.

For a developer, Couchbase Server is actually a fairly straightforward application. Al‐

though the system is designed as a clustered database, as a developer this is not some‐

thing you need to frequently consider. Or even, at a practical level, to be aware of. Using

a Couchbase cluster with two nodes is the same as using a Couchbase cluster with 30

nodes. There are no complexities, no master/slave relationships or complex data han‐

dling that need to be supported at the client level.

To a developer, this is probably the most important aspect of the system to understand.

When developing with Couchbase the most important concerns are about your appli‐

cation and the data that it needs to store, rather than having to design, and later cope,

with sudden growth and complex and arduous scale out procedures.

Architecture and Structure

Couchbase Server is a cluster-based system where each node in the cluster is entirely

equal. The software and configuration of each node is identical.

The core of Couchbase Server is a document based storage sysytem, where individual

documents are identified by a unique document ID. Data is persisted to disk, and a

caching layer provides fast access to the stored objects.

For a developer using a database there can be no more important connection than the

one between your application and the underlying server. Couchbase Server supports a

number of different client libraries that connect to the cluster. From an application

perspective, the fact that the database is a cluster of individual nodes is entirely hidden

from the developer. Applications read and write document objects tot he cluster, and

the client library and Couchbase Server handle the distribution of information, and

where a specific object is located.

Buckets and vBuckets

Two important structures internally within Couchbase Server are Buckets and vBuckets.

The Bucket is a logical holder of information and is used to enable you to compart‐

mentalize information that you store into your database. Couchbase Server supports

multi-tenancy, that is, the ability for more than one application to store and retrieve

information within Couchbase. Buckets are the logical elements used to support this.

Buckets are:

Named

All buckets have a name used to identify them on the system.

2 | Chapter 1: Couchbase Overview

Shared

All bucket data is automatically shared (and sharded) across the Couchbase Server

cluster. You cannot control how the information is distributed (it is automatically

controlled), but your client library will handle the communication directly between

your client and each node in the cluster to identify where the data should be stored

(or retrieved) from.

Optionally password controlled

All buckets can have an optional password. This can be useful both for securely

providing access to the information in your database, and to help prevent you from

accidentally connecting to the wrong bucket and updating/deleting information.

Independently managed and monitored

Each bucket has a RAM quota, replication configuration and disk storage. Each

bucket can also be independently monitored, and each bucket can be independently

compacted and indexed.

Applications can use one or more buckets for storing information, but it’s important to

remember that from a server perspective, buckets cannot talk to each other. This has

particular impact on views and indexing. The current limit of the number of buckets

that can be configured within a single cluster is 10.

Now we know that the information is automatically sharded and distributed around the

cluster. Without wanting to get ito too much detail, the method of distribution is by

dividing up the bucket content into multiple vBuckets. The vBuckets are distributed

around the cluster, and because there are a fixed number of vBuckets, we can hash the

document ID to a vBucket, and then through a vBucket map, map the vBucket to a node.

When you store a document in the database, the document ID is processed by a hashing

algorithm that produces a number, the number refers to the vBucket, and the client

library uses the vBucket map to to determine which node within the cluster that is

responsible for the vBuckets.

The vBucket structure is critical to the way the Couchbase Server works and is flexible

and scalable. When the cluster is extended, individual vBuckets (and the data they con‐

tain) are ‘rebalanced’ around the cluster. Since the number of vBuckets does not change,

finding the vBucket number for a given document ID has not changed. The hash is

computed, the vBucket number determined, and the vBucket map is used to identify

the node. Because a given document ID will always compute the same vBucket ID, and

the vBucket map always describes this structure, the number of nodes in the cluster can

change, shrinking or expanding to cope with different application loads.

For an analogy, let’s consider the typical, physical, filing cabinet. The filing cabinet is

constructed of different drawers (our nodes), and there are a fixed number of folders

within the drawers (with each folder analogous to the vBucket). On the wall by the filing

cabinets is a directory that tells you which drawer contains which folder. If I buy a new

Buckets and vBuckets | 3

filing cabinet, I can move the folders around within the drawers so that they are evenly

distributed. Once I’ve completed that operation, I then need to update my directory

(our vBucket map). To round the analogy out, there is only one copy of any piece of data

within the drawers at one time. Because the data is automatically sharded and dis‐

tributed, there is no problem in ensuring that the different ‘versions’ of the data across

the database are in sync. There is only one version of the data. For additional security,

however, you can use replication to create a copy of all the data in a bucket. The replicas

are distributed around the stored data, just like keeping a carbon copy or photocopied

version of each file in a different drawer.

As a developer, you don’t need to know about the vBucket system, since your client

library will handle the entire hashing/lookup and communication process for you, all

you need to do is connect your application to your cluster. That said, some of the errors

returned by the system will refer to a vBucket specific problem, hence why I’ve included

this background.

Data Storage and Retrieval

The most important part of any database system is how you store and retrieve the in‐

formation from the database. Couchbase Server is a document store, you store data into

the database using a document ID and the corresponding document data. The docu‐

ment ID must be unique within the bucket, but the document value that you store can

be anything—a stream of bytes, a serialized object from your application language, or

a flexible document format such as JSON. We’ll return to the significance of JSON in a

moment.

Because of the document nature, the storage and retrieval of information is straight‐

forward. There are no complicated queries or structures to write, and in fact, the core

operations can be summarized into just four types of statements: Create, Read, Update,

and Delete (CRUD). You can see these four statements in Table 1-1.

Table 1-1. Basic operations

Operation Example Sample Command

Create store(DocumentID, DocumentValue) add(), set()

Read get() get(DocumentID)

Update Update(DocumentID, DocumentValue) replace(), incr(), decr(), append(), prepend(), cas()

Delete delete(DocumentID) delete()

As you can see, the basic operations are very simple, and this ultimately makes the

programming and application development very simple. Documents are updated

wholesale, when creating, you store the whole document, and when updating, you get

the whole document, change the content or portion you want to change, and save it

back.

4 | Chapter 1: Couchbase Overview

剩余86页未读，继续阅读

cqjc

粉丝: 1
资源: 2

Couchbase Server开发指南：实战教程

Pro Couchbase Server

Pro Couchbase Server(Apress,2ed,2015)

couchbase-server-enterprise_2.5.1_x86_64

rage-with-couchbase-2020:使用Couchbase Server作为数据存储的React，Apollo，GraphQL和Express！

rage-with-couchbase-final:我们的“带有Couchbase的RAGE”教程的最终状态，它使用Couchbase Server构建了一个完整的React，Apollo，GraphQL和Express应用程序

couchbase-clj:Couchbase Server 2.x的Clojure客户端

couchbase-java-client:Couchbase Server的官方Java客户端

couchbase-admin-console:Couchbase Server 的简单数据管理控制台

loopback-example-couchbase:演示如何将 Loopback 与 Couchbase Server 结合使用的示例

Chatbase：使用Couchbase Lite，Sync Gateway和Couchbase Server的简单（移动）聊天应用程序

最新资源