概览

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

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四大产品线的特点以及应用，希望能对中国市场的新老用户有所启发和帮助。

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的信息，可以参考下面相关链接：

• Berkeley DB XML下载
• Berkeley DB XML相关文档
• Berkeley DB XML FAQ
• 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的信息，可以参考下面相关链接：

• JE下载
• JE相关文档
• JE FAQ
• JE官方论坛

1.4 应用举例

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

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

可能的应用场景包括：

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

举例而言：

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

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主要提供以下功能：

1. 应用程序统一部署和配置。比如，应用Mobile Server方案的移动设备都可以自动实现软件的安装、更新和打补丁等等配置，这一过程不需要用户的过多参与。
2. 移动设备统一管理。管理员可以远程收集众多移动设备的信息，同时也可以进行统一的操作与部署。比如，管理员可以远程向丢失的移动设备进行额外加密或者销毁设备中的数据。
3. 移动设备与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 的应用举例：

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

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

• Oracle Database Lite 10g
• Oracle Database Lite Mobile Server 10g

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

更多反馈，欢迎留言。

这些年来，随着大量数据的产生，数据可视化（data visualization）广泛应用于科研、军事、金融、医疗等等领域。我们的生活也到处可见数据可视化的例子。比如，股票软件上显示的K线图，调查结果的柱状图、曲线图，人口分布的密度图等等等等。

那么，什么是数据可视化呢？根据维基百科的解释：Data visualization is the study of the visual representation of data, meaning “information which has been abstracted in some schematic form, including attributes or variables for the units of information”。简单来说，数据可视化就是用更加直观更加生动易懂的图形图像表现某种特定的数据集合。

这篇文章将简单介绍如何轻松利用BDB Java Edition （JE）和prefuse实现自己的数据可视化应用。

可视化工具和数据库的选择

首先我们选择prefuse作为数据可视化工具。prefuse是一个轻量级的用于可视化任意数据集（visualize the data）的java类库，它提供了多种数据可视化模式，比如柱状图、树图、饼图等等。它的优点是简单易用、可视化功能齐全。

但仅仅有可视化工具是不够的，还需要什么呢？当然还必须有存储数据的数据库。可以打个比方，数据是一栋房子，数据可视化就是我们要给房子做装修，让它更好看，那么数据库就是地基。没有地基，何来房子，更不用说装修了。那么，我们选择什么样的数据库呢。既然prefuse是java类库，而我们JE的特点是纯Java实现，性能高，footprint小等等，那么，JE绝对是一个很好的选择。

好了，现在就让我们看看JE + prefuse的威力吧。

数据集属性的定义

首先，我们选择需要做可视化的数据集。在这里，我给出的例子是可视化某个公司的员工数据，包括他们的基本属性，上下级关系和各自所参与的任务。

1. 员工（Employee）的属性

@Entity
public class Employee {
    @PrimaryKey
    int employeeId;

    @SecondaryKey(relate = MANY_TO_ONE)
    String employeeName;

    @SecondaryKey(relate = MANY_TO_ONE)
    float salary;

    @SecondaryKey(relate = MANY_TO_ONE, relatedEntity=Employee.class,
                 onRelatedEntityDelete=NULLIFY)
    int managerId;

    @SecondaryKey(relate = MANY_TO_ONE, relatedEntity=Department.class,
                 onRelatedEntityDelete=NULLIFY)
    int departmentId;

    @SecondaryKey (relate =MANY_TO_MANY, relatedEntity=ServiceRequest.class,
                 onRelatedEntityDelete=NULLIFY)
    Set<Integer> SRIds = new HashSet<Integer>();

    String address;
    String email;
    String phone;

    /* setter and getter functions. */
}

2. 部门（Department）的属性

@Entity
class Department {
    @PrimaryKey
    int departmentId;

    @SecondaryKey(relate = ONE_TO_ONE)
    String departmentName;

    String location;

    /* setter and getter functions. */
}

3. 任务（ServiceRequest）的属性

@Entity
class ServiceRequest {
	@PrimaryKey
	int SRId;

