==============================================================

概述

当选择一个数据库时，其性能的好坏往往是我们要考虑的第一关键因素。本白皮书介绍了一些性能测定的方法，旨在帮助你理解从Berkeley DB 数据库的一些常见配置预期会得到怎样的性能。你的应用程序的性能也取决于你的数据、数据访问的模式、缓存大小、其他配置参数、操作系统、以及硬件等。基准测试并不能反映某一个特定的应用程序的性能好坏，但它们可以提供一些基准，并为建立基本可行的期望提供指导和帮助。

介绍

通过一些在一定配置下进行的测试，本文给出了有关Oracle Berkeley DB (BDB) 11gR2 (11.2.5.0.2.21) 吞吐量的信息。这些测试包括：不同配置下BDB 键/值接口 (key/value API) 得到的吞吐量，和使用Wisconsin 和类TPC-B 基准对BDB SQL接口进行测试得到的性能数据。

实验环境

所有的实验结果都是用相同的硬件配置得到的，硬件信息如表1所示：

表1. 硬件配置

键/值接口的性能概述

Berkeley DB 是高可配置的，它可以配置来使用或禁止数据库操作的大多数特性，例如，事务日志（WAL）功能，并发控制的锁机制。由于这个原因，Berkeley DB 将在两种不同配置环境下进行实验：分别对应于非事务性及事务性。

第一组实验测试数据存储Data Store(DS)。DS是Berkeley DB的配置选项之一。DS本质上是一种简单的、单线程、非事务性的存储系统。第二组实验测试事务性数据存储Transactional Data Store(TDS)。TDS是Berkeley DB的一种能提供所有事务语义(transactional semantics)的配置选项。表2给出这两种功能集的区别。

表2. 数据存储与事务性数据存储属性

这两组实验都使用512MB的缓存，在数据库环境中设置DB_PRIVATE的标志，同时空间局部值（spatial locality）设为10。使用DB_PRIVATE标志说明在数据库中使用堆内存（heap memory）作为其高速缓存（cache），这种配置只适用于单进程（可能有多个线程）的环境中执行。

最常用的数据库性能衡量标准是吞吐量（就是在固定时间段里读取或写入的记录数）。在我们的实验中，我们把吞吐量定义为是用Berkeley DB11gR2 (版本号为11.2.5.0.21)每秒能达到的操作次数。

在实验中，我们使用固定长度的记录。每条记录包括64字节的键值（key）和64字节的数据值（data）。所有的键值和数据值均为整数型。每个实验进行57,600批次，每个批次对应10个顺序的键值操作。比如，在插入测试中，随机产生第一个键的值（记住k），并对它进行插入操作；接下来再插入9个记录， 这9个记录具有连续的键值（k+1, k+2, k+3, …, k+9）；这个过程将重复57,600次。每个测试都运行5次，并记录相应的吞吐量的平均值和标准差。

针对每个配置，下面是实验的步骤：

• 步骤一：

生成一个具有576,000条记录的数据库（就是57,600组，每组具有10个顺序键值的记录）。这个过程仅仅是生成用于实验的数据库和预热缓存，测试并不记录其消耗的时间。

• 步骤二：

检索57,600个随机记录组，每组具有10个连续键值的记录（读取操作）。

• 步骤三：

更新57,600个随机记录组，每组具有10个连续键值的记录（更新操作）。

• 步骤四：

删除数据库中的所有记录，以每组具有10个连续键值的记录为单位（删除操作）。

• 步骤五：

像步骤一那样，重新生成测试的数据库（插入操作）。

针对每一个类型的操作（读取、更新、删除、插入），计时从第一个组操作前开始直到完成最后一组操作结束。这期间不包括用于打开和关闭数据库环境和数据库句柄所花的时间。

数据存储：单线程

第一组实验是衡量使用Berkeley DB DS来测试单线程应用程序所达到的吞吐量。表3是实验得到的结果。

表3. BDB DS 单线程的性能

事务性数据存储：单线程

第二组实验统计了基于Berkeley DB TDS的单线程应用程序在不同的配置下所达到的吞吐量。这些配置包括：写持久性，日志持久性，和存储介质。每个配置将解释为：

• 写持久性

默认条件下，事务将被同步提交到磁盘。设置DB_TXN_NOSYNC标志将意味着异步提交（即数据不会同步到磁盘），而DB_TXN_WRITE_NOSYNC标志意味着把数据写入到文件系统但不会同步到磁盘。

