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 <hostname> -port <hostport> -store <kvstore name> 

如果输出结果为 "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。 转载请注明出处，谢谢。

作为甲骨文大数据产品组合的一部分，Oracle NoSQL数据库提供企业级的NoSQL技术和支持

新闻事实

更快，更高效的动态，大容量数据存储

更多信息

• 关于Oracle大数据 – http://www.oracle.com/us/technologies/big-data/index.html
• 关于Oracle NoSQL数据库 – http://www.oracle.com/us/products/database/nosql/overview/index.html
• Oracle NoSQL数据库官方论坛 – https://forums.oracle.com/forums/forum.jspa?forumID=1388
• Oracle NoSQL数据库及伯克利数据库(Berkeley DB)中国开发者的： 博客 (www.bdbchina.com) 和微博 (weibo.com/bdbchina)

概览

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的时候。因此，副节点有可能会远远落后于主节点。总而言之，这种策略会提供较高的写性能，但也会带来较低的持久性。

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

副节点读一致性

因为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

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）。

我希望这会有所帮助。

http://www.weibo.com/bdbchina

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

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

Oracle Berkeley DB 中国开发团队

Oracle公司 Berkeley DB (简称BDB) 是业界知名的嵌入式数据库，目前拥有开源和商业两种使用许可。BDB被广泛应用于各种场合，从小型的手持设备（如手机）到大型的分布式应用（如云存储）都可以找到BDB的身影。

BDB产品研发团队在全球拥有一批资深工程师，某些工程师有超过20年的数据库开发经验。2007年，BDB在深圳成立了中国研发团队，组内工程师均毕业于国内和香港著名高校。

本次BDB产品研发团队面向社会招聘如下两个职位：
1. 数据库核心开发工程师（1人）；
2. 数据同步服务器（Oracle Mobile Server） 开发工程师（1人）。

两个职位的工作地点均在深圳，薪酬优厚。感兴趣的朋友请发简历至：chao.huang[at]oracle.com

职位1：数据库核心开发工程师（1人）

工作职责：
- 负责 Berkeley 数据库的性能优化和新功能开发工作；
- 负责 Berkeley 数据库分布式和云计算架构的设计和开发工作；
- 负责 Berkeley 数据库测试和QA工作；
- 协助销售团队解决客户技术问题。
职位要求：
- 熟悉一项或多项项目开发流程：项目规划和协调，新功能设计和实现，产品测试和QA，产品发布；
- 熟练掌握一种或多种编程语言（C，C++ 或者Java），熟悉一种或多种操作系统：Linux，Windows，Android等；
- 对SQL语言和数据库内核有较深入理解者优先，包括缓存管理，索引，日志，恢复，并发控制等等。

职位2：Oracle Mobile Server 开发工程师（1人）

工作职责：
- 参与Oracle Mobile Server的新功能开发、测试与性能优化；
- 协助Oracle Mobile Server软件发布。
- 为客户在使用过程中遇到的问题提供解决方案。
职位要求：
- 精通J2EE，SQL和PL/SQL的开发与测试。
- 熟练掌握一种或多种编程语言（C，C++ 或者Java），熟悉一种或多种操作系统：如Linux，Windows，Android；
- 有系统性能调优，SQL调优，Oracle数据库调优和Web/APP服务器调优经验者优先。

两个职位均要求有较好的英语读写能力，以及具有追求卓越的热情。除了参与产品本身的研发，也将有机会协助销售团队与中国的潜在 客户进行沟 通，解决客户所遇到的技术问题。目前，Berkeley数据库在中国市场（甚至是整个 亚太地区）的需求不断增大。加入我们，您可以通过 您的努力让我们的产品越来 越好，从而占领越来越多的市场。可以说，这是一份具有很大的挑战性，但是又是 充满乐趣的工作岗位！期待您的加入。

Oracle Berkeley DB is a family of embeddable database engines available under a dual license (Open source and commercial license). Berkeley DB is very popular, and is widely used in a variety of commercial as well as open source applications ranging from hand-held devices like cell phones to large, mission critical applications.

The Oracle Berkeley DB group is looking for one Database Kernel Developer and one Oracle Mobile Server Developer to join the development group in Shenzhen, China. The salary is negotiable.  We welcome junior level up to principal level of applicants to apply for our openings. If you want to join us, please send your resume to:  chao.huang[at]oracle.com.

We have a highly talented and experienced group of engineers distributed world-wide, several with more than twenty years of experience in the database industry. We have a small, but excellent development team in Shenzhen, China.

Position1： Database Kernel Developer

Job Responsibilities：
- Berkeley DB performance tuning and new feature implementation;
- Berkeley DB distributed and cloud computing architecture designing and implementation;
- Berkeley DB testing and QA;
- Assist in providing technical support for customers.
Job Requirements:
- Experience in one or more aspects of product development: project planning and coordination, new features design and implementation, testing and QA, product release is highly desirable.
- Expertise in one or more programming languages (C, C++ or Java) and familiarity with one or more operating system platforms like Linux, Windows, Android is required.
- Excellent knowledge of SQL and database internals, including buffer management, indexing, logging, recovery, concurrency control, etc will be a strong plus.
- Good interpersonal and communication (English and Chinese) skills are critical. The Berkeley DB development group has a very informal but effective and results-oriented work environment; a good cultural fit is important.

Position2：Oracle Mobile Server Developer

Job Responsibilities:
- Work on development, test and improvement of Oracle Mobile Sync Server product;
- Assist in releasing of Oracle Mobile Sync Server software;
- Assist in providing technical support for customers.
Job Requirements:
- Familiar with J2EE, SQL and PL/SQL development and testing.
- Expertise in one or more programming languages (C, C++ or Java) and familiarity with one or more operating system platforms like Linux, Windows, Android is required.
- Experience in Performance Profiling, Tuning SQL, Tuning Oracle Database and Tuning Web/APP Server will be an advantage.

Both positions require good written and verbal communication skills, and passions for excellence. Besides the opportunity to enhance the Berkeley DB family of products, there is also an opportunity to assist the local sales team with customers and prospects in China. There is a growing demand for products like Berkeley DB in the China market (and APAC in general) and the ideal candidate will be able to assist and make a difference! It’s truly a demanding, but fun opportunity!

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).

1. Oracle Berkeley DB 和Mobile Server的架构

Oracle Berkeley DB 和Mobile Server的架构

2. Oracle企业移动应用平台

Oracle企业移动应用平台

1. Thomson Reuters的需求

Thomson Reuters要解决的问题

2. 使用BDB的解决方案

BDB的解决方案