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

概述

当选择一个数据库时，其性能的好坏往往是我们要考虑的第一关键因素。本白皮书介绍了一些性能测定的方法，旨在帮助你理解从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

在处理大量数据时，也许你曾经面对这样的需求：

1.  查询某个时间的所有记录或者一段时间的记录；

2.  查询开通了增值业务的所有客户；

3.  查询最热门的搜索关键字；

4.  删除在某日开户的所有客户信息；

5.  更新在某网点的名称，并更新所有客户数据等等。

在上述场景中，需要对大量数据做相同的操作。如果逐条记录处理，那么频繁函数调用会消耗掉大量的计算资源，并且该方案可能不是最优的。为了有效地提高上述场景的性能，Berkeley DB 5.1（下文简称BDB）开始提供面向C，Java和C#语言的批量操作API（具体包括批量查询，更新和删除），一次即可批量返回满足需要的数据记录。

备注：

1.  BDB 3.3及以上版本支持批量查询， 4.8及以上版本支持批量更新和删除；BDB 4.8以上版本支持Java API批量查询、删除和更新。BDB 4.8及以上支持C# API批量查询，5.1及以上版本支持批量删除和更新。

2.  使用批量操作，不需要特别的编译选项。

3.  BDB SQL目前尚不支持上述批量操作。

本文将以C API为例，简要地介绍批量查询、更新和删除的原理和使用方法，并提供一个批量查询的范例。对于Java和C#用户，使用方法与C API类似，在此就不详细介绍，请参考相关文档。

（二）概述

传统的BDB是非关系型（NoSQL）数据库，每一条记录分为键值（key）和数据项（value），所有非键值的属性都存放在数据项中。BDB SQL扩展了SQL解析，使用SQL语法管理BDB数据库，目前BDB SQL尚未支持批量操作。

BDB批量操作和逐条操作的最大不同是使用缓冲区来存取输入、输出数据集。当使用批量操作时，应用程序通过记录设置缓冲区，来存取批量操作的数据集。针对不同的操作类型，缓冲区可能仅存键值，或仅存数据项，或二者皆存。例如，若查询某键值的所有数据项，则需要使用一个缓冲区，返回一定数量的数据项。

根据缓冲区是否既存键值又存数据项，BDB的批量操作分为两种模式，DB_MULTIPLE模式和DB_MULTIPLE_KEY模式。在DB_MULTIPLE的模式下，任一缓冲区只存键值或数据项。如果需要操作批量键值及其数据项，则应用程序需要为键值和数据项分别提供各自的缓冲区，且两个缓冲区里的键值和数据项一一对应。在DB_MULTIPLE_KEY模式下，应用程序仅需要提供一个缓冲区，以操作于批量记录（包括其键值和数据项）。

由于应用程序需要根据具体场合设置合理的缓冲区大小，从而达到最好的性能。下文将根据不同的操作，具体阐述缓冲区的使用，以便开发者更清晰地使用和理解BDB批量操作。

（三）批量查询

批量查询可以用来查询一个键值对应的所有数据项或者连续键值对应的所有数据项，并将查询结果分批返回到缓冲区。例如，查询某帐户的所有交易记录，假设每条交易记录长度是100字节，设置一个1024字节大小的缓冲区，每次数据库可以读取满足条件的10条记录到该缓冲区；处理完该批记录后，BDB可继续提取下一批的10条记录，直到处理完所有满足条件的记录为止。

目前BDB批量查询仅支持查询连续的数据记录。若需要查询不连续的数据记录，可以在应用程序层面做一些处理，尽可能对连续的或者相邻的记录一块做查询。
批量查询通过调用以下接口实现:
-   DB->get(DB *db,DB_TXN *txnid, DBT *key, DBT *data, u_int32_t flags)
-   DBcursor->get(DBC *DBcursor, DBT *key, DBT *data, u_int32_t flags);

根据用户提供的键值或者游标所在位置，返回该键值对应的数据项，或者游标所在位置后一定数量的数据集。在调用的接口函数中，用于返回批量结果的DBT的data域指向应用程序提供的可用缓冲区，ulen域为缓冲区大小，flags域为DB_DBT_USERMEM。
在批量查询中,DB->get()支持DB_MULTIPLE模式，而DBC->get()可以同时支持DB_MULTIPLE和DB_MULTIPLE_KEY模式。

使用不同的模式和访问方法，得到的缓冲格式不尽相同。由于应用程序需要从缓冲中依次读出每一个数据项，因此，在此将更详尽地介绍一下各种缓冲格式和读取数据项的方法。

1.  DB_MULTIPLE模式下得到的只含批量数据项或者只含批量键值的缓冲：

Img 1 DB_MULTIPLE 缓冲

读取该缓冲中的每一个数据项的过程如下：
-       DB_MULTIPLE_INIT初始化读指针；
-       DB_MULTIPLE_NEXT依次读出每一个数据项。