• 日志持久性

默认测试，日志是存储在磁盘中；同时也测试了非持久的、内存中的日志信息。

• 不同的存储介质

默认的配置是采用一个传统的硬盘。我们将比较使用这种默认配置和使用2GB的RAM在存储数据库和日志文件方面得到的性能。在所有的情况下，事务都会同步提交。

表4. BDB单线程性能

1 2GB RAMDISK, 数据库和日志均存在RAM磁盘中

2 DB_TXN_WRITE_NOSYNC，事务提交时设置的标志

3 DB_TXN_NOSYNC，事务提交时设置的标志

4允许在内存中存储日志

在所有的实验中，我们使用足够大的缓存大小，所以磁盘的I/O操作并不影响读的吞吐量。通过对比TDS和TDS RAMDISK的结果，不难发现磁盘的I/O延时和性能会大大影响写操作。通过比较TDS SYNC, TDS INMEM, TDS WNS 和 TDS NS的结果，我们可以发现不同的持久性设置也会影响到写的吞吐量。

上述结果显示了对数据库来说很常见的一些有趣特点。其中一个特点是I/O是决定数据库性能好坏的最关键因素。I/O操作尽管对数据库的读操作来说，仅会造成较小影响，但却是决定写操作性能的关键原因。在使用TDS进行的实验中，插入和更新操作会导致大量的I/O操作，所以在性能上会受到很大的影响。

这些实验表明了五种主要类别造成的延迟：

• 内存和处理器

• 从用户到内核空间之间的传递

• 文件系统

• 存储I / O

• 介质

TDS INMEM的实验是最快速的，因为所有的事务提交到内存的数据缓冲区，没有把数据转入到文件系统缓冲区或是磁盘所带来的开销。使用TDS INMEM单线程进行插入操作的实验为你的系统显示了最理想的速度，但是可能不是很有用，原因是此时数据不具有永久性。在进程意外结束时，内存中的数据将会被删除掉，所有没有持久性可言。

当事务配置了DB_TXN_NOSYNC标志时，在事务提交时，数据是不会从日志缓存区提交或同步到文件系统的。相反，日志会被保留在日志缓存区中直到该缓存满为止，此时一个文件系统的写操作会把日志从用户内存传输到内核或是文件系统内存中。接下来，由文件系统自己决定数据是否要写进以及何时写进磁盘介质中。所以，在TDS INMEM和TDS NS之间的不同性能正好反映了当日志缓存区满时把日志记录从用户级别的日志缓存区传输到内核或是文件系统内存所带来的开销。

当事务配置了DB_TXN_WRITE_NOSYNC标志时，Berkeley DB在每个事务提交时都会把日志从用户级别的日志缓存区提交或同步到操作系统或是文件系统。这样只要在把数据写到磁盘之前该操作系统不挂掉，就能提供持久性的保证，。因此，在应用程序挂掉时，只要操作系统能继续在运行的话，数据就不会丢失。但是，如果此时操作系统或是硬件也挂掉的话，已写入操作系统但没有写入磁盘的数据将会被丢失。

在TDS WNS和TD SNS的实验中，插入操作得到的不同结果就是反映了把日志从Berkeley DB日志缓存区拷到文件系统时造成事务提交的时间上的差别。最后，通过对比TDS SYNC和TDS RAMDISK的结果，你就会观察到往内存中写和往磁盘上写带来的性能差别。在TDS SYNC这个实验中，SATA总线和硬盘驱动带来的开销会大大降低性能。

相当有趣的是，在所有的实验中，读操作的性能基本上是一致，平均值占标准差只有1%（标准差=1655.92，平均=161240.2，百分比=1.026989482）。这说明了在所有的实验中，缓存造成的影响是一样的，因此在对内存中的数据进行读操作时带来的事务开销是可以忽略不计的。 尽管没有统计，但是I/O操作的开销决定了对在缓存外的数据进行读操作所需要的时间。

事务性数据存储：扩展对称多处理系统

下表显示的是BDB TDS在对称多处理系统（SMPs）时性能的数据。针对多线程访问，每个线程都使用一个数据库句柄（DB handle）以减少线程间的竞争。每个线程使用一个计时器来计算其吞吐量。下表显示的是所有这些信息的集合。