	String title;
	String content;

/* setter and getter functions. */
}

数据可视化效果

我们选择两种可视化方式：弧形树（radial tree）和节点树（node link tree）。下面看看我们的可视化效果。

利用radial tree来显示整个公司的结构（organization chart)：

上图左边最大的窗口显示的是整个公司的结构图。从图中可以看出公司有四个部门。每一个有颜色小节点代表一名员工，不同部门的员工具有不同的颜色。节点之间的连线表示上下级关系。上图右上角的小窗口显示的是选中的员工的具体信息。右下角的小窗口显示的是JE database 的schema图。从中可以看出我们定义了三个Entity: Employee, Department以及Service Request.

点击任意一个员工节点，将可以显示此员工的上下级结构图，也就是在此公司与之有关系的所有员工的结构图。比如我们点击名字叫Goodstein A. Chavez 的员工，结果如下图所示：

从上图可以看出，此员工有四名直接下属，而他的老板直接向公司的CEO汇报。

除了可以直接点击员工节点（基于员工ID）进行查询，我们还可以通过部门ID（Department ID）经理ID（Manager ID）和具体的任务ID（SR ID）和员工姓名来对员工进行查询。下面是对部门ID和任务ID查询的结果截图。

部门2的员工结构图（DeparmentID = 2）

部门2中，参与了任务3的员工（DeparmentID = 2 and SRId = 3）

值得一提的是，所有这些关系的查询都可以利用在JE里面定义的Entity之间的关系（relation），而不需要我们做额外的查询工作，比如想通过经理ID来查询此经理的直接下属，一句代码便可以实现：

dao.employeeByManagerId.subIndex(Integer.valueOf(searchKey)).entities();

JE+prefuse的优势总结

1. 简单易用：用过JE的朋友都知道，利用JE（特别是JE DPL）能够十分轻松、灵活定义各种数据集模型，其get/put操作也特别简单，而且能够很容易写出特定的查询语句。而prefuse也提供了功能齐全的可视化API。所以，利用JE做数据的存取操作，利用prefuse做数据的可视化操作，其对接是十分直接和简便的。
2. Footprint小：拿上面所举的员工数据可视化应用例子来说，整个应用程序打成可直接运行的jar文件才1.87M，但功能却很齐全（多种可视化效果，多种查询方式）。这样大小的程序，即使安装在一般的移动设备（比如手机）上运行都绰绰有余。
3. 性能高：数据可视化的性能主要体现在做查询和可视化的速度。还是以员工数据可视化为例，插入员工数据有1000条，存储到JE 数据库的大小是729k。之后用户对节点的点击和在输入框的查询，其可视化结果都能迅速得以显示（笔者没有做过具体的时间记录，但相信所需时间都是毫秒级的）。

结束语

从这个例子我们可以看出在数据可视化方面，利用JE作为存储引擎是一个很好的选择。有兴趣的朋友不妨一试。另外，这里有一个十分有趣例子，是利用JE和Google Visualization API来可视化一栋房子的用电情况（ electric usage of Hypatia House），感兴趣的朋友请参考以下链接：http://excitedcuriosity.wordpress.com/2010/02/22/its-electric-ted-data-storage-and-plotting/

One major focus of Berkeley DB has been replication for high availability (HA), the other is support for the Google Android phone platform.
* Read the new “BDB JE on Android” whitepaper
* See a screenshot of JE running on Android storing map coordinates displayed on Google Maps
* Search Oracle.com for Android (google: “site:oracle.com android”) note that most results are about BDB JE

Berkeley DB Java Edition (JE) 4.0.92

Includes the following new features and changes:

* Enhancements have been added for JE High Availability, which supports the use of JE with replication.
* The monitor package has several new event types which help a replicated application track replication group changes. A new example has been added to the replication example group to illustrate the use of RMI in replication write request forwarding.
* New properties have been added to help administer a replication group in the face of major hardware failure.
* A new RMI based example has been added to the set of JE HA Examples.
* See the High Availability Guide for an introduction to the product, and the com.sleepycat.je.rep javadoc for API specifications.
* JE’s MBeans and JConsole plugin have several new methods and capabilities to improve the ability to monitor an application. See the how-to for more information.
* Changes were made to make it easier to control JE’s use of java.util.logging through programmatic means.
* A number of bug fixes were made to work around problems in the Dvalvik libraries used by Android applications.
* A number of general bug fixes, performance improvements, and documentation improvements were made.

Software Downloads

* Downloads available today at http://download.oracle.com/berkeley-db/je-4.0.92.zip.

Questions?

Please direct your questions to our OTN forum at http://forums.oracle.com/forums/forum.jspa?forumID=273.

Android平台内置的存储数据库（或者说存储引擎）是SQLite。但由于SQLite其自身的一些缺陷，比如非Java语言、并发读写性能不 佳、技术支持困难等等，所以我们的用户倾向于Berkeley DB。我在这里向大家推荐Berkeley DB Java Edition（简称BDB JE）。我们可以把BDB JE的优势（它除了是存Java语言实现外，还有很高的存储性能和良好的并发性支持、Oracle的开发及技术支持团队等等）充分运用到Android 平台上。众所周知，Android平台是类Java语言的，所以，BDB JE对Android平台的开发者而言是一款利器。

以下将手把手教你将BDB JE快速配置到Android平台上（本文，我们用Android在PC机上的模拟器 (avd) 作为实例平台）。

准备工作

• 如果你的电脑上尚未安装Android SDK。那么首先点击这里下载并且安装 Android SDK。Android的官方主页上有详细的如何安装并且启动Android 模拟器（avd）的文档，这里就不再涉及。必须注意的一点是， 将你所安装的Android目录下（假如是<android-installation -home>）的 “tools” 文件夹路径加入到你电脑的路径（path）中去（相信有一定编程经验的读者一定很熟悉如何添加系统路径了），这样，你就可以直接在命令行上运行 Android的各种命令了。

• 点此下载最新版本的BDB JE。解压缩之后（假如你解压路径为JE_HOME/）可以看到在JE_HOME/lib/ 下有一个“je-android-4.0.71.jar”文件。如果找不到，说明你下载的不是最新版本的BDB JE。请到Oracle BDB JE官方网址进行下载：http://www.oracle.com/technology/products/berkeley-db/je/index.html。

• 在开始下面教程之前，我默认大家已经有一定的Android编程基础，如果没有，请大家到Android的官方主页上阅读相关文档（比如，如 何实现“hello world”）.

选择一：在装有Android 插件的Eclipse 编程环境下进行配置

• 如果你编程的IDE是Eclipse，并且你已经在上面安装了Android编程插件（如何在Eclipse上安装Android插件，请看这里），那么就继续阅读本小节以下步骤。注意，我用的是Eclipse3.4.2（Ganymede）版本， 也许不同的版本配置上有稍微的区别。这里建议Eclipse3.4版本以上。

• 打开Eclipse，确认在Windows->Preference->Android下已经写入Android SDK的路径。进入"File->New->Project->Android->Android Project->Next Project"，在弹出的建立project的面板上选择build target（比如Android2.0），并填写Project name (JEExample)、 application name (JEExample)、package name (com.sleepycat.je) 和 activity name (JEExample)。最后点击Finish。Eclipse将会自动帮你生成一个Android工程。假设你所建立的工程路径是<eclipse-je-android-dir>

• 进入”Project->Properties->Libraries->Add External JARs”，在弹出的窗口中选择JE_HOME/lib/je-android-4.0.71.jar。点击OK，你将可以看到在你建立的工程 （JEExample）下面有Referenced Libraries目录，点击之后可以看到je-android-4.0.71.jar。

• 复制代码（这些代码可在下面的"源代码"小节找到）：
  • 将JEExample.java 复制到<eclipse-je-android-dir>/src/com/sleepycat/je
  • 将main.xml 复制到<eclipse-je-android-dir>/ res/layout/main.xml and
  • 将strings.xml 复制到 <eclipse-je-android-dir>/res/values/strings.xml