2.  DB_MULTIPLE_KEY模式下得到的是一个含批量键值和数据项的缓冲：

1)   当数据库为BTree或者Hash时，

Img 2 DB_MULTIPLE_KEY 非recno 缓冲

读取该缓冲中的每一个键值和数据项的过程如下：
-       DB_MULTIPLE_INIT初始化读指针；
-       DB_MULTIPLE_KEY_NEXT依次读出每一条记录，并获得其键值和数据项。

2)  当数据库为Recno或者Queue时候，

Img 3 DB_MULTIPLE_KEY recno缓冲

读取该缓冲中的每一个键值和数据项的过程如下：
-      DB_MULTIPLE_INIT初始化读指针；
-      DB_MULTIPLE_RECNO_NEXT依次读出每一个记录，并获得其recno和数据项。

BDB批量查询的一个重要应用是：实现分页技术。当查询连续记录，若每条记录长度稳定，选择合适的缓冲大小，可使当前分页结果即是每次返回到缓冲的记录。若记录长度不一时，可计算当前分页的最后一个键值，并保留其后的记录，待下一次批量查询时，并到下一个分页中。当数据量较大，亦可将结果暂存在一个临时内存数据库中。

本文将在第六部分具体介绍一个批量查询的实例。

（四）批量更新

批量更新将不同的键值和数据项一一写入给定缓冲区，并调用DB->put()写接口，批量写入或者更新这些数据记录。DB->put()支持DB_MULTIPLE和DB_MULTIPLE_KEY两种模式的批量更新。

1.  DB_MULTIPLE模式

DB->put()中的key和data分别指向两个不同的缓冲，前者存储批量键值，后者存储相同数量的批量数据项。缓冲的组装过程与访问控制相关。

1)  在BTree和Hash数据库中，缓冲组装过程如下：
-       DB_MULTIPLE_WRITE_INIT分别初始化key和data的DBT；
-       DB_MULTIPLE_WRITE_NEXT依次将每条记录的键值和数据项分别写入key和data。两个缓冲的格式与img 1相同。

2)  在Queue和Recno数据库中，缓冲组装过程如下
-       DB_MULTIPLE_RECNO_WRITE_INIT分别初始化key和data的DBT；
-       DB_MULTIPLE_RECNO_WRITE_NEXT依次将每条记录的recno和数据项分别写入key和data。存放数据项的缓冲的格式与img 1相同，存放键值的缓冲的格式如下所示：

Img 4 DB_MULTIPLE_KEY recno的键值缓冲

2.  DB_MULTIPLE_KEY模式

DB->put()中的key指向一个缓冲，该缓冲存储了成对的键值和数据项，而data为空。在BTree和Hash数据库中，缓冲的格式与Img 2相同。在Queue和Recno数据库中，缓冲的格式与Img 3相同。

（五）批量删除

批量删除调用DB->del()接口，删除指定键值的所有记录，或者指定键值和数据项的所有记录。若删除二级索引中的记录，主数据库中的记录亦会被相应的删除。在逻辑上，成功的批量删除操作相当于循环地根据每一个键值或每一对键值/数据项删除其相应的记录。

DB->del()支持DB_MULTIPLE和DB_MULTIPLE_KEY两种模式。

1.  DB_MULTIPLE模式
同批量更新中的DB_MULTIPLE模式类似，将一系列键值组装到key指定的缓冲中，并调用DB->del()，删除这些键值对应的一条或者多条记录。

2.  DB_MULTIPLE_KEY模式
同批量更新中的DB_MULTIPLE_KEY模式类似，将一系列键值和其数据项组装到key指定的缓冲中，并调用DB->del()，删除这些键值和数据项所在的记录。

（六）运行示例程序

在BDB发布包中的<db-x.y.z>/examples/c/ex_bulk.c演示了批量查询，更新和删除操作。这里将提供BTree数据库中批量查询的代码片段，并通过代码注释进行讲解。

本文将提供BTree数据库中批量查询的片段。


DBC *dbcp;
DBT key, data;
size_t retklen, retdlen;
char *retkey, *retdata;
int ret, t_ret;
void *p;

memset(&key, 0, sizeof(key));
memset(&data, 0, sizeof(data));

/* 分配5MB的缓冲空间 */
#define BUFFER_LENGTH (5 * 1024 * 1024)
if ((data.data = malloc(BUFFER_LENGTH)) == NULL)
return (errno);
data.ulen = BUFFER_LENGTH;
data.flags = DB_DBT_USERMEM;

if ((t_ret = dbcp->c_close(dbcp)) != 0) {
dbp->err(dbp, ret, "DBcursor->close");
if (ret == 0)
ret = t_ret;
}
free(data.data);


(七) 总结