当引入第二个线程时，每个操作的吞吐量将相应地减少，原因是系统将进行一些锁操作，所以会导致一些相应的开销。总体上来说，写操作的吞吐量将随着线程数加大而呈按比例递增。但是，当读线程超过4个的时候，读操作的吞吐量将下降，原因是此时CPU的利用率是100%，而额外的线程需要一些不必要的上下文交互和硬件缓存的回收。

表5. 在SMP系统上，配置不同线程数对应的TDS性能

图1. 在SMP系统上，配置不同线程数对应的TDS性能

SQL接口性能概述

目前有很多流行的基准（benchmarks）是专门为基于SQL的关系数据库而设的。为适应Berkeley DB的SQL接口，我们参考实现了类似的基准。

我们的实验启发自两种流行基准: 事务处理性能委员会的TPC- B基准¹和D. J. DeWitt 的Wisconsin基准²。

这些基准实现和测试数据, 没有被第三方验证或审核，而仅仅作为我们在不需要其它软件系统介入的情况下试图去认识有关BDB性能特征所做的努力。

TPC-B 基准

TPC-B基准的测试需要实现TPC B规范要求的一些模式（Schema）和标准事务。帐户（accounts）的数目是按比例下降的，这样做的目的是在运行的时候方便管理。它有1000家分支机构（branches），总共拥有10000个出纳员（tellers）和100,000个帐户。

下表显示的是由TPC B生成的事务吞吐率（以每秒的事务数（TPS）为单位）。这些结果是从一个256兆字节大小的数据库缓存中得到。

表6- TPC-B 事务吞吐率

图2. 由类TPC-B基准衡量的每秒事务数（TPS）以及对应的线程数

Wisconsin 基准

本测试尝试按照Wisconsin 基准规范规定的模式和查询进行，但是并没有尝试去降低由数据库系统和操作系统引起的缓存效应。

这个实验衡量了在标准数据库上进行大量不同测试案例的单用户性能。所有的测试案例组合的结果可用于分析一个数据库的优势和弱势。对于查询的描述，请参阅链接⁴中的附录一。

为了这些实验能够正常运行，数据库是配置了针对单线程和单用户访问的编译优化选项。每个查询运行10次，下表显示的是平均需要的运行时间，以毫秒为单位。

表7. 由Wisconsin基准衡量的平均运行时间

参考

1 http://www.tpc.org/tpcb/default.asp

2 http://firebird.sourceforge.net/download/test/wisconsin_benchmark_chapter4.pdf

3 http://www.tpc.org/tpcb/spec/tpcb_current.pdf

4 http://firebird.sourceforge.net/download/test/wisconsin_benchmark_chapter4.pdf

结束语

Berkeley DB 键/值接口无论在单线程还是在多线程的应用程序上都执行地非常好。同时，如果一个应用程序并不需要完全的持久性的话，它将能非常显著地提高其性能。

Berkeley DB在11gR2 5.0的版本中增加基于键/值接口的SQL API。你可以从这里下载Oracle Berkeley DB:  http://www.oracle.com/technology/software/products/berkeley-db/index.html

你也可以在Oracle Technology Network (OTN) 论坛上发表相关评价以及提交问题：

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

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

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

概览

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

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!

1. Oracle Berkeley DB 和Mobile Server的架构

Oracle Berkeley DB 和Mobile Server的架构

2. Oracle企业移动应用平台

Oracle企业移动应用平台

在2010 Oracle Open World大会上，GenieDB带来了一场十分精彩的，关于是BDB构建云计算的演讲。本文抽取部分章节，供广大读者参考。转载请注明出处，谢谢。

1. GenieDB面对的问题

GenieDB面对的技术挑战

2. 技术需求

GenieDB的技术需求

3. 使用BDB的解决方案

使用BDB的解决方案（架构图）

4. 为何使用BDB？

使用BDB的优势

本人介绍的是Berkeley DB 5.o以来新推出的SQL接口 — 由Oracle和SQLite同时演讲。其中BDB部分的精彩剪辑有：

1. Oracle数据库家族的构成及区分

在Oracle，我们的数据库产品线覆盖从企业数据中心到个人移动端，覆盖到几乎所有的场合。根据计算能力和技术要求，我们划分如下图一所示：

图一 Oracle数据库家庭的构成和划分

那么，针对BDB而言，我们的强项主要集中于2个方向：仪器及设备 + 企业基础架构

2. BDB的典型应用是在仪器及设备 和 企业基础架构层

具体的使用场景和优势，请参考下图二和图三所示：

图二 BDB在仪器及设备的应用

