Berkeley DB的使用

转自: http://blog.jqian.net/post/berkeley-db.html


Berkeley DB的使用

最近碰到一个项目需要多进程读写一份共享数据,并且共享数据的几个字段需要有倒排索引方便查询,想利用现有数据库快速建立一个原型,于是调研了一下流行的一些nosql数据库。发觉Berkeley DB虽然是一个既古老又流行的开源数据库,但是关于BDB使用的文章却很少,甚至公司DBA对BDB的特性都不太了解……于是花了好几天读了一遍BDB的references和c api,发觉BDB还是个相当复杂的系统。以下对一些常见问题做一个笔记:

数据存储

Berkeley DB的数据存储可以抽象为一张表,其中第一列是key,剩余的n-1列(fields)是value。

BDB访问数据库的方式,或者套用MySQL数据库的说法是存储引擎,有四种:

  • Btree 数据保存在平衡树里,key和value都可以是任意类型,并且可以有duplicated keys
  • Hash 数据保存在散列表里,key和value都可以是任意类型,并且可以有duplicated keys
  • Queue 数据以固定长度的record保存在队列里,key是一个逻辑序号。这种访问方式可以快速在队列尾插入数据,然后从队列头读取数据。它的优点在于可以提供record级别的锁机制,当需要并发访问队列的时候,可以提供很好性能。
  • Recno 这种访问方式类似于Queue,但它可以提供变长的record。

BDB的数据容量是256TB,单个的key或value可以保存4GB数据。

BDB是为并发访问设计的,thread-safe,且良好的支持多进程访问。

少量或者中量数据都建议使用BTREE,尤其并发的场景下,BTREE支持 lock coupling 技术,可以提升并发性能。

BDB组成

Berkeley DB内含多个独立的子系统:

  • Locking subsystem
  • Logging subsystem
  • Memory Pool subsystem
  • Transaction subsystem

一般使用的时候,这些子系统都被整合在DB environment里,但它们也单独拿出来,配合BDB之外的数据结构使用。

所谓DB Environment就是一个目录,其中保存着Locking、Logging、Memory Pool等子系统的信息,不同的thread可以打开同一个目录读写DB environment,BDB通过这种方式实现多进程/线程共享数据库。

【注意】多进程共享一个环境时,必须要使用 DB_SYSTEM_MEM,否则无法正常初始化环境。

关于DB environment的设置很多,一般没必要全部在代码里设置,也可以使用名为 DB_CONFIG 的配置文件来设置,该文件默认位于环境目录。

Concurrent Data Store (CDS)

CDS适用于多读单写的应用场景,当使用CDS的时候,仅需要 DB_INIT_MPOOL | DB_INIT_CDB 这两个子系统,不应该启用任何其他子系统,比如 DB_INIT_LOCKDB_INIT_TXNDB_RECOVER 等。

由于CDS并不启动lock子系统,所以使用CDS无需检查deadlock,但下面的几种情况会导致线程永远阻塞:

  • 混用DB handle和cursor(此时同一thread会有两个locker竞争)。
  • 当打开一个write cursor的时候,在同一个线程里有其他的cursor开启。
  • 不检查BDB的错误码(当一个cursor错误返回时,必须关闭这个cursor)。

其实CDS和DS的唯一区别就在于,当要写db的时候,应该使用DB_WRITECURSOR创建一个write cursor。当这样的write cursor 存在的时候,其他试图创建 write cursor 的线程将被阻塞,直到该 write cursor被关闭。当write cursor存在的时候,read cursor不会被阻塞;但是,所有实际的写操作,包括直接调用DB->put()或者DB->del()都将被阻塞,直到所有的read cursor关闭,才会真正的写入db。这就是multiple-reader/single-writer的具体工作机制。

参考:Berkeley DB 产品对比

CDS中的注意事项

如果使用secondary database,意味着会在同一个cursor下操作两个db,此时如果用CDS,也许必须设置DB_CDB_ALLDB,但这会严重影响性能。

所谓 DB_CDB_ALLDB 是一个非常粗粒度的锁,CDS的锁基于API-layer,默认per-database,但如果设置了DB_CDB_ALL,则是per-environment,这意味着:

  • 整个DB environment下只能有一个write cursor。
  • 当写db的时候,整个DB environment下任何read cursor不可以打开。

读写CDS简单的做法是能用DB handle的地方直接使用DB handle,没有必要使用CURSOR handle,因为你用DB->put()或者DB->del()来修改数据库时,它内部也是调用了CURSOR handle。当然,如果你要使用CURSOR遍历数据库时,用于写的CURSOR必须设置DB_WRITECURSOR来创建:

DB->cursor(db, NULL, &dbc, DB_WRITECURSOR);

直接调用DB->put()或者DB->del(),或者先使用DB_WRITECURSOR创建CURSOR handle,最终都进入__db_cursor()函数,设置db_lockmode_t mode = DB_LOCK_IWRITE,然后用该mode加锁。但需要注意的是,不能在同一thread下混用DB和CURSOR handle,因为每个CURSOR会分配一个LOCKER,而DB handle也会分配一个LOCKER,两者可能导致self-deadlock。

如果在read lock或者write lock过程中,程序崩溃,这可能导致lock遗留在env中无法释放(可以用db_stat -CA观察到),这种情况下该environment已经损坏,只能删除该environment(删除掉__db.001之类的文件即可),重新创建。