从上文可以看出，BDB通过引入缓冲区的技术实现了批量查询、批量更新和批量删除操作。事实证明，在大多数情况下可以获得明显的性能提升和减少磁盘IO的次数。当然，缓冲区大小的设置根据各个应用场合会不同，如何保证性能的同时兼顾缓冲区的大小是需要测试来获得的。

关于BDB的批量操作更详尽的信息，请参考文档：

• http://download.oracle.com/docs/cd/E17076_02/html/programmer_reference/am_misc_bulk.html
• http://download.oracle.com/docs/cd/E17076_02/html/api_reference/C/dbt.html

关于BDB的更详尽的信息，请参考文档：

• BDB：http://download.oracle.com/docs/cd/E17076_02/html/
• BDB中文博客：http://www.bdbchina.com/
• BDB微博：http://weibo.com/bdbchina

ADO.NET是微软在.NET Framework中负责数据访问的类库集，它是使用在COM时代奠基的OLE DB技术以及.NET Framework的类库和编程语言来发展的，它可以让.NET上的任何编程语言能够连接并访问关系数据库与非数据库型数据源（例如XML，Excel或是文字档数据），或是独立出来作为处理应用程序数据的类对象，其在.NET Framework中的地位是举足轻重，许多人将ADO.NET视为ADO的下一个版本，但其实它是一个全新的架构、产品与概念。

DBSQL ADO.NET包是一个针对Windows ADO.NET用户发布的独立包，已包含DBSQL所需的源代码和文件。ADO.NET用户可直接用它来编译生成基于Berkeley DB引擎的ADO.NET库。

用户可在Oracle Berkeley DB的官方网站下载以下文件：

• Berkeley DB dbsql-adodotnet-5.2.28.zip, for ADO.NET (12M)

下文将详细介绍在Windows和Windows Mobile环境下的编译使用过程：

1. 环境需求

如果你的环境没有满足以下要求，相对应的工程是无法编译通过的：

• System.Data.SQLite.Linq 需要 .Net Framework 3.5 SP1.
• SQLite.Designer需要Microsoft Visual Studio SDK.

如果你不需要以上两个组件，可忽略相应的系统需求。

2. Windows

以Windows XP 32bit Visual Studio 2008为例:

打开SQLite.NET.2008.sln，如果遇到对话框询问加载方式，选择“正常加载项目”。

选择编译方式为ReleaseNative, Win32

编译整个项目。

测试生成的库：右键选择test.2008, 调试，启动新实例。点击“Run”，运行整个测试集。这些内置的ADO.NET测试同时也是很好的范例。

3. Windows Mobile

以下仍以Windows XP 32bit Visual Studio 2008为例。首先，要安装Windows Mobile 6.5.3 DTK (Developer Tool Kit) 在这里下载。

打开SQLite.NET.2008.WinCE.sln，如果遇到对话框询问加载方式，选择“正常加载项目”

然后，在”Mixed Platforms”所在的下拉菜单中选择“配置管理器”，然后如下图所示新建一个平台：

编译选项选择ReleaseNativeOnly, 然后编译整个工程。

编译通过后，将SQLite.Interop.2008.WinCE布署到Windows Mobile仿真器上：
右键选择SQLite.Interop.2008.WinCE, 属性->部署->远程目录
按需定义部署目录。这里为了方便演示下面的测试，将目录设定为：
%CSIDL_PROGRAM_FILES%\testce

确定保存后，再次右键选择SQLite.Interop.2008.WinCE，选择部署。稍等一会后，当VisualStudio输出窗口显示以下内容，表明仿真器已经启动
========== 部署: 成功1 个，失败0 个，跳过0 个==========

同样的部署System.Data.SQLite.Compact.2008, 按下图所示选择仿真器

右键选择testce.2008, 调试，启动新实例。如上图选择仿真器。测试集会自动运行，这些内置的ADO.NET测试同时也是很好的范例。运行结果如下所示(在仿真器中可用方向键对结果翻页)：

4. 结束语

以上介绍了DBSQL ADO.NET发布包的编译使用过程。你可以在发布包的根目录下找到具体的官方文档。如果在使用过程中有任何问题，欢迎和我交流！

BDB Blog：http://www.bdbchina.com/
BDB微博：http://weibo.com/bdbchina
个人微博：http://weibo.com/2153755234

Android默认提供的数据库功能是SQLite。Berkeley DBSQL完全兼容SQLite API，可以直接替换SQLite库而无需改动现有的应用程序或服务。依本方法编译得到的Berkeley DBSQL库将完全替换Android的SQLite库(drop-in模式)。在这种模式下，Android平台上所有的应用程序(包括我们自己编译的应用程序)都将链接到Berkeley DBSQL库以获取更高的存储和并发性能。

完整原文：http://download.oracle.com/docs/cd/E17076_02/html/installation/build_android_intro.html

中文介绍：

Android编译过程

本节提供了Berkeley DB Drop-in方式的Android编译指令。