• 在Eclipse中，打开main.xml，你可以看到在上一步中复制的代码。点击Run，运行JEExample。在正确运行之前，你还需要在 Android上面建立一个用于存储JE数据的文件夹，具体步骤看“在Android模拟器上运行程序”小节中的第一步。

选择二：在非IDE环境下进行配置

• 如果你不喜欢用IDE（如Eclipse)进行编程，只想通过命令行进行配置，请继续阅读本小节以下步骤。

• 首先建立一个Android 的模拟器（AVD）（如果你还没有在你的电脑上建立过Android 的模拟器）：
  • 在命令行运行 android create avd --target 3 --name my_avd （注意，我在这里建立的是Android1.6的模拟器，你也可以建立Android2.0模拟器）
  • 在你想要建立Android工程的目录下面，运行
    • android create project --path JEExample --package com.sleepycat.je --name JEExample --activity JEExample --target 3

    命令运行之后，将在你所在目录下面建立Android工程，文件夹的名称叫做JEExample，其中会有 JEExample/src/com/sleepycat/je/JEExample.java 文件。


• 将JE_HOME/lib/je-android-4.0.71.jar 文件复制到JEExample/libs

• 将三个文件：JEExample/src/com/sleepycat/je/JEExample.java， JEExample/res/layout/main.xml 和 JEExample/res/values/strings.xml 替换成下面“源代码”小节中对应的三个文件：JEExample.java， main.xml 和 strings.xml。

• 进入<android-installation-home>/platforms/android-1.6/tools， 打开 dx.bat 文件， 将其中一行 “REM set javaOpts=-Xmx256M” 改成 “set javaOpts=-Xmx512M“。注意“REM”要去掉。另外，如果你之前建立的Android模拟器 （AVD）是Android2.0，那么就更改android-2.0/tools下的dx.bat文件。

• 运行Android 模拟器：emulator -avd my_avd

• 用命令行进入JEExample目录，然后运行命令
  • ant install

这个命令将会编译JEExample.java ，然后生成JEExample/bin/JEExample-debug.apk ，并将它安装到你所运行的Android 模拟器中。

在Android模拟器上运行示例程序

