Couchbase 2.0开发者指南：构建应用详解

需积分: 9 95 浏览量更新于2024-07-23 收藏 3.27MB PDF 举报

"Couchbase Developer's Guide 2.0" 是一本针对Couchbase Server 2.0的开发人员手册，它旨在帮助开发者构建应用程序，充分利用Couchbase作为一个灵活的NoSQL数据库系统。该指南强调了与所选软件开发工具包（SDK）的配合使用，提供了深入理解Couchbase核心概念的基础。首先，Couchbase作为一个文档存储系统，其核心理念是将数据视为键值对形式的文档，每个文档都有一个唯一的键，可以包含结构化和非结构化的数据。这使得Couchbase在处理大规模、分布式数据时具有高可扩展性和灵活性，适合于实时数据处理和复杂查询场景。章节1.1 "Understanding Couchbase Concepts"深入探讨了Couchbase的关键组件，如数据桶（Data Buckets），它们是逻辑上的容器，用于组织和存储数据。每个数据桶有自己的配置选项，如内存大小和复制策略，以满足不同应用场景的需求。同时，Couchbase中的键（Keys）与文档紧密相关，它们是唯一标识文档的标识符，允许高效地检索和操作数据。指南还强调了Couchbase Server 2.0的客户端库（Client Libraries），这些库为各种编程语言提供了API，使得开发者可以轻松地在Couchbase上进行操作，无论是插入、更新、删除还是查询数据。此外，指南还提到了Couchbase Server Forum，这是一个开发者社区资源，提供技术支持、最佳实践分享以及与其他开发者互动的平台。文档更新时间为2013年3月，反映了当时的技术状态，但开发者仍可以从Couchbase官方网站获取HTML在线文档，以及访问Couchbase Documentation Library获取更多资料。版权信息和文档许可在附录中详细列出，以便用户了解使用指南的条款。本书还包括一个详尽的目录，引导读者从预览到具体的指南内容，包括介绍、手册约定、贡献者名单、以及从基础知识到高级主题的全面指导。这本手册是Couchbase 2.0开发人员不可或缺的参考资料，有助于他们在实践中快速掌握并利用Couchbase的优势。

Introduction to Couchbase

Session Store

User sessions are easily stored and managed in Couchbase, for instance, by using the document ID naming scheme,

"user:USERID". With Couchbase Server, you can flag items for deletion after a certain amount of time, and therefore you

have the option of having Couchbase automatically delete old sessions.

Optimistic concurrency operations can be used to ensure concurrent web requests from a single user do not lose data. For

more information, see Section 3.9.3, “Check and Set (CAS)”.

Many web application frameworks such as Ruby on Rails and various PHP and Python web frameworks also provide pre-

integrated support for storing session data using Memcached protocol. These are supported by default by Couchbase.

For more detailed information, including case studies and whitepapers, see Couchbase NoSQL Use Cases.

Social Gaming

You can model and store game state, property state, time lines, conversations and chats with Couchbase Server. The asyn-

chronous persistence algorithms of Couchbase were designed, built and deployed to support some of the highest scale so-

cial games.

In particular, the heavy dual read and write storage access patterns of social games, where nearly every user gesture mu-

tates game state, is serviced by Couchbase by asynchronously queueing mutations for disk storage and also by collapsing

mutations into the most recently queued mutation. For example, a player making 10 game state mutations in 5 seconds,

such as planting 10 flowers in 5 seconds, will be compressed by Couchbase automatically into just one queued disk muta-

tion.

Couchbase Server can also force-save mutated item data to disk, even if an item is heavily changed, such as when the user

keeps on clicking and clicking. Additionally, game state for that player remains instantly readable as long as it is in the

memory working set of Couchbase.

For more detailed information, including case studies and whitepapers, see Couchbase NoSQL Use Cases.

Ad, Offer and Content Targeting

The same attributes which serve Couchbase in the gaming context also apply well for real-time ad and content targeting.

For example, Couchbase provides a fast storage capability for counters. Counters are useful for tracking visits, associating

users with various targeting profiles, tracking ad-offers, and for tracking ad-inventory.

Multi-retrieve operations in Couchbase allow ad applications to concurrently distribute data and then gather it against pro-

files, counters, or other items in order to allow for ad computation and serving decisions under strict response latency re-

quirements.

For more detailed information, including case studies and whitepapers, see Couchbase NoSQL Use Cases.

Chapter 2. Modeling Documents

This section describes core elements you will use to handle data in Couchbase Server; it will describe the ways you can

structure individual JSON documents for your application, how to store the documents from a Couchbase SDK, and de-

scribe different approaches you may take when you structure data in documents.

Couchbase Server is a document database; unlike traditional relational databases, you store information in documents

rather than table rows. Couchbase has a much more flexible data format; documents generally contains all the information

about a data entity, including compound data rather than the data being normalized across tables.

A document is a JSON object consisting of a number of key-value pairs that you define. There is no schema in Couchbase;

every JSON document can have its own individual set of keys, although you may probably adopt one or more informal

schemas for your data.

As of Couchbase Server 2.0, one of the benefits of using JSON documents is that you can index and query these records.