首先要下载并且编译Android源代码树。
第一次编译过程需要花费较长一段时间，不过后面再编译就快多了。可以从这里下载Android的源代码并且按照Android文档完成编译过程。

把Berkeley DB代码目录拷到Android的代码目录里面：

$ cd ${root}/external/sqlite/dist
$ tar zxvf db-xx.tar.gz

这里的${root}指的是Android源代码树的根路径。

通过以下命令将源代码树中默认的Android.mk文件替换成Berkeley DB的版本：

$ cd ${root}/external/sqlite/dist
$ mv Android.mk Android.mk.sqlite
$ cp db-xx/build_android/Android.mk ./

提示：编译之前，可通过这里查看Android平台上的几种调优参数。

重新编译数据库部分，这样Berkeley DB就替换到最终生成的系统镜像了：

$ cd ${root}
$ . build/envsetup.sh
$ make clean-libsqlite
$ mmm -B external/sqlite/dist
$ make snod

以上指令完成后，新的基于Berkeley DB SQL的Android系统镜像即编译完毕。系统会打印出新的镜像所在目录，一般来说这个目录是：${root}/out/target/product/generic。

从SQLite迁移到Berkeley DB

如果你需要使DBSQL能够自动打开并转换现有的SQLite数据库文件，请参照本节的步骤。

首先，我们需要通过以下脚本来为Android平台编译一个静态的SQLite shell, 这个shell对自动转换功能而言是必需的。

#!/bin/bash
# This script shows how to use built-in toolchain to build
# sqlite3 shell, which is required by Berkeley DB SQL
# on-the-fly migration feature.

# Note: these variables should be set per active Android source tree
# We assume $PWD=$ROOT/external/sqlite/dist
ROOT=${PWD}/../../..
TOOLCHAIN=${ROOT}/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0
CC=${TOOLCHAIN}/bin/arm-eabi-gcc
LIB="${ROOT}/out/target/product/generic/obj/lib"
INCLUDE="${ROOT}/ndk/build/platforms/android-8/arch-arm/usr/include"

# CFLAGS should be set per Android.mk.sqlite (the original
# version of SQLite's Android.mk)
CFLAGS="-DHAVE_USLEEP=1 -DSQLITE_THREADSAFE=1 -DNDEBUG=1 \
 -DSQLITE_DEFAULT_JOURNAL_SIZE_LIMIT=1048576 \
 -DSQLITE_ENABLE_MEMORY_MANAGEMENT=1 \
 -DSQLITE_DEFAULT_AUTOVACUUM=1 \
 -DSQLITE_TEMP_STORE=3 -DSQLITE_ENABLE_FTS3 \
 -DSQLITE_ENABLE_FTS3_BACKWARDS -DTHREADSAFE=1"
CFLAGS="${CFLAGS} -I${INCLUDE}"

LDFLAGS="-ldl -nostdlib -Wl,--gc-sections -lc -llog -lgcc \
 -Wl,--no-undefined,-z,nocopyreloc ${LIB}/crtend_android.o \
 ${LIB}/crtbegin_dynamic.o -L${LIB} -Wl,-rpath,${LIB}"

${CC} -DANDROID -DOS_ANDROID --sysroot="${SYSROOT}" -mandroid \
      -fvisibility=hidden -ffunction-sections -fdata-sections \
      -fPIC ${LDFLAGS} ${CFLAGS} \
      sqlite3.c shell.c -o sqlite3orig

提示：你可能需要根据当前环境来修改以上环境变量。

运行以上脚本，成功的话我们就得到了一个静态的sqlite3 shell工具 – sqlite3orig

接下来我们需要修改系统image文件。首先用xyaffs2工具解压镜像文件

$ xyaffs2 ./system.img system

把编译好的sqlite3工具拷进去。

$ cp ${root}/external/sqlite/dist/sqlite3orig system/xbin/sqlite3orig

使用mkyaffs2image工具来重新生成system.img.

$ mkyaffs2image -f $PWD/system system.img

这样，修改好的系统镜像即可自动转换并打开现成的SQLite3数据库文件。需要注意的是：在adb shell模式下，打开sqlite3数据库的命令是sqlite3orig；而打开Berkeley DBSQL数据库的命令是sqlite3。

结束语

以上介绍了DBSQL Android平台上Drop-in模式的编译使用过程。如果你在使用过程中有任何问题，欢迎和我交流！

BDB Blog：http://www.bdbchina.com
BDB微博：http://weibo.com/bdbchina
个人微博：http://weibo.com/2153755234

本文将从“使用Heap的目的”， “一个可能的应用场合”， “如何使用Heap AM”及它的“示例程序（ex_heap）介绍”几个方面展开阐述。

使用Heap AM的目的

在通常的OLTP应用中，频繁的插入和删除操作会带来很多额外的空间维护的开销。引入Heap AM的主要目的是，更好地重用磁盘空间，减少或者降低这部分开销。