图三 BDB在企业基础架构层的应用

3. SQLite 不是和BDB竞争，而是合作

根据SQLite的作者Dr. Richard Hipp，SQLite的设计是用来替代文件系统的fopen()。SQLite面向的更多是：要求简单的数据库功能（SQL，事物等），使用简单，性能及并发要求不高的场合。

SQLite与BDB的组合（即BDB 11gR2的SQL接口）面对的是由于SQLite本身的瓶颈，而不能达到的一些问题和场合 — 比如更好的并发性，性能，加密，集群，更好的技术支持和市场推广，等等。因而说SQLite不会和BDB直接竞争，相反是合作共赢，共同推动SQLite社区和用户发展。

如下图四所示，BDB 11gR2的SQL接口是SQLite的SQL层和BDB的底层存储引擎的完美结合。

图四 BDB 11gR2的SQL接口是SQLite的SQL层和BDB的底层存储引擎的完美结合

4. SQLite的可能发展方向

图五 SQLite 目前缺失的功能

注意，这里Dr. Richard用的词是：SQLite 目前缺失的功能，并不代表说将来会提供以及什么时候以何种方式提供。

]]> http://www.bdbchina.com/2010/10/oracle-open-world-2010%e6%97%a7%e9%87%91%e5%b1%b1-bdb-%e6%bc%94%e8%ae%b2%e7%b3%bb%e5%88%97-i/feed/ 0 http://www.bdbchina.com/2010/10/%e5%a5%bd%e6%b6%88%e6%81%af%ef%bc%9aberkeley-db-%e5%b7%a5%e4%bd%9c%e6%9c%ba%e4%bc%9a%ef%bc%81/ http://www.bdbchina.com/2010/10/%e5%a5%bd%e6%b6%88%e6%81%af%ef%bc%9aberkeley-db-%e5%b7%a5%e4%bd%9c%e6%9c%ba%e4%bc%9a%ef%bc%81/#comments Tue, 12 Oct 2010 08:16:59 +0000 chaohuang http://www.bdbchina.com/?p=1464 大家好，

Berkeley DB中国研发团队计划招聘2名有数据库相关工作经验的人士。如果您有志于做嵌入式数据库开发或者测试，有相关的系统编程的经验（如操作系统，云存储等），并希望和Berkeley DB一起成长并从中make a difference，请速与我联系； 如果您有Oracle关系数据库及Weblogic等相关的开发、测试及性能优化经验的，也请速与我联系。

具体工作职责和职位要求，请参照“招纳贤士”板块 - http://www.bdbchina.com/recruit/。

注意：
1. 本次计划招聘一名开发及一名测试人员。薪水面议。工作地点： 深圳。
2. 简历请投递到chao.huang@oracle.com。 推荐使用gmail, hotmail, qq等邮箱；163， 263等邮箱通常投递都会失败。
3. 欢迎留言，谢绝来访。

* 使用基于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功能/

更多反馈，欢迎留言。

R-Tree是一种和BTree类似的数据结构，支持高维数据的快速检索，被广泛应用于各种空间数据中。R-Tree的一个典型的应用是从许多空间对象的信息中找出用户关心的那个。如给定一座城市各个建筑物的经纬度坐标并存储于R-Tree中，用户可以通过“查找当前位置向西五公里内的所有餐厅”，“查找会展中心方圆一公里内的所有汽车站”等方式来查询自己感兴趣的某些特定建筑。

2 BDB11gR2的R-Tree功能