• 首先，为Android程序建立JE environment 路径，用于存储JE的数据（这一步不可忽略，并且路径名要跟程序一致，否则无法正确运行程序）。具体做法是 ：
  • 在命令行运行adb shell mkdir /data/local/je。或者你首先运行adb shell，然后cd data/local，最后mkdir je。
  • 你也可以删除这个文件夹：rm /data/local/je/*。更多adb shell的命令请参照Android文档。
• 在Android模拟器窗口上点击三角按钮（在Home界面）进入程序列表，在这里你可以看到已经安装上去的 JEExample 程序图标, 点击它，运行JEExample程序。 进入程序之后，在程序界面最上方可以看到  “JEExample”  字样，下面是一个 文字编辑框（TextEdit box）, 还有两个按钮，分别是 “Put Data” 和  “Get Data” 。

• 存数据：
  • 在文字编辑框里输入 key/data 数据对（比如 k1/d1）然后点击 “Put Data” 按钮，这样一条数据（键是k1，值是d1）便存进JE数据库中。

你可以在命令行运行adb shell，进入/data/local/je， 就可以看到JE的存储数据。

• 读数据：
  • 在文字在文字编辑框里输入 你之前存储的键值key（比如k1），然后点击 “Get Data” 按钮，将会弹出“Get Data”的对话框，上面显示你之前存储的数据（比如d1）。

JE示例源代码

• JEExample.java

  
  package com.sleepycat.je;
  
  import android.app.Activity;
  import android.app.AlertDialog;
  import android.content.DialogInterface;
  import android.util.Log;
  import android.os.Bundle;
  import android.view.View;
  import android.widget.Button;
  import android.widget.EditText;
  import android.widget.TextView;
  
  import java.io.File;
  
  import com.sleepycat.je.Database;
  import com.sleepycat.je.DatabaseConfig;
  import com.sleepycat.je.DatabaseEntry;
  import com.sleepycat.je.DatabaseException;
  import com.sleepycat.je.Environment;
  import com.sleepycat.je.EnvironmentConfig;
  import com.sleepycat.je.OperationStatus;
  import com.sleepycat.je.Transaction;
  
  public class JEExample extends Activity {
  
      @Override
      public void onCreate(Bundle icicle) {
          super.onCreate(icicle);
  
          try {
              final File envDir = new File("/data/local/je");
              final EnvironmentConfig envConfig = new EnvironmentConfig();
              envConfig.setTransactional(true);
              envConfig.setAllowCreate(true);
              final Environment env = new Environment(envDir, envConfig);
              final DatabaseConfig dbConfig = new DatabaseConfig();
              dbConfig.setTransactional(true);
              dbConfig.setAllowCreate(true);
              dbConfig.setSortedDuplicates(true);
              final Database db = env.openDatabase(null, "exampledb", dbConfig);
  
              setContentView(R.layout.main);
              final Button button1 = (Button) findViewById(R.id.do_put);
              button1.setOnClickListener(new Button.OnClickListener() {
                  public void onClick(View v) {
  
                      final EditText editText =
                          (EditText) findViewById(R.id.entry);
                      final String keyData = editText.getText().toString();
                      final int idx = keyData.indexOf("/");
                      String key = null;
                      String data = null;
                      String result = null;
                      if (idx < 0) {
                          result = "enter key/data to put";
                      } else {
                          key = keyData.substring(0, idx);
                          data = keyData.substring(idx + 1);
                          result = key + "/" + data;
                          final DatabaseEntry keyEntry =
                              new DatabaseEntry(key.getBytes());
                          final DatabaseEntry dataEntry =
                              new DatabaseEntry(data.getBytes());
  
                          try {
                              final Transaction txn =
                                  env.beginTransaction(null, null);
                              final OperationStatus res =
                                  db.put(txn, keyEntry, dataEntry);
                              if (res != OperationStatus.SUCCESS) {
                                  result = "Error: " + res.toString();
                              }
                              txn.commit();
                          } catch (DatabaseException DE) {
                              result = "Caught exception: " + DE.toString();
                          }
                      }
                      Log.d("JE", "did put of: " + result);
  
                      if (result.contains("Caught exception:")) {
                      	new AlertDialog.Builder(JEExample.this).
                      	    setTitle("Put Data").setMessage(result).
                      	    setPositiveButton("Quit", new DialogInterface.OnClickListener() {
                      		    public void onClick(DialogInterface dialog, int whichButton) {
                      		    }
                      		}).show();
                      } else {
                      	new AlertDialog.Builder(JEExample.this).
                  	        setTitle("Put Data").setMessage("You put the key/data pair: " + result).
                  	        setPositiveButton("Confirm", new DialogInterface.OnClickListener() {
                  		        public void onClick(DialogInterface dialog, int whichButton) {
                  		        }
                  		    }).show();
                      }
                  }
              });
  
              final Button button2 = (Button) findViewById(R.id.do_get);
              button2.setOnClickListener(new Button.OnClickListener() {
                  public void onClick(View v) {
  
                      final EditText editText =
                          (EditText) findViewById(R.id.entry);
                      final String key = editText.getText().toString();
                      final DatabaseEntry keyEntry =
                          new DatabaseEntry(key.getBytes());
                      final DatabaseEntry dataEntry = new DatabaseEntry();
                      String result = null;
                      try {
                          final Transaction txn =
                              env.beginTransaction(null, null);
                          final OperationStatus res =
                              db.get(txn, keyEntry, dataEntry, null);
                          if (res != OperationStatus.SUCCESS) {
                              result = "Error: " + res.toString();
                          } else {
                              result = new String(dataEntry.getData());
                          }
                          txn.commit();
                      } catch (DatabaseException DE) {
                          result = "Caught exception: " + DE.toString();
                      }
                      Log.d("JE", "did get of: " + result);
                      if (result.contains("Caught exception:")) {
                      	new AlertDialog.Builder(JEExample.this).
                  	        setTitle("Get Data").setMessage(result).
                  	        setPositiveButton("Quit", new DialogInterface.OnClickListener() {
                  		        public void onClick(DialogInterface dialog, int whichButton) {
                  		        }
                  		    }).show();
                      } else {
                      	new AlertDialog.Builder(JEExample.this).
                  	        setTitle("Get Data").setMessage("Get result: " + result).
                  	        setPositiveButton("Confirm", new DialogInterface.OnClickListener() {
                  		        public void onClick(DialogInterface dialog, int whichButton) {
                  		        }
                  		    }).show();
                      }
                  }
              });
          } catch (Exception DE) {
              TextView tv = new TextView(this);
              tv.setText("blew chunks " + DE);
              setContentView(tv);
          }
      }
  }
  

• res/layout/main.xml

  
  <?xml version="1.0" encoding="utf-8"?>
  <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
      android:orientation="vertical"
      android:layout_width="fill_parent"
      android:layout_height="fill_parent"
      >
  
    <TextView android:id="@+id/label"
      android:layout_width="fill_parent"
      android:layout_height="wrap_content"
      android:text="JEExample"
      />
  
    <EditText android:id="@+id/entry"
              android:layout_width="fill_parent"
              android:layout_height="wrap_content"
              android:background="@android:drawable/editbox_background"
              android:layout_below="@id/label"
      />
  
    <Button android:id="@+id/do_put"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="@string/button_put"
      />
  
    <Button android:id="@+id/do_get"
            android:layout_width="wrap_content"
            android:layout_height="wrap_content"
            android:text="@string/button_get"
      />
  </LinearLayout>
  

• res/values/strings.xml

  
  <?xml version="1.0" encoding="utf-8"?>
  <resources>
      <string name="app_name">JEExample</string>
      <string name="button_put">Put Data</string>
      <string name="button_get">Get Data</string>
  </resources>

结束语

怎么样，是不是很简单就可以将JE配置到Android中了？你也赶紧试试吧。如果在配置或者安装过程中出错，欢迎给我留言。

注：英文好的同学，可以参照JE最新发布包中的<je-home>/docs/HOWTO-Android.html的英文原文。

概览

Berkeley DB Java 版是一套纯Java语言实现的嵌入式数据库。它提供的事务存储引擎不仅显著的减少了对象持久化开销，而且保持了对象-关系映射（ORM）解决方案的灵活性，速度和扩展性。Berkeley DB Java版3.0引入了直接持久层（DPL），旨在提供和与企业 Java Bean 3.0 (EJB3) 持久性相同好处：对象持久化时，不需要将对象转换成关系表。

更多请参见我在OTN上完整的中文翻译：http://www.oracle.com/technology/global/cn/products/berkeley-db/pdf/bdb-je-persistence-api-basics.pdf

英文原文：http://www.oracle.com/database/docs/BDB-JE-DPL-Basics-Whitepaper.pdf

起源

加州大学伯克利分校的BSD 4.3及以前的所有版本包含了专属于AT&T Unix代码，而当时从AT&T获得源码许可证是非常地昂贵。为了不受许可证的支配，当时BSD的开发者Keith Bostic提议，BSD系统中应该有更多的非AT&T部分，以Net/1的协议发布。随后，在1991年，Keith Bostic和Margo Seltzer 以及 Mike Olson一起着手开发了Berkeley DB以替换当时的Unix下经典的数据库引擎ndbm（New Database Manager， http://en.wikipedia.org/wiki/Ndbm）。这之后Berkeley DB迅速流行起来，并促成了Sleepycat Software公司（在2006年2月时，Sleepycat Software被甲骨文收购）。 时间进入到2004年，随着Java语言的大行其道以及其对多线程机制的良好支持，Berkeley DB的开发者们为Java开源社区带来一味大餐，这便是今天的Oracle Berkeley DB Java版(下文简称为 JE)。

JE 介绍

关系数据库是开发人员可用来进行数据存储和分析的最复杂的工具之一。大多数持久化的对象数据并非为特定的SQL的查询分析而存在；它们通常在程序中被检索，然后重构成为具体Java 对象才能使用。我想这就是现在一些主流Java企业应用中用到的Object-Relational Mapping(ORM)的技术。但从Java面向对象编程的角度看，能否直接将要持久化的对象通过诸如IO serialization 的办法直接保存到文件上，并能享有关系数据库系统提供的事务，并发，和高效的好处呢？ 设想一下，去掉了SQL解析和优化的开销，抛开了JDBC以及数据在客户端/服务器通信的巨大开销，应用的速度提升将会有多少？
JE正是居于这一设计思想而孕育出来的，是完全用 Java 设计，运行在应用程序的地址空间中，没有客户端/服务器通信的开销，从而使开发人员能够快速、简单、可靠地存储和检索信息。

主要特性

1. 轻松快速地数据存储
Berkeley DB Java 版可以轻松快速地存储数据，而不会导致像其他数据库中那么多的开销。Berkeley DB Java 版是与您的应用程序运行在同一 JVM 中的单个 JAR 文件，因此不需要远程服务器。本地缓存在内存中保存最活跃的数据以避免了开销较大的磁盘访问，并将 JVM 内存的使用限制到一个可预测的数量。

* 本地、进程间数据存储
* 与模式无关的、应用程序本机数据存储
* 按关键字访问的数据检索和顺据数据检索
* 易于使用的 Java 集合 API
* 用于访问 Java 对象的直接持久层 (DPL)
* DPL 类的模式进化
* 单进程、多线程模型
* 用于高并发性的记录级锁定
* 对辅助索引的支持
* 内存中和/或磁盘上
* 可配置的后台清理器线程重新组织数据并优化磁盘使用

2. 可靠地事务处理能力
Berkeley DB Java 版可靠地存储数据并确保数据完整性。如果系统发生故障，Berkeley DB Java 版将恢复事务数据并根据日志和数据库信息将系统重置为可运行的、一致的状态。

* 完全符合 ACID
* 可选择的隔离级别和持久性保证，可在每事务基础上进行配置
* 使用 Java 事务 API (JTA) 托管的事务
* 使用 J2EE 连接器体系结构 (JCA) 进行 J2EE 应用服务器集成
* 使用 Java 管理扩展 (JMX) 进行审计、监视和管理
* 灾难和例程故障恢复模式
* 基于超时的死锁检测
* 冷热备份、日志文件压缩和完整的数据库转储

3. 易于部署
Berkeley DB Java 版是高度可移植的、非常灵活且易于集成。它从一开始就被设计为一个充分利用 Java 环境的纯 Java 产品。作为单个 Java 存档 (JAR) 文件，它在运行您应用程序的 JVM 中运行。Berkeley DB Java 版旨在通过企业级、纯 Java 的数据存储解决方案为不断增长的大型 Java 社区提供服务。

* 100% 的纯 Java，便于移植且易于开发
* 单个 JAR 文件 – 易于安装，与应用程序运行在相同的 JVM 上
* 需要 Java 1.4.2 或更高的标准版 JVM
* 编程管理
* 无需人为管理
* 针对例行管理功能的 API
* 体积小 820KB
* 可扩展到数以 TB 计的数据，数百万条记录
* 包含源代码、测试套件

性能比较：JE vs Derby

正如一份关于JE和Derby的性能比较的Oracle白皮书(http://www.oracle.com/technology/products/berkeley-db/pdf/je-derby-performance.pdf)展示的那样： 在相同的硬件平台，JE只使用了相当于Derby一半的内存却达到了近乎于数量级的性能提升！

尾记

Oracle Berkeley DB Java 版的体系结构对于读密集型和写密集型的工作负载支持非常高的性能和并发性。有鉴于其良好的伸缩性，和易于部署性，JE成功应用到上至全球型的电子商务网站，下至终端设备。同时，由于其开源和双重licence特性，对于广大Java爱好者和数据库工程人员而言也是不可多得的参考宝典。

—
黄超