当向Heap数据库增加一条新的记录时，它会从Heap数据库文件的起始页进行遍历以找到第一个有充足空间的页，并把这条记录写入该页中。这种插入方式使得Heap AM能够充分地利用数据库中每个页的空间，并能很好地控制数据库文件的过快增长。假设说，如果你的应用程序需要不断地对数据库进行等量插入和删除操作时（即，首先往数据库中插入一些记录，接着再删除相当数量的记录），Heap的数据库文件大小基本会保持一致。倘若，你使用其它AM, 例如BTree的话，由于BTree在插入一条记录时，是根据该记录的键值的排列顺序来决定该把记录放到哪个页中，所以BTree的数据库文件会比Heap的数据库文件在相同条件下增长得快些。

同时，你的应用程序还可以通过调用DB->set_heapsize()来显式地指定你的Heap数据库文件的物理大小。当达到指定大小后若继续增加记录，Heap 则会溢出并抛出DB_HEAP_FULL异常。

因此，相对其他的四种AM来说，Heap AM的一个很重要的优势是磁盘空间的复用。

一个可能的应用场合

Heap AM的加入主要源于行业中对于使用数据库做缓存的需求。通常来说，企业需要寻求一个方法能够使Berkeley DB运行在多台具有相同配置的机器上，并无须考虑BDB运行过程中磁盘空间的消耗情况。然而，如果仅仅是将Btree数据库中“老化”的记录（你可以理解为cache中不常访问的数据）驱除出去并不能立即释放可重用的空间，你还必须定期的进行数据库整理（compact）以释放空间。而整理操作通常都代价昂贵。Heap的访问方法避免了数据库整理的需要。它通常使用在一些运行在磁盘空间受限的应用程序中。

如何使用Heap AM

目前， Heap还不支API DB->set_partition()，因此一个heap数据库中的所有的记录仅仅被保存在一个Heap数据库文件中。每条记录通过其所在的位置进行访问。在一个Heap数据库中，键值是用来存储记录号（record id），其结构为<页号：索引>，即由该记录对应的数据值（data）所在页的页号（page）和其在页中的索引（index）2部分组成，并在第一次插入时被确定。

具体来讲，使用Heap访问方法仅仅涉及到以下几个步骤。
1) 在DB->open中使用DB_HEAP标志，以说明你的数据库将使用Heap访问方法。由于记录号具有唯一性，因此Heap数据库不支持DB_DUP或DB_DUPSORT。

if ((ret =
    dbp->open(dbp, NULL, dbname, NULL, DB_HEAP, DB_CREATE, 0)) != 0){
        dbenv->err(dbenv, ret, "DB->open");
        return (ret);
}

2) 当插入新的记录时，使用DB->put(…, DBT *key, DBT *data, …); 并需要指定标志DB_APPEND。此时，

key（键值）是一个空的记录号<页号：索引>，它将在该记录插入完成后被自动赋值。
data（数据值），也就是你的应用存储将要存储的那条记录。

DB_HEAP_RID rid;
DBT key, data;
char buf[BUFFER_LEN];
int cnt, ret;

memset(&rid, 0, sizeof(DB_HEAP_RID));
memset(&key, 0, sizeof(DBT));
memset(&data, 0, sizeof(DBT));

ret = 0;

key.data = &rid;
key.size = key.ulen = sizeof(DB_HEAP_RID);
key.flags = DB_DBT_USERMEM;
data.data = buf;
data.flags = DB_DBT_USERMEM;

for (cnt = start; cnt < (numrecs + start) && (ret =
    generate_data(buf, cnt, test_var)) == 0; ++cnt) {
        data.size = data.ulen = (u_int32_t)strlen(buf) + 1;
        /* Require DB_APPEND flag to add new data to the database.*/
        if ((ret =  dbp->put(dbp, NULL, &key, &data, DB_APPEND)) != 0) {
            dbenv->err(dbenv, ret, "insert_heap:DB->put");
	    break;
        }
}

3) 使用DB->set_heapsize(DB *dbp, u_int32_t gbytes, u_int32_t bytes); 来显式指定数据库文件的物理大小。此时，将创建一个大小为gbytes千兆+ bytes字节的Heap AM数据库文件。

if ((ret = dbp->set_heapsize(dbp, ghpsize, hpsize, 0)) != 0) {
	dbenv->err(dbenv, ret, "DB->set_heapsize");
	return (ret);
}

示例程序（ex_heap）介绍

在新发布的Berkeley DB 5.2 中，由我负责添加了一个关于Heap AM的例子，名为ex_heap。你可以在<db-5.2-XX>/examples/c目录下找到ex_heap.c的文件，那个就是了。

ex_heap不仅演示了如何在BDB中使用Heap AM创建数据库，还比较Heap AM和BTree在存储数据方面的性能不同，例如在插入或删除过程中对应的数据库文件大小以及时间的变化。

