Oracle Berkeley DB 中国研发团队的博客 » Berkeley DB JE

在多个节点上部署Oracle NoSQL数据库

chaohuang — Fri, 02 Dec 2011 08:27:32 +0000

`在多个节点上部署Oracle NoSQL数据库`

`1. 简介`

Oracle NoSQL数据库是一款基于Berkeley DB Java Edition构建的，分布式的，跨数据中心的Key-Value数据库。它是一款高性能，和极短的响应时间（毫秒级）的云数据库方案。Oracle NoSQL数据库使客户能够轻松地管理大量的，动态模式 (dynamic schemas) 的数据，如Web日志数据，传感器和智能仪表的数据，用户个性化数据，和社交网络的数据。 Oracle NoSQL DB是采用Oracle Berkeley DB Java Edition做底层存储引擎，但我们在其之上添加了更多的基础架构层的功能，如：数据分布动态分区负载平衡监控和管理可预见的延迟多节点备份举例来说，Oracle NoSQL DB是汽车的话，Oracle BDB则算汽车引擎。 Oracle NoSQL数据库会有商业版和社区版两个版本。当前发行的第一个版本中(v1.1.100)，两者没有功能上的区别（商业版有Oracle的支持服务）。目前商业版本已经开放下载：http://t.cn/SvbsUm 它包括数据库产品本身的Java类库，第三方类库，示例代码，文档，启动脚本和基于Google GWT实现的管理功能。

2. Oracle NoSQL数据库在企业部署的示例图

如下图所示，在当今的企业部署中，Oracle NoSQL数据库可以和传统的关系型数据库混合搭配提供服务。比如，NoSQL数据库可以运行有实时要求的、非结构化的应用；关系型数据库可以用来执行查询分析、交易结算等功能。举个在线电子商务的应用来说，和用户相关的注册信息、个人头像、评论、爱好、购物车、网站的静态图片、商品等信息可以存在 Oracle NoSQL数据库；而当用户选定进行结算时，则可以通过Oracle关系型数据库进行支付等操作。

Oracle NoSQL数据库分客户端和服务端2个部分。客户端提供给应用程序的API调用（如Put，Get，Delete，Multi Put/Get/Delete，Iterator等），以及服务端的一些状态和统计信息（如数据分区、机器负载等）。目前客户端仅提供Java接口，暂时不支持其他语言。

而服务端则具体用来管理数据，提供数据库操作、并发控制、一致性和扩展性、管理功能等。在下图中，每个Storage Node代表着数据中心中的一台物理或者虚拟的机器（VM），这些机器可以是跨数据中心的。而针对整个NoSQL数据库的管理进程可以部署在某个Storage Node上。我们提供命令行和web两种管理接口。

Oracle NoSQL数据库在企业部署示例图

3. 在多个节点上部署NoSQL数据库

目前Oracle NoSQL数据库只支持在Linux或者Solaris （10及以上）机器上进行部署，这是由于部署及管理的脚本是bash的。如果你要在Windows上进行部署，你可以有2种办法：使用 Cygwin，MingGW等类Linux工具；或者将NoSQL部署脚本转换成Windows的bat脚本（可参考 https://forums.oracle.com/forums/thread.jspa?threadID=2307203&tstart=0 ）。你也可以尝试在类Linux的系统（如Unix）上实验部署Oracle NoSQL数据库。为了性能考虑，我们不推荐你使用虚拟机。

3.1 前期准备

JDK 1.6.0 u25或以上。
一台或者多台Linux或者Solaris （10及以上）机器。
保证机器之间时间同步。你可以使用ntp等工具。
Oracle NoSQL数据库发布包，如kv-1.1.100.zip。

3.2 安装步骤

a. 创建启动配置参数文件

b. 启动管理进程和存储节点代理进程(Storage Node Agent, 简称SNA)

c. 通过Oracle NoSQL数据库管理（命令行或者web方式）配置一个NoSQL库，步骤如下：

1) 创建一个数据中心

2) 部署一台Storage Node，用来运行该NoSQL库的管理模块

3) 将管理模块部署到Storage Node上（该步骤在步骤b的基础上增加了对NoSQL数据库级别的管理功能，因此管理节点和端口必须一致）

4) 创建一个Storage Node池

5) 将步骤2)创建的Storage Node加到存储节点池

6) 将剩余节点(Storage Node) 轮流部署并加入到存储节点池

7) 在指定的存储节点池上部署NoSQL库，指定复制因子和数据分区数。

d. 在客户端运行HelloBigDataWorld示例程序，验证数据库是否部署成功。

3.3 实际部署示范

对照3.2的过程，简单起见我们在3个节点上部署一个NoSQL数据库实例，并运行HelloBigDataWorld例子。

1. 下载Oracle NoSQL数据库发布包（如kv-1.1.100.zip），并解压释放。释放文件的文件夹约定为KVHOME。（注意：如果是多机环境，你要将发布包释放或者映射到每台机器的对应目录。）

2. 创建存放数据文件的目录，约定为KVROOT。多机的话，每台机器一样要创建数据文件目录。

3. 在管理节点上，创建启动配置参数文件

> KVHOME/bin/kvctl makebootconfig -root KVROOT \
                                  -port 5000 \
                                  -admin 5001 \
                                  -harange 5010,5020

4. 启动管理进程和存储节点代理进程

> KVHOME/bin/kvctl start -root KVROOT

5. 在管理节点上：验证管理进程和存储节点代理进程是否顺利启动

> jps -m
29400 ManagedService -root /tmp -class Admin -service BootstrapAdmin.13250 -config config.xml
29394 StorageNodeAgentImpl -root /tmp -config config.xml

# 如果顺利启动则会出现上面所示的2个进程

6. 在客户端：验证客户端是否可以顺利“联系”存储节点代理进程

> KVHOME/bin/kvctl ping -port 5000 -host node01

# 如果成功则出现如下所示的信息：
SNA at hostname: node01, registry port: 5000 is not registered.
            No further information is available

# 否则，不成功的话，会出现如下错误：
Could not connect to registry at node01:5000
Connection refused to host: node01; nested exception is:
java.net.ConnectException: Connection refused

7. 通过命令行配置一个NoSQL数据库实例

7.1 使用命令行单步执行

1) 启动管理功能的命令行

> KVHOME/bin/kvctl runadmin -port 5000 -host node01

2) 指定数据库名字

kv-> configure mystore

3) 创建一个数据中心 

kv-> plan -execute -name "Deploy DC" deploy-datacenter "Boston" "Savvis"
1
kv->

4) 部署一台Storage Node，用来运行该NoSQL库的管理模块

kv-> plan -execute -name "Deploy n01" deploy-sn 1 node01 5000 "comment"
2
kv->

5) 将管理模块部署到Storage Node上 （该步骤在步骤b的基础上增加了对NoSQL数据库级别的管理功能，因此管理节点和端口必须一致）

kv-> plan -execute -name "Deploy admin" deploy-admin 1 5001
3
kv->
6) 创建一个Storage Node池

kv-> addpool BostonPool
kv-> show topology
dc=[dc1] name=Boston
 sn=[sn1]  dc=dc1 node1:5000 status=UNREPORTED
7) 将步骤2)创建的Storage Node加到存储节点池

kv-> joinpool BostonPool 1
AllStorageNodes: sn1
BostonPool: sn1
kv->
8 ) 将剩余节点(Storage Node) 轮流部署并加入到存储节点池

kv-> plan -execute -name "Deploy n02" deploy-sn 1 node02 5000
4
kv-> joinpool BostonPool 2
AllStorageNodes: sn1 sn2
BostonPool: sn1 sn2
kv-> plan -execute -name "Deploy n03" deploy-sn 1 node03 5000
5
kv-> joinpool BostonPool 3
AllStorageNodes: sn1 sn2 sn3
BostonPool: sn1 sn2 sn3
kv->

....
9) 在指定的存储节点池上部署NoSQL库，指定复制因子和数据分区数

kv-> plan -execute -name "Deploy the store" deploy-store BostonPool 3 300

10) 查询所有以上步骤的结果

kv-> show plans
1 Deploy Boston DC         SUCCEEDED
2 Deploy n01               SUCCEEDED
3 Deploy admin             SUCCEEDED
4 Deploy n02               SUCCEEDED
5 Deploy n03               SUCCEEDED
6 Deploy the store         SUCCEEDED

11) 退出命令行

kv-> quit

7.2 使用脚本

1) 启动管理功能的命令行，并指定运行的脚本

> KVHOME/bin/kvctl runadmin -port 5000 -host node01 -script scrpt.txt
kv-> 

执行脚本(scrpt.txt)内容如下：

### Begin Script ###
configure mystore
plan -execute -name "Deploy Boston DC" deploy-datacenter "Boston" "Savvis"
plan -execute -name "Deploy n01" deploy-sn 1 node01 5000
plan -execute -name "Deploy admin" deploy-admin 1 5001
addpool BostonPool
joinpool BostonPool 1
plan -execute -name "Deploy n02" deploy-sn 1 node02 5000
joinpool BostonPool 2
plan -execute -name "Deploy n03" deploy-sn 1 node03 5000
joinpool BostonPool 3
plan -execute -name "Deploy the store" deploy-store BostonPool 3 300
### End Script ###

2) 查询所有以上步骤的结果

kv-> show plans
1 Deploy Boston DC         SUCCEEDED
2 Deploy n01               SUCCEEDED
3 Deploy admin             SUCCEEDED
4 Deploy n02               SUCCEEDED
5 Deploy n03               SUCCEEDED
6 Deploy the store         SUCCEEDED

3) 退出命令行

kv-> quit

8. 在客户端运行HelloBigDataWorld示例程序，验证数据库是否部署成功。

在客户端编译示例程序：

