bdb使用心得及问题题材.doc

Bdb回调函数： 假如索引库的键值不是从pkey，pdata中拼接，则需要指明skey-flags = DB_DBT_APPMALLOC; 用户自己malloc一块地址拼接skey，防止bdb插入时候地址失效 索引库关联主库时候，单独查索引库1000/ms 按照索引查主库200/ms 使用共享内存：指明DB_SYSTEM_MEM标志（只生成__db001.db） long shm_key = 38659; ret = _env-set_shm_key(_env, shm_key); int DB_ENV-remove(DB_ENV *dbenv, char *db_home, u_int32_t flags);销毁当前不用的环境。所有与之相关的备份文件及环境区域被删除，而日志文件、数据库文件及环境路径仍然保留。若当前环境仍然在使用，需指定DB_ENV-FORCE标志，所有已经进入该环境区域的进程将照常运行,但新加入该环境的动作将失败。一般情况下，环境将随着数据库恢复的操作被清除，该函数并没有必要。但当打开该环境时启用了DB_SYSTEM_MEM,需要调用该函数释放掉被分配的共享内存段；另外，互斥结构被分配的系统资源也需要调用该函数来释放。在多线程操作中，只允许一个线程来进行该操作。db_home用来指定被销毁环境的路径；若参数3为DB_USE_ENVIRON或DB_USE_ENVIRON_ROOT,说明环境路径使用了BDB File Naming来命名，参3为DB_FORCE的情况只在应用程序无法关闭或者出现死锁的时候出现。 DB_CURSOR: FLAG有参数DB_CURSOR_BULK？ 5. 虽然Berkeley DB的B 树存取方法是一个相当传统的B+树实现，树节点之间的指针用页面号而不是内存指针表示，因为函数也把磁盘页格式用作内存页格式。这种表示的优势在于页面可以不需要格式转换就能被从缓存刷出到磁盘，劣势在于遍历索引结构时需要（代价稍高的）重复的缓冲池查找而不是（代价稍低的）内存操作。 底层假设Berkeley DB索引的内存表示实际上是磁盘上持久数据的缓存，这还有其他的一些对性能的影响。例如，每当Berkeley DB访问一个缓存的页面时，首先要pin住内存中的页面。Pin操作防止任何其他的线程或进程将该页从内存池中换出。即便整个索引结构都可以在缓冲中放下，并且从不需要被刷新到磁盘，Berkeley DB仍然在每个操作时要获取和释放这些pin，因为Mpool底层的模型是一个缓存而不是一个持久存储。 BerkeleyDB的锁叫cds，需要在tie之前在env里设置init_cds，加锁函数为cds_lock，返回一个lock，解锁的时候对这个lock调用方法cds_unlock或者直接undef掉即可 B树的共享栓所谓栓，是指一种资源，类似于mutex，是一种轻量级的锁。在4.7中，访问一个页 的数据时，需要先锁住页(page)，访问完后再释放锁。而在4.8 中，我们提出了的 共享栓的概念，即当多个线程/进程并发访问同一个页的时候，尽量彼此使用共享 的栓，从而避免等待。从我们的在Solaris 10上测试结果来看，如果线程数 = CPU数，4.7的性能下降较多；而使用的共享栓的4.8，速度比同样情况下4.7的提升 25%-16倍左右。当然，具体性能提升指标取决于应用场景和平台。 如果发现二级索引失效了，应该通过调用DB-remove()将其删除，同时，再调用一次DB-associate() 方法来生成新的索引； Berkeley DB多线程支持 原先为了在多线程环境下使用bdb，还专门在调用其API前加线程锁。自己加锁除了多出工作量以外，还有一个麻烦：当一个DB的数据很大时，对它的加锁粒度就太大了，会拖慢性能。后来才发现bdb自己是可以在多线程环境下使用的，只是在DB_ENV初始化时需要加标记：DB_ENV *dbenv;u_int32_t flags; flags | = DB_THREAD; dbenv-open(dbenv, “/home/data/”, flags, 0);在这个DB_ENV下的操作就是线程安全的了，不过还有一点要注意，就是get数据时作为value的DBT需要加DB_DBT_THREAD标记:DBT tKey,tValue;tValue.flags = DB_DBT_MALLOC;...int ret=m_dbp-get(m_dbp,NULL,tKey,tValue,0)