ex_heap首先创建一个使用Heap作为访问方法的数据库，并初始化一定数量的记录。接下来进行至少2个轮回的插入和删除操作，即在每个轮回中，先插入一定数量的记录，接着删除相等数目的记录，同时记录每轮操作需要的时间及数据库文件大小的变化。

有兴趣用户可以从BDB下载页面下载最新的BDB5.2版本来体验下ex_heap, 解压后就可以使用了（为方便引用，记${BDB_HOME}为Berkeley DB源代码的根目录）。下面分别简要介绍下在Windows和Linux平台下如何编译ex_heap。

• Windows平台下编译ex_heap：

在Windows下，编译ex_heap比较简单，只须用Visual Studio 2005/2008打开
${BDB_HOME}/build_windows/Berkeley_DB.sln（或者使用Visual Studio 2010打开${BDB_HOME}/build_windows/Berkeley_DB_vs2010.sln），找到ex_heap的项目直接编译即可。如下图所示：

• Linux平台下编译ex_heap：

首先需要编译出BDB 5.2的库，然后再编译ex_heap, 具体步骤如下所示：

$ cd ${BDB_HOME}/build_unix
$ ../dist/configure
$ make
$ make ex_heap

使用ex_heap时，要求指定数据库环境所在的目录，同时ex_heap也提供很多额外的配置功能，比如，允许和BTree进行比较、允许指定cache的大小、使用定长还是变长数据做为输入、指定Heap AM数据库大小等等。可以用如下命令得到所有可配置信息：

${BDB_HOME}/build_unix$ ./ex_heap

具体可配置信息：