Transactional Data Store (TDS)

TDS是使用BDB的终极方式,它适用于多读多写,并且支持Recoveriablity等任何你能想到的常见数据库特性,或者不如说,只有当你确定需要这些特性的时候,你才应该使用BDB;如果你仅仅想要一个单纯的KV系统,那也许BDB并不适合你。

一般来说,创建TDS Environment的flag如下:

DB_CREATE | DB_INIT_MPOOL | DB_INIT_LOCK | DB_INIT_LOG | DB_INIT_TXN

TDS的任何DB相关的操作都必须是事务性的,包括打开db时,都需要先创建txn:

DB_TXN* txn;
int ret = env->txn_begin(env, NULL, &txn, 0);
ret = db->open(db, txn, "test.db", NULL, DB_BTREE, DB_CREATE, 0);
// 如果使用secondary database, 则associate()调用也需要包含在txn里
ret = db->get(db, txn, &key, &val, 0);
ret = db->put(db, txn, &key, &val, 0);
if(ret) txn->abort(txn);
else txn->commit(txn, 0);

如果仅仅有读操作,其实可以无需调用commit,直接abort即可。

如果使用 DB_AUTO_COMMIT 打开db,则关于db handle的操作,不需要额外指定txn参数,此时使用了BDB的autocommit特性。

Write Ahead Logging

WAL是很多事务性数据库使用的技术,即在数据实际写入到数据库文件之前,先记录log,一旦log被写入到log文件,即认为该事务完成(并不会等待数据实际写入到数据库文件)。

这是因为log的写入始终是顺序写到文件末尾的,这比实际数据写入数据库文件(随机写入文件)要快2个数量级。

清理无用log的办法:

  • 使用命令 db_archive -d
  • 调用ENV->set_flags 设置 DB_LOG_AUTOREMOVE

Deadlock

使用TDS时,死锁原则上无法避免:

  • 两个进程互相等待一块被对方锁住的资源则会发生死锁
  • 甚至单一进程内试图获取一个已经被不同locker获取过的lock,也会发生死锁

采用BTREE/HASH访问方式下,并发操作时,无法避免死锁,因为page splits随时可能发生,见图:

死锁检测(原理是遍历wait-for图,发现环;如果有环出现,则打破它):

  • 同步检测 DB_ENV->set_lk_detect(),在每个阻塞的锁上检测,好处是立即发现,坏处是cpu占用略高(insignificant)
  • 异步检测 DN_ENV->lock_detect() 或者 db_deadlock,需要额外发起一个进程或线程,坏处是只有当运行该命令时才能检测,好处是cpu占用低

一般解决死锁的办法:同步检测 + 异步检测 + 设置锁超时

当environment没有被损坏时,可以使用 db_stat -Cl 查看死锁情况。

Degree 2 isolation

degree 2 isolation 保证事务读到已经COMMIT的数据,但是在该读事务结束之前,其他事务可以修改该记录。degree 2 isolation适用于长时间的读取事务,比如遍历数据库等。

使用办法:使用 DB_TXN->txn_begin(), DB->get(), DBC->get() 等函数时,设置参数DB_READ_COMMITTED

区别于degree 3 isolation,后者保证在一个读事务内,无论读取多少遍,都可以读到同样的记录。但这会拒绝该记录的任何写事务。所谓degree 1 isolation则更进一步,可以读取未COMMIT的数据,建议谨慎使用,容易导致数据不一致。

性能调优和参数设置

lock table size

lock table的大小依赖于以下三个参数:

  • lock最大数量:ENV->set_lk_max_locks() 同时可以请求的锁的最大值,比如同时2进程并发,要锁11个对象,则需要2x11个锁。
  • locker最大数量:ENV->set_lk_max_lockers() 同时发起锁请求的最大值,比如同时2进程并发,则最多2个locker。
  • lock object最大数量:ENV->set_lk_max_objects() 同时需要锁住的object的最大值,比如同时2进程并发,如果5层BTREE,则需要锁住2x5=10个对象,此外再加上单独的DB handle。

实际上面的计算得到的最大值还要double,因为如果开启deadlock检测,对每个locker来说BDB会新增一个dd locker,用于检测死锁。

timeout

可以分别设置锁和事务的超时:

  • ENV->set_timeout() 设置锁和事务的默认超时
  • DB_TXN->set_timeout() 单独设置事务的超时

cachesize

使用db_stat查看cache命中情况:

$ db_stat -h var -m
125MB 8KB       Total cache size
1410M   Requested pages found in the cache (99%)
14      Requested pages not found in the cache

建议根据程序设置合理的cachesize,尽量保证所有数据都可以被cache命中。

你是否需要BDB

可以看出BDB比一般的KV数据库还是要复杂很多的,如果你需要如下的一些特性,也许你可以考虑BDB:

  • 期望对value部分也建立索引,比如需要secondary indices,多表之间join
  • 多个进程并发读写数据库(但需要注意的是,在高并发情况下,比如8进程每秒1000读请求几条写请求,你在解决死锁问题上花费的时间也许会让你痛不欲生)
  • 事务性、HA

如果你只需要一个简单有效的KV系统,leveldb也许是一个更好的选择,接口也更 modern 清晰简洁。

如果你只是单thread,那么BDB、sqlite等等,随便用什么都可以。


你可能感兴趣的:(Berkeley DB的使用)