新发布的BerkeleyDB 11gR2(以下简称BDB11gR2）版本能够无缝地兼容SQLite的接口，从而支持各种基于SQLite的应用，包括SQLite自带R-Tree扩展应用。关于SQLite的R-Tree细节，可参见http://www.sqlite.org/rtree.html。
下面，本文将从编译和使用两方面，介绍如何在BDB11gR2中使用R-Tree功能。

2.1 编译

BDB11gR2通过编译开关控制是否启用R-Tree功能。默认情况下，BDB11gR2是不启用R-Tree的。要获得R-Tree的支持，则应该在编译时加上SQLITE_ENABLE_RTREE标志。

Linux平台

cd build_unix
../dist/configure CPPFLAGS=-DSQLITE_ENABLE_RTREE --enable-sql
make dbsql


Windows平台

在工程文件的属性中，选择 Properties -> Configuration Properties -> c/c++ -> Command Line -> Additional Options, 加入/D DSQLITE_ENABLE_RTREE，并重新编译工程。

2.2 使用R-Tree

一棵R-Tree实际上对应于一张虚拟表。建立R-Tree索引的过程，实际上就是建立虚拟表的过程。和普通表类似的，我们也可以对这张特殊的虚拟表进行插入，删除，更新等操作。

我们以下面这张图为例来说明R-Tree的典型操作和应用。

在图1中，有三个蓝色的矩形，代表三个建筑的边界，标记为1，2，3。它们的坐标信息如图所示。我们要建立一棵R-Tree，来存储这些矩形的坐标信息，并在此基础上进行一些简单的查询。

建立R-Tree索引

CREATE VIRTUAL TABLE demo_index USING rtree(
id,
minX, maxX,
minY, maxY
);

以上操作建立了一张R-Tree索引表。该索引表中每一条记录代表了一个矩形框。每条记录由5列组成，其中id是一个整数类型的主键，minX，maxX分别代表矩形框横坐标的最小值和最大值，minY，maxY分别代表矩形框纵坐标的最小值和最大值。注意，BDB11gR2中的R-Tree表的列数必须是3-11之间的基数，其中第一列是表的主键，2k和2k+1列分别代表第k维数据的下界和上界(k=1~5).

插入数据

向R-Tree的表中插入数据，和向普通表中插入数据的语法是完全一致的。
以下三条语句插入了图1中的三个矩形：

INSERT INTO demo_index VALUES(
1,
0, 2,
0, 1
);
INSERT INTO demo_index VALUES(
2,
3, 5,
3, 5
);
INSERT INTO demo_index VALUES(
3,
4, 5,
1, 4
);

基于R-Tree的查询

和普通表类似的，用户卡可以对R-Tree表进行查询。如

SELECT id FROM demo_index
WHERE id=1;

但R-Tree表上更为常用和典型的查询则是范围查询(Range-Query). 举例如下：

SELECT id FROM demo_index
WHERE minX>=0 AND maxX<=3
AND minY>=0 AND maxY<=2;

查询的结果为
1

上面这条查询的含义是找出图1中所有被包含在红色虚线矩形框中的矩形。

SELECT id FROM demo_index
WHERE maxX>=1 AND minX<=4
AND maxY>=0 AND minY<=4;
查询结果为
1
2

上面这条查询的含义是找出图1中所有和黑色虚线矩形框有交集的矩形。

总结

R-Tree在高维数据的检索中有着广泛的应用。各种地理信息，带时间记录的归档信息等，都可以通过建立基于R-Tree的索引，来达到快速检索的目的。欢迎通过使用Berkeley DB11gR2的RTree功能来构建自己的R-Tree索引，若有任何相关问题，请联系  Linchun dot sun at Oracle dot com。

CREATE VIRTUAL TABLE demo_index USING rtree(

   id,               

   minX, maxX,       

   minY, maxY        

);

以上操作建立了一张R-Tree索引表。该索引表一共由5列组成，每一条记录代表了一个矩形框。其中id是一个整数类型的主键，minX，maxX分别代表矩形框横坐标的最小值和最大值，minY，maxY分别代表矩形框纵坐标的最小值和最大值。注意，r-tree的列数n必须为2m+1，其中m为表示对象的维数。

插入数据

在R-Tree的表中插入数据，和往普通表中插入数据的语法是完全一致的。

以下三条语句插入了图1中的三个矩形：

INSERT INTO demo_index VALUES(

1,                   

0, 2,  

0, 1     

);

INSERT INTO demo_index VALUES(

    2,

    3, 5,

    3, 5

);

INSERT INTO demo_index VALUES(

    3,

    4, 5,

    1, 4

);

基于R-Tree的查询

和普通表类似的，用户卡可以对R-Tree表进行查询。如

SELECT id FROM demo_index

 WHERE id=1;

但R-Tree表上更为常用和典型的查询则是范围查询(Range-Query). 

SELECT id FROM demo_index     

 WHERE minX>=0 AND maxX<=3

   AND minY>=0 AND maxY<=2;

查询的结果为

1

这条查询的含义是找出图1中所有被包含在红色虚线矩形框中的矩形。

SELECT id FROM demo_index     

 WHERE maxX>=1 AND minX<=5

   AND maxY>=0 AND minY<=4;

查询结果为

1

2

3

这条查询的含义是找出图2中所有和黑色虚线矩形框有交集的矩形。