usage: ex_heap:
[-b][-c cachesize][-d] -h home [-n recs_per_rep]
[-p pgsize][-r repeats][-S ghpsize][-s hpsize]
-b: run sample application using a btree database.
-c: specify the cache size for the environment.
-d: test on variable-length data (default: fix-length).
-h: specify the home directory for the environment (required).
-n: specify the num. of records per repetition (default: 10000).
-p: specify the pgsize of database.
-r: number of repetition (a pair of insertion and deletion (default: 1).
-S: specify the heap size (gbytes) for the heap database.
-s: specify the heap size (bytes) for the heap database.

比如我们使用以下命令来运行ex_heap：

${BDB_HOME}/build_unix$./ex_heap -h exHeap -b -d -n 100000 -p 4096 -r 10 -s 4000000

该命令中“-h exHeap”指定exHeap为环境目录，标志“-b”允许Heap AM和BTree在数据库文件增长方面和插入删除操作上性能的比较（不指定“-b”的话， 只考虑Heap AM在以上2方面的情况），标志“-d”表明在程序中使用可变长的记录进行插入删除操作（默认为固定长度的记录）， 标志“-n 100000”表明在每一个插入或删除操作中使用100000个记录，标志“-p 4096”指定数据库中的页大小为4096字节，标志“-r 10”指定在此次应用程序运行过程中进行10个轮回的插入删除操作，标志“-s 4000000”指定Heap数据库文件大小为4000000字节。

运行程序之后，输出的内容为：

======================================================
About to enter the insert phase.
Database type: Heap     with configured heapsize = 0 gbytes and 4000000          bytes.
Pagesize: 4096
Initial records number: 10000
Number of repetitions: 10
Number of inserts per repetition: 100000

------------------------------------------------------
repetition       physical file size      running time
0                356352              0.01 seconds
1               3796992              0.30 seconds
2               4001792              0.29 seconds
3               4001792              0.29 seconds
4               4001792              0.29 seconds
5               4001792              0.29 seconds
6               4001792              0.30 seconds
7               4001792              0.29 seconds
8               4001792              0.29 seconds
9               4001792              0.29 seconds
10               4001792              0.30 seconds

======================================================
About to enter the insert phase.
Database type: Btree
Pagesize: 4096
Initial records number: 10000
Number of repetitions: 10
Number of inserts per repetition: 100000

------------------------------------------------------
repetition       physical file size      running time
0                458752              0.02 seconds
1               4984832              0.49 seconds
2               4993024              0.49 seconds
3               4988928              0.49 seconds
4               4993024              0.49 seconds
5               4988928              0.49 seconds
6               4988928              0.49 seconds
7               4993024              0.48 seconds
8               4988928              0.48 seconds
9               4984832              0.49 seconds
10               4984832              0.49 seconds

从输出结果的对比可以看出，在相同的配置下，Heap AM不仅在时间开销上比BTree更有优势，而且只占用更小的数据库空间（文件大小）。

结束语

如果您有任何问题，欢迎给我们的博客或者BerkeleyDB的新浪微博留言，也欢迎通过OTN论坛提问。

BDB中文博客：www.bdbchina.com
Oracle BDB 官方论坛：http://forums.oracle.com/forums/category.jspa?categoryID=246
BDB新浪微博：http://weibo.com/bdbchina
个人新浪微博：http://weibo.com/redsuncmx

1. 什么是Vacuum

一个数据库在进行多次写操作(增,删,改)后，就会攒下一些碎片，即填充率非常低的页面(page)或是空白页面。这些页面占用了不少空间，却仅存储了少量数据。Vacuum的作用好比Windows下的磁盘碎片整理，即依次扫描数据库的数据页面，将数据搬移得更加紧凑，腾出空白页并且删除之，缩减数据库大小。Berkeley DB SQL(以下简称DBSQL)支持在线Vacuum(对一个正在运行的数据库进行操作)。你可以把它想像成扫描重排页面数据的写进程，这个进程可以和其它的所有OLDP操作并行执行。

在使用Vacuum时需要清楚以下要点：
- 整理数据碎片，回收文件系统空间，提升查询性能。
- 频繁操作会影响当前主业务性能。因此在DBSQL 5.2版本中，针对这一问题实现了增量Vacuum。用户可手动控制Vacuum操作涉及的数据块大小。
- 如果数据库被压得过紧，空闲空间不足，那么插入新数据时数据库需要频繁分配新页面，影响了操作性能。因此在DBSQL 5.2版本中，针对这一问题引入了Fill Percent参数。用户可手动控制Vacuum时的页面填充率。

以下具体介绍Berkeley DB SQL (以下简称DBSQL) 5.2版本中Vacuum功能的使用方法：

2. 使用Vacuum功能

2.1 基本Vacuum命令
基本的Vacuum命令是对全数据库进行Vacuum。直接在SQL语句或者SHELL里面执行”VACUUM”指令，即完成一次基本Vacuum：

• VACUUM;

当数据库较大时，一次Vacuum将会耗费较多的时间，影响数据库的正常业务响应时间。此外，全数据库Vacuum是放在一个事务里面完成的，在资源受限的情况下，有可能无法一次完成对整个数据库的操作。

2.2 增量Vacuum
BDB 5.2实现了增量Vacuum。所谓增量，即每次Vacuum仅操作一小部分数据块，下一次再从上次结束的地方继续操作，如此反复进行，就可以完成整个数据库的Vacuum，同时也不会对主业务有明显影响。比如说 在一天中操作频率较低的时间段(夜间)，可以启动一个并行的维护程序，在数据库业务正常运行的同时，周期性地调用增量Vaccum来回收空间。

要使用增量Vacuum，需要先设定每次操作回收的最大页数(默认值为128页)。命令为：

• PRAGMA bdbsql_vacuum_pages [=N]

此参数用于获得或者设定一次增量Vacuum操作的最大回收页数。当回收的页数大于该值时候，当前增量Vacuum完成并退出。如果未设定N，返回当前的最大回收页数。

设定了该参数后，我们有两种方式来使用增量Vacuum:

• 1. 手动
  这种方式可以自由地控制Vacuum的频率和时机，也是推荐的方法。使用办法：首先调用”PRAGMA auto_vacuum=INCREMENTAL”来置为手动增量Vacuum模式，然后在程序中即可调用”PRAGMA incremental_vacuum(N)”来执行一次增量vacuum。
• 2. 自动
  在自动模式下，DBSQL在提交事务后会自动执行一次增量Vacuum。这种方式的好处是不需要额外的程序控制，但如果事务提交非常频繁，会带来额外的负担。使用办法：调用”PRAGMA auto_vacuum=FULL”来设置数据库为自动增量Vacuum模式。

在数据库运行过程中，可用以上指令在手动和自动模式间切换。

2.3 Fill Percent
在DBSQL 5.2中我们引入了一个新的Vacuum参数：页面填充率。用法:

• PRAGMA bdbsql_vacuum_fillpercent [=N]

此参数用于获得或者设置预期的数据库页面填充率。所有DBSQL Vacuum模式均受此参数控制。N为填充率百分比(1~100)，当N被设定时，DBSQL Vacuum会以N为目标重排数据库页。当N未被设定时，返回当前设定的页填充率(默认值为85).

Vacuum操作包括两方面：

• 1. 数据页重排
  只有当页填充率百分比低于N时，DBSQL才会重排该页，将其它页面的数据挪到未使用的空间，使其填充率尽可能地接近目标值。被搬空的页面就成了新的空白页。
• 2. 空白页回收
  统一将空白页挪到文件末端，删除空白页并截短数据库文件。

Fill Percent参数的引入，丰富了用户Vacuum操作的手段。在不同情况下用户可以选择不同的Fill Percent参数来精细化操作。典型的应用:

• 对于一个正在工作的数据库，用一个非常低的Fill Percent值(比如1)来快速回收数据库中已存在的空页。因为这种情况下不存在页内数据搬移，数据库仅仅将现有的空页交换到尾部并截短，不会对现有数据加锁，速度会非常快。
• 对于一个处于关闭状态的数据库，用一个较高的Fill Percent值来尽可能地回收空间。

这里有一个问题：假设用户设定目标Fill Percent值为80(%)，每条数据约占15%的空间。那么重排后该页应该存储5条数据(75%，更接近于目标值)还是6条数据(90%，更大填充率)呢。这是一个设计上的权衡选择。关于这一点，我们经过内部讨论后选择了前者。即令填充率接近于目标值，而不是尽可能地大。”Some applications want room to add data on the page, others want the pages packed as densely as possible”。在BDB开发者看来，页里面的数据和空闲空间都是重要的。合理的空闲空间可以让新数据利用现有的空闲空间，使得数据插入更加快速。

4. 范例

以下面是新Vacuum功能的范例片段，该程序实现了对指定数据库的循环增量Vaccum。

void vacuum()
{
	sqlite3 *db;
	char sql[4096];
	struct timeval t1, t2, t_begin;
	int rc, i;

	sqlite3_open(db_name, &db);
	error_handler(db);

	/* 设置为手动增量Vacuum模式 */
	exec_sql(db, "PRAGMA auto_vacuum=INCREMENTAL;", 1);

	/* 每次增量Vacuum最多回收256页 */
	exec_sql(db, "PRAGMA bdbsql_vacuum_pages=256;", 1);

	/*目标页填充率为75% */
	exec_sql(db, "PRAGMA bdbsql_vacuum_fillpercent=75;", 1);

	/*循环做40次增量Vacuum */
	for (i = 0; i < 40; i++) {
		exec_sql(db, "PRAGMA incremental_vacuum;", 1);
		if (rc = sqlite3_errcode(db)) {
			fprintf(stderr, "[vacuum] ERROR: %s. ERRCODE: %d.n",
				sqlite3_errmsg(db), rc);
		}

		/* 获得数据库文件大小 */
		get_filesize(db_name);

		/* 睡眠一小段时间以减轻Vacuum对数据库的IO压力 */
		sqlite3_sleep(100);
	}

	cleanup(db);
}

5. 结束语

以上我们介绍了5.2 Vacuum的新功能并给出了一个范例。欢迎继续关注!

官方资料：Auto Vacuum, Incremental Vacuum, Vacuum Fillpercent, Vacuum pages

BDB Blog：www.bdbchina.com
BDB微博：http://weibo.com/bdbchina
个人微博：http://weibo.com/2153755234

从上世纪80年代第一个版本诞生至今，BDB一直扮演着嵌入式数据库领域领头羊的角色。由于具备了强大的性能，极度的易用性和良好的稳定性，BDB成为这个世界上最受欢迎的嵌入式数据库，并被广泛应用于从路由器到浏览器到操作系统等等计算机系统的方方面面之中,为用户带来了巨大的价值。下面，就让我们一起来揭开Berkeley DB 5.2.28（以下简称BDB5.2）的神秘面纱，看看这个最新版本的BDB将为开发者带来了哪些激动人心的新特性。

【新的访问方法 (Heap Access Method)】

在保留原有的btree，hash， recno和queue这四种访问方法的基础上，BDB5.2新增了heap 访问方法。Heap 访问方法通过复用删除数据所释放的空间，将数据库的大小控制在一个限定的范围内，有效的提高了空间利用率。它适用于存储容量受限的设备或对数据库文件大小有严格限制的环境，以及插入密集型的应用程序。比如可用来做中间服务器的静态图片缓存。

【动态资源管理 (Dynamic Resource Management)】

BDB5.2中，开发者无需再显式指定每种系统资源（如lock，locker等）的上限并在程序开始时一次性分配；BDB5.2将在程序运行过程中动态分配这些资源。资源的分配将根据实际的使用情况动态增长。

【扩展的高可用性 (SQL support for HA/replication) 】

BDB5.2为SQL接口也增加高可用性支持。开发者可以在多个节点上通过SQL HA来构建一个数据库集群，从而扩展了计算能力。

【扩展的Sequence (SQL support for Sequence)】

BDB5.2的SQL 接口引入了Sequence的支持，允许用户使用SQL语句生成序列， 并提供事务保护。

【灵活的高可用性管理 (Group Membership) 】

BDB5.2引入了新的组管理机制，允许用户动态地向组(Replication Group)里添加或者删除结点。系统将自动调整和维护组的大小。

【新增的db_tuner工具 (db_tuner)】

BDB5.2新增了一个db_tuner工具，可以辅助用户选择合适的page size，提升程序的性能。

除此之外，秉承我们一贯的为用户提供最高性能，最灵活的嵌入式数据库的理念，最新的BDB5.2 还修正了上一个版本中存在的各种问题，并对原有的多项功能进行了增强。更多详情，参见这里。

您可以通过 BDB下载页面下载并体验最新的BDB5.2. 如果您有任何问题，欢迎通过我们的博客或者BerkeleyDB的新浪微博留言，也欢迎通过邮件联系我们。

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!