This enables you to collect and retrieve information based on rules you specify about given fields; it also enables you to

retrieve records without using the key for the record. For more information about indexing and querying using Couchbase

SDK, see Chapter 4, Finding Data with Views.

2.1. Comparing Document-Oriented and Relational Data

In a relational database system you must define a schema before adding records to a database. The schema is the structure

described in a formal language supported by the database and provides a blueprint for the tables in a database and the re-

lationships between tables of data. Within a table, you need to define constraints in terms of rows and named columns as

well as the type of data that can be stored in each column.

In contrast, a document-oriented database contains documents, which are records that describe the data in the document,

as well as the actual data. Documents can be as complex as you choose; you can use nested data to provide additional sub-

categories of information about your object. You can also use one or more document to represent a real-world object. The

following compares a conventional table with document-based objects:

Figure 2.1. Conventional RDMS Table and Document-based Information

Modeling Documents

In this example we have a table that represents beers and their respective attributes: id, beer name, brewer, bottles avail-

able and so forth. As we see in this illustration, the relational model conforms to a schema with a specified number of

fields which represent a specific purpose and data type. The equivalent document-based model has an individual document

per beer; each document contains the same types of information for a specific beer.

In a document-oriented model, data objects are stored as documents; each document stores your data and enables you to

update the data or delete it. Instead of columns with names and data types, we describe the data in the document, and pro-

vide the value for that description. If we wanted to add attributes to a beer in a relational mode, we would need to modify

the database schema to include the additional columns and their data types. In the case of document-based data, we would

add additional key-value pairs into our documents to represent the new fields.

The other characteristic of relational database is data normalization; this means you decompose data into smaller, related

tables. The figure below illustrates this:

Figure 2.2. Data Normalization in Traditional RDBMS

In the relational model, data is shared across multiple tables. The advantage to this model is that there is less duplicat-

ed data in the database. If we did not separate beers and brewers into different tables and had one beer table instead, we

would have repeated information about breweries for each beer produced by that brewer.

The problem with this approach is that when you change information across tables, you need to lock those tables simul-

taneously to ensure information changes across the table consistently. Because you also spread information across a rigid

structure, it makes it more difficult to change the structure during production, and it is also difficult to distribute the data

across multiple servers.

In the document-oriented database, we could choose to have two different document structures: one for beers, and one for

breweries. Instead of splitting your application objects into tables and rows, you would turn them into documents. By pro-

viding a reference in the beer document to a brewery document, you create a relationship between the two entities:

Modeling Documents

When you use JSON documents to represent your application data, you should think about the document as a logical con-

tainer for information. This involves thinking about how data from your application fits into natural groups. It also re-

quires thinking about the information you want to manage in your application. Doing data modeling for Couchbase Server

is a similar process that you would do for traditional relational databases; there is however much more flexibility and you

can change your mind later on your data structures. As a best practice, during your data/document design phase, you want

to evaluate:

• What are the things you want to manage in your applications, for instance, users, breweries, beers, and so forth.

• What do you want to store about the things. For example, this could be alcohol percentage, aroma, location, etc.

• How do the things in your application fit into natural groups.

For instance, if you are creating a beer application, you might want particular document structure to represent a beer:

{

"name":

"description":

"category":

"updated":

}

For each of the keys in this JSON document you would provide unique values to represent individual beers. If you want to

provide more detailed information in your beer application about the actual breweries, you could create a JSON structure

to represent a brewery:

{

"name":

"address":

"city":

"state":

"website":

"description":

}

Performing data modeling for a document-based application is no different than the work you would need to do for a rela-

tional database. For the most part it can be much more flexible, it can provide a more realistic representation or your appli-

cation data, and it also enables you to change your mind later about data structure. For more complex items in your appli-

cation, one option is to use nested pairs to represent the information:

{

"name":

"address":

"city":

"state":

"website":

"description":

"geo":

{

"location": ["-105.07", "40.59"],

"accuracy": "RANGE_INTERPOLATED"

}

"beers": [ _id4058, _id7628]

}

In this case we added a nested attribute for the geo-location of the brewery and for beers. Within the location, we provide

an exact longitude and latitude, as well as level of accuracy for plotting it on a map. The level of nesting you provide is

your decision; as long as a document is under the maximum storage size for Couchbase Server, you can provide any level

of nesting that you can handle in your application.

In traditional relational database modeling, you would create tables that contain a subset of information for an item. For

instance a brewery may contain types of beers which are stored in a separate table and referenced by the beer id. In the

case of JSON documents, you use key-values pairs, or even nested key-value pairs.

剩余140页未读，继续阅读

cqjc

粉丝: 1
资源: 2

Couchbase 2.0开发者指南：构建应用详解

Couchbase Developer's Guide 开发指南2.0.pdf.zip

couchbase-java-cache:Couchbase Java SDK 2.0 的 JCache 实现

couchbase-net-examples:配置和使用Couchbase .NET SDK 2.0的示例

Couchbase

couchbase-java-samples:Couchbase Java SDK 1.4.x和2.0.x的样本

Couchbase Essentials

couchbase中文

couchbase安装

Learning Couchbase

docker-couchbase:Couchbase Dockerfile

最新资源