javac -g -cp lib/kvclient-M.N.O.jar:examples examples/hello/*.java

运行该示例程序：

java -cp KVHOME/lib/kvclient-M.N.O.jar:KVHOME/examples \
     hello.HelloBigDataWorld \
     -host  -port  -store  

如果输出结果为 "Hello Big Data World!"，那么恭喜你，你的第一个Oracle NoSQL数据库已经配置成功了。

4. 卸载NoSQL数据库

卸载的过程比较直观，有2种办法：

1. 在每个Storage Node节点上：通过kvctl停止数据库，然后移除KVROOT目录。

a) kvctl stop -root KVROOT/

b) rm KVROOT/

2. 在每个节点上kill掉所有NoSQL数据库的Java进程（通过jps -m定位进程号），然后移除KVROOT目录。备注：这里基于的假设是Oracle NoSQL数据库是7*24的不间断应用，因此目前的办法是逐个Storage Node来停止服务，并删除数据。

5. 后续

当你的NoSQL成功部署以后，你可能会去读一下Oracle NoSQL数据库的FAQ和Getting Started Guide来编写你的第一个NoSQL应用。你也可能会要去查询对应的Javadoc以及示例代码。

如果是数据库管理员的话，你可能会去读一下Oracle NoSQL数据库的FAQ和Administrator’s Guide。

以上所有这些文档在你下载的Oracle NoSQL发布包中，或者你也可以访问 http://docs.oracle.com/cd/NOSQL/html/index.html 如果有更多问题，欢迎通过邮件和我联系： chao.huang[at]oracle[dot]com；或者通过新浪微博和我们互动： weibo.com/bdbchina。转载请注明出处，谢谢。

Berkeley DB Java Edition 高可用性介绍

chaohuang — Wed, 07 Sep 2011 09:19:07 +0000

这是一篇译文，现在贴过来。原文见JE官网http://www.oracle.com/technetwork/database/berkeleydb/overview/index-093405.html的底部“Berkeley DB Java Edition High Availability”一栏。

概览

Oracle Berkeley DB Java版高可用性（JE HA）是一个支持replication特性的事务性数据管理系统。JE HA提供的高可用特性可以极大提升数据读操作的可扩展性（scalability）及其性能。

这份白皮书将详细介绍JE HA的关键概念和主要特性，从而让开发人员和应用软件设计者理解如何最好地利用JE HA解决软件开发中特有的数据管理问题。

本白皮书同时也讨论了软件架构师在设计基于JE HA的应用时，如何从技术的角度权衡各方面的性能与资源。

基本介绍

Oracle Berkeley DB Java版本（JE）在最新的发布版本中引进了一个新特性，即高可用性（high availability，简称为HA）。JE是一个事务性的数据管理系统，最新版本的JE 便是在之前版本的基础上做了扩展，加入了HA的特性。

用户在应用程序中可以利用JE的直接持久层（DPL）创建用于存储Java对象的索引数据库。在JE中，多个数据库操作可以包含进一个事务（transaction）中，从而得到事务所提供的原子性、一致性、分离性和持久性（ACID）等事务特性。如果应用程序或者系统发生故障，JE的故障恢复机制（recovery）可以使应用程序的数据恢复到一致的状态。

JE HA是一个嵌入式数据管理系统，它在具备JE全部功能的基础上，为JE提供replication规则，即“主节点（master）可以执行读/写操作，副节点（replica）只能执行读操作”。这种规则意味着数据库读与写操作都可以在单个主节点中进行，而在副节点上只能进行读操作。如果主节点发生故障被关闭，那么JEHA将在所有副节点中自动选择其中一个作为新的主节点，这样，所有的读写操作就可以在新的主节点中进行。作为一个嵌入式的类库，JE HA可以广泛应用在各种硬件配置和环境中。

JE HA主要解决以下三个应用上所面临的难题：

在不允许宕机的应用场景中，能够迅速进行热备切换（failover）；
通过配置多个只读副节点以提供读操作的可扩展性；
在实现数据持久性（durability）时，允许应用程序将数据提交到（快速的）网络，而不是（缓慢的）磁盘，从而使事务的提交更加高效。

然而，JE HA不适用于需要对写操作进行扩展的应用场景。这类应用场景需要数据分区（data partition），然后在每一个数据分区中运行一个JE HA的环境。同样，JE HA也不提供与其他数据库进行数据同步的功能。本白皮书不再赘述这两方面的应用。

除去上述两个应用场景，JE HA可以广泛应用在各种环境中。下面分别进行简单的介绍。

基于小型局域网的数据复制备份：基于数据中心的服务可以向本地的多个机器提供数据，比如一个公司网站。这种服务由几台安放在同一个数据中心的服务器提供，这些服务器通过高速的局域网互联。
广域数据存储：广域数据存储服务可以存储大量的账户信息，用户可以在全球任何地方访问这些信息。这种服务由许多分布在全球多个地方的数据中心的服务器提供。这些服务器通过数据中心之间的高速网络进行通信。
主节点/从节点：提供主从节点机器的热备切换。

JE HA可以在广泛的应用环境中对数据进行replication，而单独一种数据管理和replication机制并不能适用于所有环境。因此，JE HA可以让应用程序控制主副节点之间的数据一致性程度，事务持久性，以及提供了其他可以提升性能、可靠性以及数据可用性的各种设计选择。这份白皮书的目的就是介绍这些选择和配置，并且提供足够的细节便于用户的理解，这样用户在设计应用程序时可以做出正确的选择和取舍。

JE HA概述

这一章节将描述JE HA的总体架构和关键概念。

下文中，术语“数据库”（Database）用于表示一组键/值对（key/value pair）数据集，这些键/值对数据集共享一个索引数据结构，它对应于关系型数据库管理系统（RDBMS）中表（table）的概念。术语“环境”（Environment）用于表示一组具有逻辑关系的Berkeley DB数据库集合，以及相关的元数据（meta-data）和内部文件。每个环境用一个文件目录命名。可以看出，环境就是RDBMS中数据库的概念。也就是说，下文中涉及的数据库就是RDBMS中的表，而环境就是RDBMS中的数据库。

JE HA将一个环境在一个replication group中的各个节点之间进行replication操作。一个环境就是一个replication单元。在一个replication的环境中，所有数据库都支持replication操作和满足事务性。

Replication group

一个replication group是一个节点集合。这些节点都将参与到环境的replication过程中。一个replication group由两种节点组成：可选（Electable）节点和监测（Monitor）节点。

每个可选节点都拥有一份可进行replication的环境副本，它既可作为主节点，也可作为副节点。一个可选节点将通过一种分布式的两阶段投票协议（distributed two-phase voting protocol）而被选举成为一个主节点。这种投票协议将可以保证每次仅选举出一个主节点。所有参与选举的节点中，拥有最新环境数据的节点将被选为主节点。一个可选节点可以进入以下几种状态（但每个时间点只能进入一种状态）：

主节点（Master）状态：一个节点将通过简单多数（或者叫过半数，simple majority）原则，在众多可选节点中被选举为主节点。一个节点变成主节点后可以进行读和写操作。
副节点（Replica）状态：副节点通过replication stream与主节点进行通信。Replication stream用于跟踪记录在主节点中所做的任何更新。在后续章节中将会对replication stream做详细的介绍。副节点只支持读操作。
未知（Unknown）状态：一个节点处于未知状态意味着此节点不能识别主节点，并不断尝试着寻找主节点，或者联系其他成员节点来进行主节点选举。处于未知状态的节点将不断尝试过渡到主节点或者副节点状态。这种状态的节点如果能满足事务性的一致性要求（下文将详细描述），那么它仍然可以进行读操作。
分离（Detached）状态：一个节点处于分离状态意味着此节点已经被关闭（shutdown）。处于分离状态的节点仍然属于replication group中的成员，但它并不是一个活跃节点（active node）。同样，如果一个节点不处于分离状态，则意味着它是活跃节点。

注：为了简略，术语“主节点”和“副节点”在以下的讨论中将用于表示replication group中的某节点正处于主节点状态和副节点状态。

监测节点（monitor node）用于跟踪和监视一个replication group中所有可选节点的当前状态。所有新节点的加入和当前节点的删除所引起的replication group结构的变化都会被监测节点监听到。监测节点同时也能监听所有可选节点的动态状态变化（即此节点处于活跃状态抑或分离状态）。监测节点没有任何持久的状态，也不拥有可进行replication的环境副本。应用程序可以利用监测节点将所有的写请求路由到replication group当前的主节点中，同时将读请求路由到replication group的副节点中。另外，只有应用程序需要调用监测节点，监测节点才会被replication group所创建。也就是说，监测节点并不是必需的。

一个replication group中的多个副节点可以分布到多台物理机器中，这样可以保证单个机器上的故障或者宕机不会影响到同组中的其他节点。但不同replication group中的多个副节点运行在同一个物理机器中的情形也并不少见。这种配置在某些应用场景中是十分有用的。例如，实现数据分区，这种应用场景在后面章节会有详细描述。

图一清楚描述了一个replication group G中的主要元素：三个可选节点（N1，N2 和N3）以及两个监测节点（M1和M2）。

（图一） Replication group G。可选节点：G（N1），G（N2）和G（N3）。两个监测节点：G（M1）和G（M2）。

Replication group的生命周期

一个replication group总是从一个节点开始，这第一个节点会被默认成为主节点。一个可进行replication的环境可以是空的，或者是一个已存在的独立（standalone）的环境。但这个环境被转换成一个可进行replication的环境格式之后，可以往这个replication group中加入新的可选节点，这样会增加组的大小，同时也会增加主节点选举和数据持久性所需要的有效可选节点的数目（quorum）。

一个新的可选的节点通常需要经过以下几步才能真正参与到replication group中（即成为活跃节点）：

新节点找到主节点，并且提供自身的配置信息。
主节点把新节点的信息存储到内部一个用于记录组节点信息的可进行replication的数据库中。其他可选举节点将通过replication stream获知新节点的信息。至此，新节点可被视为是replication group中的一名成员节点。
此新成员节点开始初始化它所拥有replication环境副本。如果某些日志文件已经被JE 的日志清除器（log cleaner）所回收，那么新节点将调用一个叫做Network Restore的操作，从组内某一个成员节点中直接拷贝一份日志文件，并且用这份日志副本作为重演（replay）replication stream的起始点。
新节点重演replication stream，直到它满足一致性的要求为止。

满足一致性要求之后，新成员节点就成为一个活跃的副节点。它将可以为应用程序提供读操作，并且可以在热备切换过程中被选为主节点。

由于监测节点不需要为应用程序提供数据的读写服务，所以它并不拥有可进行replication的环境副本。因此加入一个监测节点很简单，只需要在主节点所拥有的环境副本中加入此监测节点的信息。这样，其他成员节点可以利用该信息与监测节点通信，向监测节点通知有关组内的变化，例如某次选举，或者组内成员的组成变化（新增节点或者删除节点）。同样，由于没有环境副本，当监测节点在每次启动的时候，它必须查询其他可选节点以判定组内当前成员节点的构成和状态。

如果节点运行的机器发生故障或宕机时，replication group有可能会由于组内节点数目无法达到有效可选节点数而无法运行。这些发生故障的节点可以通过JE HA提供的API显式地进行删除，这样余下的成员节点数目便可以满足有效可选节点数的要求，从而replication group可以恢复到正常的运行状态。当然，节点的删除往往意味着数据可持久性的降低。

Replication stream

所有发生在主节点上的写事务操作都将通过一种逻辑意义上的replication stream被复制到所有副节点中。这种replication stream是建立在TCP/IP连接之上，这种连接是主节点和每个副节点之间的专用连接。Replication stream包含主节点上的一些逻辑变化，这些逻辑变化是各种发生在环境中的数据库事务操作，如插入（insert）、更新（update）、删除（delete）、提交（commit）和中止（abort）等等。这些逻辑操作将从当前主节点日志文件中的日志条目（log entry）计算出来并且复制到各个副节点中，然后在每个副节点中通过高效的内部重演机制执行这些操作。

为了能让副节点能成功重演replication stream，这些日志条目必须是连续的。它们不能是一些被JE的日志清除器删除掉的条目。

为了保证这一点，JE HA把日志分成两部分：

可移除日志，一般在日志的前端，由过时的数据组成，日志清除器可以将其删除。
不可移除日志，一般在日志的末端，所有在这部分的日志都是新的，日志清除器不可以将其删除。只有这部分日志才能用于构造replication stream。这部分日志会随着新条目的加入而不断增大。一旦不可移除日志在所有副节点上重演，就会转换为可移除日志。

下图描述了一个具有三个节点的replication group：节点1是主节点，节点2在重演日志时落后最多，所以节点2被用于决定可移除和不可移除日志。所有没有被节点2重演过的日志条目都会组成不可移除日志。在这个例子中，节点1的日志文件5和日志文件6，以及节点3的日志文件4和日志文件5组成了不可移除日志。这些文件在节点2进行更多重演之前都不能被回收。

（图二）可移除和不可移除日志

只要副节点能进行处理，主节点将一直异步地向副节点发送数据的日志信息，即使主节点中的事务还在进行或者这些事务还未提交。如果主节点中的某个事务最后被取消（abort），副节点中的同个事务同样会被取消。然而，应用程序的某个线程有可能会为了满足某个特殊事务对持久性的要求，会进行等待直至该特定事务在一个或多个副节点上提交。对于这类事务，副节点将通过向主节点发送确认响应明该事务已在副节点上提交。但这并不意味着主节点中的后续操作会被阻止，因为主节点在等待响应的过程中可以继续进行其他事务性操作。

对于主节点和副节点来说，主节点往replication stream发送写操作信息和副节点从replication stream读取（并且重演）这些操作是异步的。一旦应用程序创建了一个新日志条目，主节点就能将该日志条目写入复制流。副节点一旦从replication stream读取了这个操作信息，就可以重演该操作。并且，如果主节点需要，副节点可以在重演操作之后向主节点发送一个确认操作已经提交的应答信息。

Heartbeat

除了向副节点发送日志信息，主节点还会定期向副节点发送heartbeat。如果没有收到主节点发来的heartbeat，副节点将认为主节点或网络可能出现故障，并且发起一次主节点选举来解决这次潜在的问题。在任意的时间点，副节点在重演replication stream时都有可能滞后于主节点，所以在那一时刻副节点的环境可能会与主节点不一样（尽管在副节点赶上主节点之后，这些环境最终都将一致）。副节点将会利用heartbeat中的信息来判断在重演replication stream的时候它落后于主节点的程度，从而可以让副节点满足读一致性的要求（读一致性的要求决定了什么样的滞后程度是可以接受的）。

应用程序架构

JE HA建立在JE的基础之上，所以共用了JE大部分的API。然而，基于JE HA的应用程序是一个分布式的应用程序，这会带来一些额外的问题，而解决这些问题的最佳时机是在对应用程序的架构进行初始设计的时候。在这一章节中，我们将对JE HA的一些主要特性做一个概述，这些特性会对基于JE HA的应用程序的架构设计有直接的影响。

在应用程序中嵌入数据管理

这一小节将会基于JE来讨论什么是在应用程序中“嵌入”数据管理，并且会将此讨论延伸到JE HA中。

在谈论JE的时候，我们通常用术语“嵌入式（embedded）”来描述应用程序和数据管理能力之间的关系。这些通过JE的类库实现的数据管理能力是被嵌入到应用程序中的。由于JE是被应用程序直接使用和管理的，所以应用程序的用户或者管理员都不需要注意到JE的存在。这种应用程序有可能运行在一个嵌入式设备中，比如一台手持设备，一台桌面机器或者一个数据中心。事实上，JE提供的是存储层的功能，因此它往往是作为存储引擎来为应用程序提供数据管理服务。

对比其他传统的客户端-服务器端（client-server）数据管理架构，嵌入式的数据管理架构有以下一些优点：

数据将以原始的形式进行存储和读取，而不需要在不同的数据模型（比如，关系型（relational）数据模型）之间进行转换。应用程序可以将一些结构体或者复杂的对象直接进行序列化后存储进JE的数据库中。
不需要数据库管理员（DBA）。相反，应用程序将数据库配置和管理直接纳入到它自身的配置和管理中，其结果仅需在应用程序中增加几个新的配置。
数据库能够自动恢复（recovery）。终端用户不会注意到任何单独的数据库恢复过程。相反，应用程序在打开一个数据库的时候，JE只在必要的时候会自动并且透明地进行数据库恢复。类似的，当应用程序关闭时，数据库也会被自动关闭。
性能会优于传统的客户端-服务器端架构，其原因是嵌入式结构将消除进程之间通信的额外消耗。这种进程间的通信通常发生在应用程序和数据管理服务之间。

对于JE HA来说，应用程序通常运行在replication group中的每一个可选节点中，并且都拥有一份JE 环境副本。在基于JE HA的应用程序中嵌入数据管理的方式与基于JE是一样的。运行在主节点中的应用程序可以进行读和写的操作；而运行在副节点中的应用程序则只能进行读操作。

写操作管理

应用程序负责将应用层面上对数据库的所有修改请求（例如，通过JE对数据进行插入、删除和修改操作，以及对数据库的建立、重命名、清空和删除操作等等）提交到主节点上。应用程序有两种方式可以向主节点发送写操作请求：

基于副节点的转发：每一个副节点上的应用程序时刻与主节点保持联系，并且能将所有写操作请求转发到当前主节点。
基于监测节点的路由：应用程序在监测节点中运行一个路由程序，该路由程序可以将写操作请求路由到当前主节点，并且能够将读操作请求路由到所有合适的活跃节点以达到负载平衡。

当你在以上两种方式做出选择时，必须考虑以下几个因素：

与当前存在的负载平衡机制的整合。在某些情况下，例如，一个基于硬件的负载平衡器，并不容易甚至不可能将一个中间级的路由器整合进来。在这种情况下，基于副节点的转发将是最好的选择，因为这种机制不会干扰到当前负载平衡机制。
写操作请求的延迟性。利用基于副节点路由来转发一个写操作请求会带来额外的网络跃点（network hop），因此会增加写操作请求的延迟时间。这种延迟的增加在某些应用程序中并不希望看到，例如这些应用程序要求较低的写延迟和较短的反应时间。
网络利用率。如果写请求的平均有效载荷很高，操作请求的转送机制会与replication stream竞争网络资源，这样反而会影响replication性能。如果应用程序的写请求有效载荷很高，那么基于监测节点的路由会是更好的选择。
操作请求的格式。如果采用基于监测点的路由方式，可能需要对应用程序的操作请求格式设计成能够易于识别其是否为写操作。例如，网络应用可以利用URL的格式协议来让路由器能识别读操作和写操作。当采用基于监测点路由方式时，必须要考虑到设计这些请求格式时的额外需求。
路由器的可用性。对于高可用性，应用程序的设计者必须考虑到使用多路由的情况，这样路由器就不会是导致故障发生的热点。在采用基于监测点路由时，多路由会带来额外的复杂性。

对这两种方式的选择是对简单性和性能之间的权衡考虑。基于监测点的路由方式也许会提供更高的性能，但也会带来额外的复杂性。基于副节点的转发方式实现起来相对简单，但相对来说或许没有那么好的性能。

由于不同应用程序中的操作请求的格式和协议各有不同，JE HA并不提供任何机制用于传送成员节点之间或者路由器和成员节点之间的操作请求。应用程序必须自己提供这样的传送功能。

不过，JE HA提供接口用于判定replication group中的成员节点，并且能跟踪当前主节点的状态。

以下几个章节将描述JE HA所支持的一些功能，这些功能将会帮助用户实现上述的两种方式。

基于副节点的转发

（图三）基于副节点的转发

一个基于JE HA的应用程序通过一个支持replication的环境的句柄（replicated environment handle）来访问其环境副本。这个句柄的API可以为应用程序提供以下功能：

决定节点当前状态。例如，可以查询某个节点当前是主节点或是副节点。
将一个状态变化监-听-器（state change listener）和一个句柄相关联。这样，状态变化监-听-器将会持续收到来自主节点的各种信息。

利用这些API，应用程序可以知道它当前所在的节点是否是主节点。如果不是，那么它可以将它接收到的写请求操作转发到当前的主节点上，过程如图三所示。用于转发写请求操作到恰当的节点的机制实际上是应用程序所提供的，并不会涉及JE。

基于监测节点的路由

（图四）基于监测节点的路由

监测节点并不拥有环境的本地备份。它唯一的作用就是用来跟踪replication group当前的状态。路由程序可以根据这些状态信息来将读写操作路由到replication group适当的节点中去。路由程序是应用程序基础架构中的一部分，一般来说不会包含任何应用程序特有的逻辑，但有一个例外：路由程序有足够的信息可以识别读操作和写操作请求格式。

为了实现这种方式的路由，应用程序将一个监-听-器和监测节点句柄（monitor handle）相关联起来。监-听-器接受三类消息：

组内成员节点组成的变化。组内成员节点的加入和移除都会通知给监-听-器。
组内当前主节点的变化。
组内节点当前状态的变化。也就是，此节点当前是否是活跃节点。

路由程序一旦接收到应用程序的操作请求，就会判断此请求是否是写操作请求。若是，路由程序将利用监测节点来确定哪个节点是主节点，从而将此写操作请求转发到主节点。对于读操作请求，它利用监测节点来确定组内的当前节点组成，选择一个活跃节点来完成读操作请求，从而在此过程中实现负载平衡。

更复杂的路由程序的实现将会根据键值范围（key ranges）的分布以及数据读取的方式，将每个读操作请求转发到某个最有可能在缓存中拥有此被读数据备份的成员节点中。因此可以说，该方式实现了一种读分区（read partition）数据存储模式。

可选节点的热备切换（failover）

在程序运行过程中，主节点的选举过程是透明的。因此，应用程序必须允许由于选举而产生的各种状态变化，这样应用程序才能在状态变化中继续运行。下面几种状态的变化均是由于热备切换所导致的：

如果当前主节点发生故障，那么某个可选节点将会由副节点通过选举转变成主节点。在利用基于监测节点路由机制的应用程序中，这种转变意味着，一个之前只能接收读操作请求的节点，现在开始接受和处理写操作请求。而在利用基于副节点转送机制的应用程序中，新的主节点必须停止转发写操作请求，相反，它必须开始接受来自其他副节点的写操作请求。
当前的主节点可能转变成副节点。这种情况很少发生，一般会涉及到临时网络分割（network partition），这时候主节点不能参与节点选举。因此，剩下的节点会重新选举一个新的主节点。在该情况下，由于某些试图在此副节点（之前是主节点）上进行写操作的事务会失败，并抛出异常，因此变成副节点之后的该主节点必须转发所有它接收到的写操作请求，或者拒绝这些请求。
由于热备切换，一个副节点可能会将自己与发生故障的主节点间的通信切换到一个选举出来的新主节点。通常这种转变对应用程序是透明的。JE HA只需重新与新的主节点建立replication stream。在某些罕见的情形下，JE HA有可能需要进行恢复操作，并撤销某些之前已经提交的事务。在这种情况下，replication环境的句柄便会失效。因此，应用程序必须重新建立环境和数据库的句柄，并且通过访问之前环境句柄重新获得所有被缓存起来的瞬时状态。

JE HA事务配置选项

支持Replication的环境必须是是事务性（transactional）的。支持Replication的事务提供了额外的选项用于对事务进行配置，这些选项对应用程序的性能有直接的影响。对这些配置选项的选择实际上是对持久性、写可用性、副节点读一致性以及性能等各方面的权衡考虑。这一章节将具体描述这些配置选项，并且突出讨论如何进行这种权衡考虑。

持久性选项

JE提供了三种不同程度的持久性，分别对应于已经提交的数据在磁盘上所具有的三种不同的持久状态。

SYNC：已经提交的更新被写到磁盘上。该级别的持久性能够保证在机器发生故障的时候，已经提交的数据不会被丢失。但是这种持久性并不能保证在媒介（比如磁盘）损坏的时候数据没有丢失。
WRITE_NO_SYNC: 已经提交的更新被写进文件系统缓冲区。该级别的持久性仅仅保证在应用程序发生故障时，已提交的数据不会丢失。如果机器不发生故障，这些已经提交的数据将最终写进磁盘。
NO_SYNC: 已提交的更新只写进JE的内部缓冲区。在这一级别的持久性中，已提交的数据在应用程序发生故障的时候会丢失。

JE HA扩展了JE持久性的概念，即允许事务通过向快速的网络提交更新从而持久化数据，而不是提交到相对缓慢的磁盘上。因此，除了允许在主节点和副节点中设置以上提及的各种同步级别之外，JE HA还规定副节点完成事务重演之后向主节点发送一个提交响应。并不是所有事务的提交都会从副节点中返回一个响应。主节点只有在必要的时候才会明确要求副节点产生响应。如果一个副节点已经落后于主节点并且尝试赶上主节点，那么主节点将不会要求该副节点发送响应。

因此，JE HA的持久性有三个方面：

主节点上数据同步的程度。
对副节点返回响应数目的要求，这一要求在与事务相关的响应策略（Acknowledgment Policy，下文会有介绍）中有所规定。
在副节点返回提交响应前，副节点上数据的同步程度。

响应策略（Acknowledgment Policy）配置

响应策略配置提供三种可能的选择：ALL，SIMPLE_MAJORITY以及 NONE。

ALL：该策略要求，在事务被主节点持久化之前，所有可选的副节点都必须向主节点发送响应说明它们已提交了这些事务。这一策略会保证较高的数据可持久性，因为在此事务被持久化之前，每个副节点都拥有一份该事务所做的更新操作的拷贝。该策略也保证副节点上较高的读一致性，这是因为所有副节点都能赶上主节点，并且在副节点处理replication stream的过程中没有滞后性。然而，该策略会降低replication group的写可用性，特别是在replication group的节点数较大的情况下。因为即使仅仅一个节点变成不可用，写事务提交操作都会失败。另外一个缺点是提交的延迟性会被提高，因为提交所需的时间将会由性能最差的副节点决定。
SIMPLE_MAJORITY：该策略要求，简单多数（即过半数）的可选节点必须向主节点发送响应说明它们已经提交了事务。由于在事务被提交之后，该事务所做的数据更新的拷贝存在于过半数的副节点中，并且当其余的副节点赶上replication stream的进度时，这些更新最终会传播到这些节点中，因此该策略保证了中级别到高级别的持久性。如果在主节点上某次事务成功提交之后，主节点发生故障，选举程序将保证这些事务的更新不会被丢失。之所以有这个保证，是因为选举程序要求过办数的可选节点都参与到选举过程中，从而保证了至少一个节点既发送了事务提交响应又参与了选举过程。选举算法更进一步保证拥有最新日志的节点将被选举成为主节点，这样可以在产生事务的主节点发生故障之后保持这些更新。

“SIMPLE_MAJORITY”策略在副节点上的读一致性没有“All”策略那么高，这是因为主节点上事务产生的更新有可能没有被复制到并不发送事务提交响应的副节点上（由于只有过半数的副节点要求发送响应）。因此，对数据一致性的要求比较严格的事务会停滞在所有有滞后的副节点中，直到这些滞后的副节点赶上主节点。在正常情况下，这种滞后会很小，并且处于滞后中的副节点会迅速赶上主节点的事务。

“SIMPLE_MAJORITY”策略具备从中等级别到高等级别的写可用性，这是因为replication group允许节点发生故障，并且只要有过半数的节点保持可用，那么replication group便可以继续完成那些要求过半数持久性的写事务。由于主节点需要等待的节点数较少，所以“SIMPLE_MAJORITY”策略的性能比“all”策略要好，同样，主节点会向所有与它有通信的副节点发出响应请求，但它只需要等待到过半数的副节点做出反应即可。这样意味着提交延迟并不会取决于组内速度最慢的节点。

NONE：在该策略下，事务的持久性不依赖于任何副节点发送提交响应。只要事务满足主节点上的同步策略，就可以认为该事务已经被持久化。由于并不能保证在事务提交的时候所做的更新已经被复制到其他副节点中，因此这种策略会导致较低级别的持久性（相对于不支持replication的JE环境）。如果在主节点上某次事务成功提交之后，主节点发生故障，那么这次事务所做的更新有可能会丢失。同样，该策略导致副节点上的读一致性较低，特别是在主节点负载很重并且没有必需的资源来维持replication stream的时候。因此，副节点有可能会远远落后于主节点。总而言之，这种策略会提供较高的写性能，但也会带来较低的持久性。

下面的表格总结了这三种响应策略的优缺点：

	持久性	写可用性	副节点读一致性	写操作性能
All	高	低	高	低
SIMPLE_MAJORITY	中-高	中-高	中-高	中
NONE	低	高	低	高

副节点读一致性

因为replication stream代表着被序列化的JE数据库日志，所以对replication stream的重演会导致副节点从一个事务的一致性状态转变到另外一个事务的一致性状态。副节点的重演机制保证所有事务性的更新会作为一个原子单元来提交，并且更新的过程会与其他正在进行的写事务隔离开，从而保证这些更新所要求的隔离性（isolation）。如果从单独一个节点的角度来看，副节点的所有行为完全具备事务性，并且满足通常的ACID特性，就如不支持replication的JE环境一样。这一章节将讲述关于副节点与主节点之间一致性的问题。

JE HA支持最终一致性（Eventual Consistency）。这种一致性模型并不能保证在事务在主节点提交的那一刻，所有副节点保持一致。然而，它保证在足够长的一段时间内如果没有新的更新产生，那么所有的更新会在所有的成员节点中传播，并且所有的副节点最终会与主节点共享一个一致的环境视图（environment view）。

由于所有在主节点上的读操作都具有绝对的一致性，所以所有要求绝对一致性的读操作都应该路由到主节点中。应用程序可以利用之前提到过的写转发（write forwarding）技术将这些读操作请求发送到主节点中。然而，对于并不要求绝对一致性的情况，在副节点的读事务开始时，读事务可以指定副节点滞后于主节点最大所能接受的程度。有两种方式可以量化这种滞后程度：

以时间衡量 – 在JE API的TimeConsistencyPolicy中有所描述。
以副节点在replication stream中的位置衡量 – 在JE API的CommitPointConsistencyPolicy中有所描述。

滞后的程度主要取决于主节点和副节点的负载，以及传输replication stream时的通信延迟。还有一种可能的情况是，某个副节点在一段时间内都没有和主节点联系，它需要赶上主节点在这段时间内所做的一些更新。

对一致性策略的选择取决于应用程序所采取的操作的性质。而对所选择策略的配置会直接影响到副节点上的读操作性能。接下来的章节将会详细描述这些策略以及它们的一些配置。

时间一致性策略（Time Consistency Policy）

这种策略描述了当副节点上的读事务开始时，副节点允许滞后于主节点的时间长短。假设t0是当前时刻（t0是时刻变化的），lag是所允许滞后的时间长度，那么所有在（t0 – lag）时刻之前在主节点上被提交的事务都必须在副节点上进行重演。而在这些事务进行重演之前，副节点上的读事务都不允许进行。值得强调的一点是，t0是时刻变化的瞬时间，而不是读事务开始时的固定时间，意味着副节点是在试图赶上一个随时间不断移动的目标。因此，这里的滞后表示的是一个有固定长度的时间窗（长度为lag），这个时间窗是随时间而不断移动的。所以，副节点上的读事务会一直等到副节点对replication stream的重演充分赶上主节点之后才开始，也就是说，直到副节点所重演的事务落在长度为lag的时间窗口之内时，或者来自主节点上的heartbeat表示副节点已经赶上主节点时，副节点上的读事务才可以开始。如果副节点在规定的时间内（这一时间同样由此策略设置）没有赶上主节点，那么读操作事务将会被放弃。

时间一致性策略可以适用于某些网页应用中。在这些应用中，可以使滞后时间小于用户访问一序列的网页时的交互时间。

在给定的负载和可用的硬件资源情况下，如果将滞后时间设置得过短，会导致经常性的超时异常，从而会降低副节点的读操作可用性。过短的滞后时间同样会增加读操作请求的等待时间，因为副节点会让读事务一直等待，直到它能在replication stream中赶上主节点。应用程序的设计者应该需要从应用程序的角度来决定可以接受的最长滞后时间，然后用这个时间来配置时间一致性策略。

提交点一致性策略（Commit Point Consistency Policy）

这个策略以副节点在replication stream上所处的位置来定义滞后时间，这个位置与某个特定的事务的提交点相关。这个策略保证，在副节点上的读操作可以开始之前，replication stream上所有在提交点之前出现的事务，包括处于提交点的事务，都将被副节点重演。这种情况下的滞后表示了一个可扩大的事务更新窗口，窗口的下端固定在提交点，而窗口上端可以随着新事务在主节点上的提交而扩大。JE HA扩展了事务的API，从而使应用程序可以得到与某事务的提交点。

和时间一致性策略一样，如果副节点在该策略规定的时间内没有重演提交点所限定的事务，那么副节点上的读操作事务会被放弃。

提交点一致性策略可以为网页应用提供会话一致性（session consistency）。通过将一个提交点和用户的会话相关联，并且在会话的每一个写操作中更新提交点，这样便可以实现会话的一致性。会话中的读事务可以利用提交点一致性策略来保证所有的读事务都可以读到会话所写入的数据，而无论该读操作是发生在哪个副节点上。

由于需要应用程序在读写操作过程中维护提交点的状态，所以提交点一致性的使用会比时间一致性复杂。时间一致性相对来说比较简单，但是它对时间的依赖意味着，当主节点、副节点或者网络负载过高时，这一策略不一定能正确地实施。

性能

由于JE HA 以JE为基础，因此所有适用于JE的性能调优方法都适用于JE HA。除此之外，还有一些专门针对JE HA的调优。以下章节将进行详细说明。

持久性

持久性配置对应用程序的写操作性能调优来说是最重要的方面之一。在不支持replication的JE环境中持久性的缺省设置是SYNC，这样可以保证已提交的事务在机器发生故障时不会被丢失。虽然SYNC设置通常会导致较大的性能损失，但为了保证数据在事务提交之后可以永久保留在磁盘上，这种设置是必要的。

对基于JE HA的应用程序的调优，把持久性设置成，NO_SYNC和SIMPLE_MAJORITY是一个较好的着手点。这个设置可以允许主节点和副节点异步地向文件系统和磁盘写入数据，也就是在提交之后的某个时间点才写入磁盘，而不是在提交后马上同步写入文件系统和磁盘。此外，当向磁盘存储数据时，JE可以对多个事务产生的更新进行打包，从而形成条数较少的，体积较大的，然而效率会更高的顺序写操作。

把提交响应策略设置成SIMPLE_MAJORITY可以减少主节点等待提交响应所带来的延迟时间，因为这种延迟不受性能最差的副节点所决定。对节点数目较大的replication group来说，延迟时间会随着节点数目的增大而延长。采用SIMPLE_MAJORITY设置可以保证万一当前的主节点发生故障时，数据在其他副节点中是可用的。但是有一种情况例外：即同时有多个程序发生故障从而导致过半数的节点（这些节点将会产生提交响应）在事务提交之后并且在将数据存储到磁盘之前发生宕机。这时候主节点会由于接收不到过半数的节点发来的提交响应而进行无限期等待。

从这种持久性设置开始着手调优，程序设计者可以为程序的整体需求选择最好的持久性等级。值得注意的是，持久性可以在事务级别上进行设置。这样可以允许一个程序的不同部分根据本地的需求使用不同级别的持久性。

读一致性

为了能有效利用副节点上的读操作吞吐量，并且能使主节点上的负载达到最小（因为只有主节点才能进行写操作），所有不要求绝对一致性的读操作请求都应该由应用程序路由到副节点上。并且，为了使延迟达到最小，可以在满足应用程序需求的条件下选择最不严格的一致性策略。

和持久性一样，可以在单独的事务级别上设置一致性。在之前的章节中，已经详细说明了如何选择和设置一致性策略。

Replication stream的代价

JE HA利用TCP协议从主节点向副节点传输replication stream。在一个有N个节点的replication group中，一共有（最后肯定会有）N-1份日志拷贝在网络中传输。因此在设计数据模型时，对键（key）所占空间大小进行优化会对性能有所帮助。特别是对写密集型的应用程序来说，这一点尤其重要。

值得注意的是，正如写操作性能的瓶颈往往是连续写磁盘的吞吐量，网络的吞吐量也正是replication性能的瓶颈。因此，重要的是要确保可利用的网络带宽能够负担预期的写负载。

副节点的滞后

当主节点需要向副节点发送最新的日志条目时，由于最新的日志条目很有可能存储在主节点的缓存中，从而不需要访问磁盘，因此主节点上的缓存能有助于主节点高效地构造replication stream。如果需要访问磁盘来获得旧的日志条目，则会导致与正在进行的所有磁盘写操作（这些写操作会在磁盘存储新的日志条目）发生竞争。这种读/写磁盘的竞争会扰乱顺序写磁盘的模式，而这种模式正是JE能保证较高写操作性能的关键。

因此，最好能保证所有的节点处在运行状态，这样副节点可以和主节点的保持一致，主机点将不用频繁通过访问磁盘来构建replication stream。如果某个副节点发生故障，则应尽快让它恢复运行。

如果某个节点（假设是节点A）发生故障，某些日志文件尽管已经被清除器（cleaner）回收，但是这些日志对节点A来说是其恢复运行后构建replication stream所必需的，那么JE HA将会阻止replication group中其他活动节点删除这些日志文件。JE HA只会在某段时间（这个时间是可设置的）之内阻止对这些日志文件的删除。在这段时间内，日志文件将会在活动节点中不断堆积，导致活动节点存在磁盘空间耗尽的风险。如果节点A在这段时间之后（磁盘空间已经耗尽）重新运行，那么有可能任何一个活动节点中都不存在一个连续的replication stream。因此，这种情况下节点A需要进行网络恢复（Network Restore）操作。网络恢复操作将某个活动节点中的日志文件复制到节点A中，然后在节点A中开始重演主节点发送过来的replication stream。如果数据库环境比较大，网络恢复操作则有可能是磁盘读/写密集型和网络传输密集型操作。

JE HA的可扩展性

JE HA架构支持单节点写和多节点读。下面的章节将分别描述读操作和写操作的扩展。

写扩展性

对于单节点写来说，写操作的可扩展性主要由主节点处理写操作的能力所决定，继而又取决于主节点上可用的硬件资源。通过使用提交到网络这种持久性策略，以及通过降低那些不需要绝对一致性的读操作的负荷，主节点可以降低某些I/O负载。

在当前的实现中，主节点负责维护发送到其他所有成员节点的replication stream。每个replication stream的构建都会在主节点上增加CPU负载。为了改进这个问题，每个replication stream都将由一个专门的feeder线程来维护，这个feeder线程可以利用多核机器的优势来维护并行的replication stream。每个replication stream同样会给主节点所在的子网带来网络传输负载，并且写密集型的应用程序对带宽的需求有可能会超出子网上可用的网络带宽。

写分区（partition）

如果应用程序的需求允许，写操作的水平扩展性可以通过将数据分区到多个支持replication的环境中实现。但是JE HA目前没有提供明确的API来支持这种数据分区。

下图描述了如何利用三个支持replication的环境来对数据进行分区：RE1，RE2和RE3对应着三个replication groups，G1，G2以及G3。数据既可以均匀地分布在三个组中，也可以基于预期的写/更新频率来进行分区。例子中的每个replication group由三个可选节点以及一个监测节点组成。这几个replication groups分布在三台机器中MC1，MC2以及MC3。

这个例子里的路由器包含三个监测节点：G1（M），G2（M）以及G3（M），每个监测节点对应一个replication group。路由器必须根据数据分区规则来将数据操作请求路由到特定的节点中。这些路由方式都取决于要访问的数据本身以及操作的类型（读或写）。

（图五）HA写分区：3个写分区，3个replication groups，每个replication group有3个可选节点。

读扩展性

JE HA中读扩展性可以通过多个只读副节点来实现。JE HA并没有对replication group中节点的数目有所限制。添加一个新的节点并不会增加当前的replication group对资源的需求。但是正如上文所描述一样，添加新节点会增加写节点（即主节点）以及网络的负载。

通过添加新节点来提高读扩展性对于应用程序来说是完全透明的。一个新节点可以被添加进一个正在运行的replication group中，并且一旦这个新节点在本地拥有足够多的日志副本，新节点便可以开始处理读操作请求。

结语

JE HA通过简单、直接地扩展JE的API来提供快捷、可靠以及可扩展的数据管理功能，并且能够嵌入到应用程序当中。JE HA的配置是十分灵活的，允许用户在数据持久性、数据一致性以及性能等方面综合权衡之后，设计出具有广泛适用范围的应用程序。

你可以在以下网址下载Oracle Berkeley DB Java版本：

http://www.oracle.com/technology/software/products/berkeley-db/je/index.html

你可以在Oracle Technology Network（OTN）上提交你对Oracle Berkeley DB Java版本的意见或者问题：

http://forums.oracle.com/forums/forum.jspa?forumID=273

关于销售或者产品支持的信息，请发送Email：berkeleydb-info_us@oracle.com

想了解关于新产品发布信息，请发送Email：bdb-join@oss.oracle.com

OTN论坛翻译：如何在JE中实现分页

chaohuang — Mon, 20 Jun 2011 08:51:37 +0000

这篇文章翻译了一个在JE OTN论坛关于如何实现分页的讨论。由于时间仓促，采用google翻译的内容可能比较晦涩，请谅解。英文原文见 http://forums.oracle.com/forums/thread.jspa?messageID=3197926.

1楼，用户Shoaib的提问：

有一点我注意到的是，在使用DPL我们无法得到ArrayList的代理实现，像Map和sorteMap。假设，如果我想从索引第5000条记录位置获取到下50条记录，我会通过EntityCursor迭代器或key的Map遍历获取未来50个记录。

因此，当我们实现分页并一页一页进行页面遍历，这个过程中要消耗大量的CPU周期。我可以使用EntityCursor跳转到记录号对应位置（而不通过主键）吗？现在我不看任何这样的选项。有没有使用DPL我们可以指定记录号而不是主键进行访问？

如果我这样做（如下），它将吃了整个内存，如果有百万条记录的话。

ArrayList list = new ArrayList（dao.getMyEntityByPK（）.map（）.values（））;

这将把所有实体值载入到内存的ArrayList。

2楼，JE开发者Mark的答复：

嗨Shoaib，

BDB JE目前没有一种方法来通过记录号而不是主键来访问记录，并且我们目前没有计划去增加。

目前最好的办法是保存当前分页上的第一个和最后一个键值。当你需要遍历到下一页或前一页，从记录下的键开始，向前或向后读取。

但是，这并没有提供一种方法来跳转到第5000条记录。 BDB JE没有有效的方式做到这一点。 JE使用B树索引，而只要是使用标准的B树就有没有办法来有效的索引。

我们的BDB C版本产品使用了一个不同的B树索引，支持按记录号访问，但是，使用此功能大大降低并发性。该产品是用C语言实现，但提供一个Java JNI接口。如果你有兴趣，请参阅：

http://www.oracle.com/technology/documentation/berkeley-db/db/java/com/sleepycat/db/DatabaseConfig.html＃setBtreeRecordNumbers （布尔）

如果您有关于C版产品进一步的问题，请使用它的论坛：

http://forums.oracle.com/forums/forum.jspa?forumID=271

3楼，Mark的进一步补充：

我还有一个实现分页的建议。

我知道，在SQL数据库，分页有时通过LIMIT关键字，或在Oracle DB使用ROWNUM实现。见：

http://www.oracle.com/technology/oramag/oracle/06-sep/o56asktom.html

事实证明在这些SQL DB中，通常这一功能LIMIT/ ROWNUM指定了有限的记录数（当查询请求任意一组大型数据集时）。整个查询，只有所要求范围的记录数是从服务器返回。这对于客户机 – 服务器模式的数据库而言是可以的，因为减少了返回客户端的记录数，但对任何一个像BDB嵌入式数据库而言是无价值的。而即使是客户机 – 服务器数据库，执行在一个大型数据集的查询仍然是非常昂贵的。更糟的是，当你每请求另一页的记录时，这个大型查询要执行一次。

我问了一下熟悉Oracle DB的人，关于应用程序中如何最好的实现分页。一种已知可以正常工作的方法是创建一个临时数据库（在SQL术语中是Table，JE中是Database），由行号或页码索引。这个临时DB用于分页非常有效，因为它是由行号索引。如果不再需要时，临时数据库可以被删除。

临时数据库是对一个要进行分页的数据集的copy。当然，创建和初始化临时数据库是有代价的。但如果你将在许多查询或者场合使用它，初始的代价是值得的。另外，要知道，临时数据库是一个对你想分页数据集的快照，所以它不会包含（在临时DB）构造完后所做的更改。

要创建一个BDB JE的临时数据库，我们建议使用Deferred Write数据库以获得最佳性能。要创建一个Deferred Write数据库，在当打开数据库时调用DatabaseConfig.setDeferredWrite（true）。使用Deferred Write数据库会将所有信息都保存在内存中，直到缓存被填满。当缓存溢出时数据才写入到磁盘。你不应该显示调用Database.sync，因为数据是暂时的。当您完成使用临时数据库，将其关闭并删除它（使用Environment.removeDatabase）。

创建完临时数据库，将要分页的信息复制到临时数据库。当你复制时，你可以通过简单地指定一个整数计数器递增的行号。有几种方法你可以考虑存储在临时数据库的信息。

1）使用行号作为Key，要显示的行信息作为Data。

2）使用行号作为Key，将要显示信息对应的数据库主键作为Data。

3）使用页码作为Key，并将该子页的行信息列表作为Data。

4）使用页码作为Key，并将该子页的行信息对应的数据主键的列表作为Data。

对于（1）和（2），行号是临时数据库的Key。您可以轻松地检索从行号5000开始的记录，例如。利用行号做Key的好处是，你可以随时更改页面大小（page size）而不用更改临时数据库。

对于（3）和（4），页码是临时数据库的Key。它的优点是，你可以读取一个记录，以获得所需显示页面的信息（或一个页面信息的主键）。但是你不能改变page size而无需重新创建临时数据库。

对于（1）及（3），所有你需要显示的信息存储在临时数据库中。需要显示信息时，你无需做别的查询。但临时DB的大小会变得很大（对比于存储的是主键），所以临时数据库信息更容易填满缓存并写入磁盘。

用（2）及（4），要显示信息的主键存储在临时数据库中。缺点是，你必须通过主键再查询来获得相应的显示信息。而存在其他数据库中的数据可能已被更改或删除，您必须考虑到这一点。它的优点是临时DB要小得多，因为只存储了Key，而不是Data本身。

为简单起见，我建议首先尝试方法（1）或（3），这取决于页大小是固定的还是没有。如果您发现临时DB过大，并导致性能问题，然后尝试方法（2）或（4）。

我希望这会有所帮助。

bdb开通新浪微博

chaohuang — Mon, 30 May 2011 10:41:58 +0000

各位BDB中文博客的粉丝们，为了更好的和大家交互并分享BDB的消息，我们刚刚开通的新浪微博。微博地址为：

http://www.weibo.com/bdbchina

欢迎各位朋友添加关注并和我们分享信息。感谢大家的一直以来的支持。

备注：由于工作比较忙（很少看博客评论），我们推荐大家使用新浪微博和我们互动，从而可以得到更及时、有效的反馈。

Oracle Berkeley DB 中国开发团队

Using Oracle Berkeley DB as a NoSQL Data Store

chaohuang — Thu, 24 Feb 2011 03:37:59 +0000

Using Oracle Berkeley DB as a NoSQL Data Store

By Shashank Tiwari

Learn why and how Oracle Berkeley DB can bring NoSQL benefits to your app.

Published February 2011

“NoSQL” is the new popular buzzword among developers, architects and even technology managers. However, despite the term’s newfound popularity, surprisingly there is no universally agreed-upon definition for it.

Generally, any database that isn’t RDBMS, upholds schema-less structures, is generally relaxed on ACID transactions, and promises high availability and support for large data sets in horizontally scaled environments is popularly categorized as a “NoSQL data store”. Given that these common features often seem in direct contrast to those of a good old RDBMS, some people propose non-relational, perhaps shortened as NonRel, as a more appropriate term than NoSQL.

Regardless, while the definitional conflict continues, many have begun to realize the benefits of NoSQL data stores by including them in their application stack. The rest are keeping a close watch and evaluating if NoSQL is right for them.

The growth of NoSQL as a category has also led to the emergence of a number of new data stores. Some of these new NoSQL products are good at persisting JSON-like documents, some are sorted ordered column-family stores, and others persist distributed key-value pairs. While newer products are exciting and offer many nice features, a few existing ones rise up to deliver the new promise as well.

One such data store is Oracle Berkeley DB. In this article I will illustrate and explain why and how Berkeley DB can be included in the stack as a NoSQL solution. The article focuses exclusively on Berkeley DB’s NoSQL-centric features and thus does not exhaustively cover all of Berkeley DB’s capabilities and idiosyncrasies.

Berkeley DB Essentials

Fundamentally a key-value store, Berkeley DB comes in three distinct flavors:

Berkeley DB – key-value store programmed in C. (Berkeley DB official documentation uses the term key-data in place of key-value.) This is the “classic” flavor.
Berkeley DB Java Edition (JE) – key-value store re-written in Java. Can easily be incorporated into a Java stack.
Berkeley DB XML – Written in C++, this version wraps the key-value store to behave as an indexed and optimized XML storage system.

(Note: Although this article does not expressly cover Berkeley DB JE or Berkeley DB XML, it does include examples that use the Java API and the Java-based persistence frameworks to illustrate the capabilities of Berkeley DB.)

Simple as it may be at its core, Berkeley DB can be configured to provide concurrent non-blocking access or support transactions, scaled out as a highly available cluster of master-slave replicas, or in a number of other ways.

Berkeley DB is a pure storage engine that makes no assumptions about an implied schema or structure to the key-value pairs. Therefore, Berkeley DB easily allows for higher level API, query, and modeling abstractions on top of the underlying key-value store. This facilitates fast and efficient storage of application specific data, without the overhead of translating it into an abstracted data format. The flexibility offered by this simple, yet elegant design, makes it possible to store both structured and semi-structured data in Berkeley DB.

Berkeley DB can run as an in-memory store to hold small amounts of data or it can be configured as a large data store, with a fast in-memory cache. Multiple databases can be set up in a single physical install with the help of a higher-level abstraction, called environment. One environment can have multiple databases. You need to open an environment and then a database to write data to it or read data from it. It’s advised that you close a database and the environment when you have completed your interactions to optimally use resources.

Each item in a database is a key-value pair. The key is typically unique but you could have duplicates. A Value is accessed using a key. A retrieved value can be updated and saved back to the database. Multiple values are accessed and iterated over using a cursor. Cursors allow you to loop through the collection of values and manipulate them one at a time. Transactions and concurrent access are additionally supported.

The key of a key-value pair almost always serves as the primary key, which is indexed. Other properties within the value could serve as secondary indexes. Secondary indexes are maintained separately in a secondary database. The main database, which has the key-value pairs, is therefore also sometimes referred to as the primary database.

Berkeley DB runs as an in-process data store, so you statically or dynamically link to it when accessing it using the C, C++, C#, Java or scripting language APIs from a corresponding program.

With that whirlwind introduction, the following section describes Berkeley DB in the context of its NoSQL-centric features.

Fluid Schema

The first benefit of a NoSQL store is its relaxed attitude toward well-defined database schemas. Let us see how Berkeley DB fares on this feature.

To appreciate Berkeley DB’s capabilities, I suggest you take it for a spin. Therefore, it is recommended that you download and install both Berkeley DB and Berkeley DB JE on your machine so you can try some examples yourself and follow along with the rest of the illustrations in this article. Download links and installation instructions are available online here. (I compiled Berkeley DB with –enable-java, –enable-sql, and –prefix=/usr/local for this article.) The fundamental concepts that relate to storage, access mechanisms and the API don’t vary much between Berkeley DB and Berkeley DB JE so most things I cover next apply equally well to both.

Berkeley DB itself imposes little restrictions on the data items beyond it being a collection of key-value pairs. This allows applications to flexibly use Berkeley DB to manage data in a variety of formats, including SQL, XML and Java objects. You can access data in Berkeley DB via the base API, the SQL API, the Java Collections API, and the Java Direct Persistence Layer (DPL). It allows a few different storage configurations: B-Tree, Hash, Queue, and Recno. (The Berkeley DB documentation refers to the different storage mechanisms as “access methods”. Hash, Queue, and Recno access methods are available only in Berkeley DB and not in Berkeley DB JE or Berkeley DB XML.)

Depending on your specific use case, you could choose an access mechanism and a storage configuration. This choice of a particular access method and a storage configuration can affect schema. To understand the impact of the choices, you need to first understand what they are. I cover the access methods and storage configurations next.

Using the Base API

The Base API is a low-level API that allows you to store, retrieve and update data, the key-value pairs. This API is similar across different language bindings. Therefore the Base API for C, C++ and Java are quite the same. DPL and the Java Collections API, on the other hand, are only offered as an abstraction in the Java API.

The Base API puts, gets and deletes key-value pairs. Both the key and the value are an array of bytes. All key and data values get serialized to byte arrays before they are stored. One could use Java’s built-in serializer or Berkeley DB’s BIND API to serialize various data types to byte arrays. Java’s built-in serializer is typically a slow performer so one must go in favor of the BIND API. (The jvm-serializers project benchmarks various alternative serializers and is a good reference point to analyze relative performance among different serialization mechanisms in the JVM.) The BIND API avoids redundantly storing the class information with every serialized class and instead puts that information in a separate database. Potentially, you could makes things faster by writing your own custom tuple binding to improve the BIND API performance.

As an elementary example, you can have a data value defined as follows:

import java.io.Serializable;
public class DataValue implements Serializable {
    private long prop1;
    private double prop2;

    DataValue() {
      prop1 = 0;
      prop2 = 0.0;
    }

    public void setProp1(long data) {
      prop1 = data;
    }

    public long getProp1() {
      return prop1;
    }

    public void setProp2(double data) {
      prop2 = data;
    }

    public double getProp2() {
      return prop2;
    }
}

Now, you can store this data value using two databases, one to store the value with a key and another to store the class information.

The data is stored using four distinct steps:

First a second database, apart from the one to store key-value pairs, is configured to store class data as follows:
```
Database aClassDB = new Database("classDB", null, aDbConfig);
```

Then a class catalog is instantiated as follows:

StoredClassCatalog storedClassCatalog = new StoredClassCatalog(aClassDb);

A serial entry binding is established like so:

EntryBinding binding = new SerialBinding(storedClassCatalog, DataValue.class);

Finally, a DataValue instance like so:

DataValue val = new DataValue();
val.setProp1(123456789L);
val.setProp2(1234.56789);

is mapped to a Berkeley DB DatabaseEntry, which serves as a wrapper for both the key and value, using the binding you just created as follows:

DatabaseEntry deKey = new DatabaseEntry(aKey.getBytes("UTF-8"));
DatabaseEntry deVal = new DatabaseEntry();
binding.objectToEntry(val, deVal);

Now you are ready to put the key-value pair in Berkeley DB.

The base API supports a few variants of the put and get methods, to allow or dis-allow duplicates and overwrites. (The intent of neither this example nor the article is to teach you the detailed syntax or semantics of using the base API so I will not get into further details; see the doc here.) An important takeaway is that the base API allows for low-level manipulation and custom serialization around storing, retrieving and deleting key-value pairs.

If you prefer to interact with Berkeley DB with a higher level API, then you should use DPL.

Using DPL

Direct Persistence Layer (DPL) provides familiar Java persistence framework semantics for manipulating objects. You can treat Berkeley DB as an entity store where objects are persisted, retrieved to be updated and deleted. DPL uses annotations to mark a class as an @Entity. Associated classes, which get stored with an Entity, are annotated as @Persistent. Specific properties or variables can be annotated as @PrimaryKey and @SecondaryKey. A simple Entity could be as follows:

@Entity
public class AnEntity {

    @PrimaryKey
    private int myPrimaryKey;

    @SecondaryKey(relate=ONE_TO_ONE)
    private String mySecondaryKey;
    ...
}

DPL imposes the class definition as a well-defined schema. From the base API we know that such a conformance to schema is not a requirement for Berkeley DB. For some use cases, however, formal entity definitions are helpful and provide a structured approach to data modeling.

Storage Configuration

As mentioned previously, key-value pairs can be stored in four different types of data structures: B-Tree, Hash, Queue and Recno. Let’s see how they stack up.

B-Tree. A B-tree needs little introduction but if you do need to review its definition then read the Wikipedia page on B-Tree, available online at http://en.wikipedia.org/wiki/B-tree. It’s a balanced tree data structure that keeps its elements sorted and allows for fast sequential access, insertions and deletions. Key and values can be arbitrary data types. In Berkeley DB the B-tree access method allows duplicates. This is a good choice if you need complex data types as keys. It’s also a great choice if data access patterns lead to access of contiguous or neighboring records. B-Tree keeps a substantial amount of metadata to perform efficiently. Most Berkeley DB applications use the B-Tree storage configuration.
Hash. Like the B-Tree a hash also allows complex types to be keys. Hashes have a more linear structure as compared to a B-Tree. Berkeley DB hash structures allow duplicates.While both a B-Tree and a hash support complex keys, a hash database usually outperforms a B-Tree when the data set far exceeds the amount of available memory. That is because a B-Tree keeps more metadata than a hash and a larger data set implies that the B-Tree metadata may not fit in the in-memory cache. In such an extreme situation the B-Tree metadata as well as the actual data record itself will often have to be fetched from files, which can cause multiple I/Os per operation. The hash access method is designed to minimize the I/Os required to access the data record and therefore in these extreme cases, may perform better than a B-Tree.
Queue. A queue is a set of sequentially stores fixed length records. Keys are restricted to logical record numbers, which are integer types. Records are appended sequentially allowing for extremely fast writes. If you are impressed by Apache Cassandra’s fast writes by appending to logs then give Berkeley DB with queue access method a try and you wouldn’t be disappointed. Methods also allow reading and updating effectively from the head of the queue. A queue has additional support for row-level locking. This allows effective transactional integrity even in cases of concurrent processing.
Recno. Recno is similar to a queue but allows variable length records. And like a queue, recno keys are restricted to integers.

The different configurations allow you to store arbitrary types of data in a collection. Similar to NoSQL, there is no fixed schema, other than those imposed by your model. In the extreme situation, you are welcome to store disparate value types for two keys in a collection. Value types can be complex classes, which for the sake of argument could represent a JSON document, a complex data structure or a structured data set. The only restriction really is that the value should be serializable to a byte array. A single key or a single value can be as large as 4GB.

The possibility of secondary indexes allows filtering on the basis of value properties. The primary database does not store data in a tabular format and so non-existing properties are not stored for sparse data sets. A secondary index skips all key-value pairs that lack the property on which the index is created. In general the storage is compact and efficient.

Support for Transactions

Berkeley DB is a very flexible database that can turn many features on and off. Berkeley DB can run without transaction support or it could be compiled to support ACID transactional integrity. Perhaps, the malleable nature of Berkeley DB makes it a very appropriate data store for many situations. Transactional integrity is the least supported feature in a quintessential NoSQL data store. Berkeley DB, in highly available systems, that don’t expect ACID transactional compliance can turn transactions off and work like a typical NoSQL product. However, in others it could be flexible and support transactional integrity.

While I don’t intend to cover details on transactions, it’s worth noting that like traditional RDBMS systems, Berkeley DB enabled with transactions allows definition of transactional boundaries. Once committed, data is persisted to disk. To enhance performance, one can use non-durable commits, where writes are committed to in-memory log files and later synched with the underlying file systems. Isolation levels and locking mechanisms are also supported.

Before a database is closed a sync operation assures that persistent file copies have up-to-date in-memory information in the system. The combination of this sync operation and Berkeley DB’s transactional recovery subsystem (assuming that you have enabled transactions) ensure that the database is always returned to a consistent transactional state, even in the event of application or system failure.

Large Data Sets

Theoretically Berkeley DB has an upper bound of 256TB but in real life it’s usually bound by the size of the machine it runs on. At the time of this writing, Berkeley DB does not demonstrate support for extremely large files that span multiple machines with the help of distributed file systems. (Files larger than the size of a single node can be managed with the help of distributed file systems like the Hadoop Distributed File System, or HDFS.) Berkeley DB works better on local file systems than it does on network file systems. More accurately, Berkeley DB relies on the POSIX compliant attributes of a file system. For example, when Berkeley DB calls fsync() and the file system returns, Berkeley DB assumes that the data has been written to persistent media. For performance reasons, distributed file systems typically do not guarantee that a write has been completed all the way to the persistent media.

The maximum B-Tree depth supported is 255. Lengths of the key and value records are typically bound by the available memory.

Horizontal Scale-out

Berkeley DB replication follows a master-slave pattern. In such a pattern there is one master and multiple slaves or replicas. However, the selection of a master is not static and it’s recommended that the selection is not manual. All participants in a replication cluster go through an election process to choose the master. The one with the most up-to-date log records is the winner. If there is a tie, then priorities are used to select the master. The election process is based on an industry standard Paxos-compliant algorithm.

Replication has numerous benefits including the following:

Improves read performance – The availability of multiple replicated nodes to read data from improves the read performance drastically.
Improves reliability – The presence of replicated instances provides better failover options in times of node failure and data corruption.
Improves durability – You can relax durability guarantees on the master to avoid excessive write to disk operations, which typically involves expensive I/O. In a clustered environment the durability is enhanced by the fact that the write has been committed to multiple nodes, even if it’s not written to disk.
Improves availability – The presence of multiple nodes, along with asynchronous write to disk, makes it possible for replicas to keep serving operations even when the master is under heavy load.

Summary

Berkeley DB undoubtedly qualifies as a robust and scalable NoSQL key-value store; the use of Berkeley DB as the underlying storage for Amazon’s Dynamo, Project Voldemort, MemcacheDB, and GenieDB is further evidence supporting this claim. There has been a little bit of FUD around Berkeley DB performance, especially in the wake of couple of comparative benchmarks published online:

However, there are many live systems that prove Berkeley DB’s strengths. Many of these systems, through careful tuning and application coding improvements, have achieved excellent scalability, throughput, and reliability results. Following the lead of those systems, Berkeley DB can certainly be used as a scalable NoSQL solution.

Shashank Tiwari is Founder & CEO of Treasury of Ideas, a technology driven innovation and value optimization company. As an experienced software developer and architect, he is adept in a multitude of technologies. He is an internationally recognized speaker, author and mentor. As an expert group member on a number of JCP (Java Community Process) specifications he has been actively participating in shaping the future of Java. He is also an common voice in the NoSQL and Cloud Computing space and a recognized expert in the RIA community.

BDB JE事务的提交方式概述

taozhang — Fri, 24 Dec 2010 05:33:29 +0000

这段时间看到有些用户对BDB JE的事务持久性（Durability)，主要是JE各种事务提交方式比较感兴趣。以下这篇博客介绍了事务的持久性，并简要描述了JE事务所提供的提交方式。

大家知道，事务具有ACID特性，即：原子性，一致性，隔离性和持久性。事务的持久性意味着当系统或介质发生故障时，确保已提交事务的更新不能丢失，即一旦一个事务提交，数据库保证它对数据库中数据的改变是永久性的，能够承受任何系统故障，持久性通过数据库备份和恢复来保证。

事务的持久性与事务的提交方式有着密切联系，当JE的用户创建一个事务时，用户通过设置TransactionConfig来指定事务的提交方式，分别是：

TransactionConfig.setNoSync(boolean)，即txnNoSync
TransactionConfig.setWriteNoSync(boolean)，即txnWriteNoSync
TransactionConfig.setSync(boolean)，即txnSync。

您可以参看下图了解这几种提交方式的区别：

当选择txnNoSync方式时，在事务提交之前，JE会将数据写入JE自己的缓冲区，操作系统会选择适当的时机（缓冲区满，后续事务选择txnSync 提交方式或数据库做了一次checkpoint）将数据写到磁盘上，一旦应用程序或是JVM崩溃了，用户的数据就会丢失。

当选择txnWriteNoSync方式时，在事务提交之前，JE会将数据写入文件系统的缓冲区，操作系统会选择适当的时机（缓冲区满，后续事务选择 txnSync提交方式或数据库做了一次checkpoint）将数据写到磁盘上，这种方式可以避免因为应用程序或JVM崩溃而带来的数据丢失，但是无法避免操作系统崩溃带来的数据丢失，因此也无法保障数据的持久性。

当选择txnSync方式时，在事务提交之前，它会强制调用操作系统的fsync方法将数据写到磁盘上，这样一旦事务提交成功，即使操作系统崩溃也能保证数据的持久性，但是该方式不能保证介质故障的数据持久性，在这种情况下，需要采用数据库备份的方式来提供持久性。

这三种事务提交模式给性能带来的影响如下：

txnNoSync，节省了JE与操作系统的交互和磁盘I/O，性能相对其它两种更好
txnWriteNoSync，节省了磁盘I/O，性能次之
txnSync，性能相对其它两种方式要差一些

因此，用户需要根据他们的需要来选择不同事务提交方式。

BDB JE 发布4.1新版本 — 3倍cache性能提升

chaohuang — Fri, 05 Nov 2010 04:43:55 +0000

BDB Java Edition 4.1 delivers up to a 3X performance improvement over JE 4.0 in some read-only scenarios where the working set doesn’t fit in the cache. The new release includes multi-threaded cache management and advanced in-memory Internal Node compression.

With Concurrent Eviction, cache management is now multi-threaded, resulting in reduced latency and a smoother performance curve as the application data exceeds the cache space. Internal Node (IN) Compression significantly reduces the in-memory footprint of internal data structures, creating better efficiency.

Tests run by a BDB JE user comparing JE 4.0.103 to JE 4.1 using a read-only workload demonstrate extraordinary improvements. The two versions have equivalent performance when the database fits completely in cache (4 GB of memory), but when the cache size is dropped to .5 GB (only some of the Internal Nodes fit in memory) the throughput and latency of JE 4.1 is 300% better than 4.0.103. Further, the variation in latency is greatly reduced.

Software Downloads

* Downloads for software and the latest documentation will be available on OTN.
* Downloads available today at http://download.oracle.com/berkeley-db/je-4.1.6.tar.gz (.zip).

Oracle Berkeley DB 产品家族介绍

haomianwang — Wed, 08 Sep 2010 05:45:49 +0000

Oracle Berkeley DB最先由加州大学伯克利分校为了移除受到AT&T限制的dbm代码，而从BSD 4.3到4.4时所改写的。经过将近二十年的衍化，目前Oracle Berkeley DB家族已经发展到包含4个独立产品线 – Berkeley DB、Berkeley DB Java 版、Berkeley DB XML和Mobile Server，被应用到行行业业，在全球有超过2亿的部署。

本文将分别介绍Oracle Berkeley DB四大产品线的特点以及应用，希望能对中国市场的新老用户有所启发和帮助。

1. Oracle Berkeley DB数据库产品系列

（图一）

Oracle Berkeley DB 产品家族目前有三大数据库产品，分别是：Berkeley DB，Berkeley DB XML 和 Berkeley DB Java Edition。它们的关系和系统架构可以参照图一。下面我将分别进行介绍。

1.1 Berkeley DB

Berkeley DB 也称 Core（下文都以此简称），是Berkeley DB家族第一个发布的产品。Core的核心代码全部由C语言写成，同时提供其他多种语言的应用程序接口（包括 C++, C#, Java, Perl, Python, PHP, Tcl, Ruby等等）。Core有以下一些特点（请大家注意，下面列举的大部分特点其实是Berkeley DB家族所有产品的共同特点）：

基于Key/Value的存储：对于Core以及Berkeley DB其他产品来说，用户可以任意定义所存储数据的键（key）以及对应的值（value），这样的数据存储方式具有很好的灵活性和多样性。也是由于这个特点，Berkeley DB产品家族被业界归为非关系型（non-relational）数据库。
嵌入式数据管理：这里的嵌入式跟大家平时提到的嵌入式有点不一样。这里的嵌入式的意思是指，Core是作为库（library）的形式直接嵌入到用户的应用程序当中，和用户程序运行到同一地址空间，用户选择适当的API进行编程调用。这样“嵌入式”的最大好处就是不需要人为进行管理（即不需要专门的DBA），并可以大大提高程序开发的周期，和降低程序后期的维护成本。
体积(footprint)小：由于Core是直接嵌入应用程序当中，所以产品的体积必须越小越好。目前，Core的体积只有1M左右，这意味着，即使对于移动设备（如手机）来说，Core也可以十分轻松嵌入到你的程序中。
几乎具备数据库的所有功能和特性：对于这么小体积的数据库，你也许会问，Core会不会丧失很多数据库的特性呢。恰恰相反，在保持小体积的优势下，Berkeley DB几乎具备数据库的所有特性，包括：ACID，事务性（transaction），错误恢复（failure recover），高并发性（high concurrency）等等。
高可用性（high availability，简称HA)：高可用性一方面可以提高数据读取性能，另一方面是具备自动错误恢复（automatic failover）功能，使数据存储更加安全可靠。
高性能：Core拥有极高的数据存取性能，并且用户可以根据机器的配置进行调优。具体性能测试可以参考文档 Oracle Berkeley DB:Performance Metrics and Benchmarks。

尤其需要指出的是：最新版本的Oracle Berkeley DB（11gR2）的一个引人瞩目的特性就是我们引入了对SQL 92标准的支持（见图一红色圆圈部分）。Oracle Berkeley DB SQL接口完全兼容SQLite原有的编程接口，从而以往运行在SQLite上的程序和应用都可以无缝的、方便的迁移到Oracle Berkeley DB这个更加强大的存储引擎。并且，Oracle Berkeley DB和SQLite还将进行长期的官方层面的合作，保证了Oracle Berkeley DB的SQL接口和SQLite保持一致，免除了用户的后顾之忧。此外，Berkeley DB SQL接口完美支持很多第三方的SQLite工具，如JDBC，ODBC，FireFox 3及其SQLite Manager 插件等。更多有关DBSQL的技术细节，可以参考本站另外一篇博客《Oracle Berkeley DB 支持SQL啦》。

也许有人会问：何时该选用BDB的Key/Value的选项，何时该选用BDB的SQL接口呢？

简单的来理解，BDB的Key/Value的选项是一个本地持久化的“HashTable”，可以存取任何数据类型（声音、视频、图像、Java对象等），通过简单的put/get/delete接口来操作。简单的数据访问方式、不需要太多复杂的统计和分析计算的场合都可以使用。比如，微博客的底层数据管理；如果再和hadoop集成后，还可以做一些复杂的分析功能。

当使用场合需要轻量级的数据库、有SQL支持、要求高性能和高并发；或者需要和企业端的Oracle 数据库（如Oracle 11g）进行双向的数据同步时，建议可选用Oracle Berkeley DB的SQL接口。举例来说，手持设备/平台上（如Android，Windows Mobile、iPhone等）。

更多关于Core的信息，可以参考下面相关链接：

Core下载
Core相关文档
Core FAQ （可以在此找到常见问题答案）
Core官方论坛（在此论坛提出技术问题，会得到Berkeley DB组资深工程师的回答，当然，提问必须是英文。）
Core HA官方论坛

1.2 Berkeley DB XML

Berkeley DB XML是基于Core数据存取之上，专门用于存取XML文档的数据库（如图一所示），简而言之，Berkeley DB XML以Core作为存储引擎，在此基础上建立对XML文档进行管理、索引和查询优化模块，并提供相应的XML 标准的API。因为Berkeley DB XML建立在Core之上，所以除了具备Core的大部分特点之外，还有以下针对XML文档的一些特点：

支持XQuery 1.0 and XPath 2.0。
十分灵活的索引功能：Berkeley DB XML支持节点（node），element（元素），attribute（属性）和元数据（meta-data）索引。这样灵活的索引可以极大提高查找性能，特别是针对存取较大的XML文件。
支持对XML文档的修改

更多关于Berkeley DB XML的信息，可以参考下面相关链接：

1.3 Berkeley DB Java Edition

Berkeley DB Java Edition（以下简称JE）是Berkeley DB产品家族另外一个独立的产品，也就是说，它并不像BDB XML一样基于BDB Core。JE 除了具备上述 Core 的特点（K/V存储、体积小、性能高以及高可用性（HA）等等）之外，还有以下特色：

纯java，简单易用：JE 是纯java语言编写的，意味着JE可以无缝运行于任何java环境。用户只需要在应用程序中包含JE的jar文件，便可调用JE的API进行编程，无需任何额外配置工作。
更高的并发性，更高的性能：相对于Core，由于JE提供基于“记录”级别（record level，一条记录由Key和Value组成）的锁，所以JE拥有更高的并发性以及更高的读写性能。关于JE的性能测试，可以参考文档：
- Oracle Berkeley DB Java Edition vs. Apache Derby: A Performance Comparison
- Oracle Berkeley DB Java Edition High Availability -Large Configuration and Scalability Testing
Java对象存储：JE 利用直接持久层（Direct Persistence Layer，DPL) 可以十分方便、灵活、快速存取用户定义的任意java对象。可参考文档Direct Persistence Layer for Berkeley DB Java Edition。
适用于J2EE：JE 提供对Java Transaction API (JTA), J2EE Connector Architecture (JCA) 和 Java Management Extensions (JMX)的支持。

更多关于JE的信息，可以参考下面相关链接：

1.4 应用举例

概括而言，你需要一个数据存取的产品，并要满足：

性能要求高，相应时间短、占用资源少的场合
方便管理，不需要DBA
数据访问方式是简单的，任何类型的数据
运行于普通硬件平台，随着业务增长可以水平扩展
高可用集群和容错备份

可能的应用场景包括：

搜索及内容管理
缓存及日志模块
SOA及Web Service的相关模块
资源、系统或者仪器管理
存储设备
网关、网络设备、网络计费系统等
消息队列、工作流等系统
授权及身份管理
仪器、终端和手持设备

举例而言：

某全球知名电子商务公司，选择Core作为中间层的静态数据缓存。当用户浏览产品页面的时候，所有的产品信息、价格、用户评价等等数据都是先从Core进行读取。这样可以大大提高页面的显示时间，从而增进用户购物体验。同时还利用Core来管理购物车和交易结算等。
某全球著名互联网公司，利用Core HA存取数亿用户的账户信息。Core HA的高性能、高并发性和高可用性满足了此互联网公司对用户登录功能的苛刻要求，包括极短的登录请求响应时间，24×7的无间断服务，高达十亿级别的扩展性，以及极高的可靠性。
比如某知名手机公司推出的智能手机选择Berkeley DB SQL作为其底层数据库。某知名POS机厂商也选择 Berkeley DB SQL接口作为新推出的某款POS机的存储引擎。
某全球连锁酒店选择Berkeley DB XML来实现在线预定和销售系统。
某大型跨国企业选择Berkeley DB XML里进行资产和仪器管理。
很多全球型的金融公司的交易系统和底层基础架构的数据存取模块中选择Berkeley DB及Berkeley DB JE。
军方的战场实施动态监控系统选择Berkeley DB JE。
若干全球知名的社交网站中选择Berkeley DB JE构建上千个节点的云计算方案。
某全球知名的网络服务商的视频点播、短信/邮件、视频电话等系统中。

2. Oracle Berkeley DB 11gR2 + Mobile Server

（图二）

Oracle Berkeley DB 11gR2 + Mobile Server 可以提供移动数据同步解决方案。Oracle Mobile Sync Server（以下简称为Mobile Server）是一个提供企业级移动解决方案的中间层（middle-tier infrastructure）。它的一端连接的是客户端数据库，另外一端连接的是Oracle数据库。Mobile Server主要提供以下功能：

应用程序统一部署和配置。比如，应用Mobile Server方案的移动设备都可以自动实现软件的安装、更新和打补丁等等配置，这一过程不需要用户的过多参与。
移动设备统一管理。管理员可以远程收集众多移动设备的信息，同时也可以进行统一的操作与部署。比如，管理员可以远程向丢失的移动设备进行额外加密或者销毁设备中的数据。
移动设备与Oracle数据库的数据双向同步。与Oracle数据库的同步功能可以保持移动设备的完整性和及时性，并且不要求移动设备时刻与Oracle数据库保持连接。

在Oracle Berkeley DB 11gR2之前，Mobile Server支持的客户端数据库是Oracle Database Lite Client。往后Oracle Berkeley DB 11gR2 会是Mobile Server客户端数据库的推荐选择，而原来的Oracle Database Lite Client将停止新功能开发。因为Berkeley DB 11gR2安装更加简单，性能更加优越，并且体积更小。Berkeley DB 11gR2 + Mobile Server的总体架构图如图二所示。

Oracle Mobile Server 的应用举例：

某国的海岸卫队的舰船上的数据同步和设备管理。
某大型的博彩机构的手机订单系统。
某国海关的缉私等设备上。
某大型快速消费品公司的自动售货机上。

更多关于Oracle Mobile Sync Server的信息，可以参考下面相关链接：

- 性能要求高，资源少的场合（如任务密集型的应用，像工作流、规则引擎、队
列、SOA事件管理和监控、网站缓存等）
- 方便管理，不需要dba （如仪器、设备，像手机，汽车、医疗设备等）
- 数据管理/访问方式是简单的，面向对象的（如Twitter， facebook等，只需要
简单、高效的插入和删除操作；不需要很多复杂的分析和统计功能）
- 运行于普通硬件平台，随着业务增长可以水平扩展的 (如云计算、金融系统等）

使用Oracle Berkeley DB实现空间数据库

chaohuang — Fri, 09 Jul 2010 02:10:18 +0000

关于使用Oracle Berkeley DB作为空间数据库的引擎，可以参考如下资料：

* 使用基于Key/Value 接口的场合，可以考虑Berkeley DB C版本或者Berkeley DB Java 版的产品。可以参考美国University of Virginia的叫做PRIDE的学术论文：http://www.cs.virginia.edu/~stankovic/psfiles/pride.pdf

* 使用Oracle Berkeley DB SQL产品中的R*Tree功能，具体可以参考：http://www.bdbchina.com/2010/04/bdb11gr2的r-tree功能/

更多反馈，欢迎留言。

BDB-JE HA性能白皮书

chaohuang — Fri, 09 Jul 2010 01:43:07 +0000

自从BDB-JE 4.0推出了高可用/集群的新特性，我们的工程师进一步做了关于在大型服务器上运行BDB-JE HA的性能测试。具体测试案例及结果数据可参考：http://www.oracle.com/technology/products/berkeley-db/pdf/BDB-JE-HighAvailability-WhitePaper-June2010.pdf。

这篇白皮书可以作为BDB-JE HA性能的参考，也可以作为测试选型BDB-JE HA的依据。需要注意的是，性能数据依赖于很多因素的影响，我们的测试结果仅作参考。

同时，你可能发现附件中涉及到的关于GC和JVM参数的调整，对于性能的巨大影响。

希望能对您有用。更多反馈，欢迎留言。