TwinDB

来自开放百科 - 灰狐
(版本间的差异)
跳转到: 导航, 搜索
(简介)
 
第7行: 第7行:
  
 
Put and delete entries are cached in memory until TwinDB_sync() is called or a read occurs (by calling TwinDB_get()). Then, it:
 
Put and delete entries are cached in memory until TwinDB_sync() is called or a read occurs (by calling TwinDB_get()). Then, it:
 
+
*1. locks the first database
  1. locks the first database
+
*2. writes to it
  2. writes to it
+
*3. unlocks it  
  3. unlocks it  
+
  
 
and repeats this process for the backup database. Upon startup, it checks to see if a lock is on either file. If so, it assumes that database file is corrupt and replaces it with the other.
 
and repeats this process for the backup database. Upon startup, it checks to see if a lock is on either file. If so, it assumes that database file is corrupt and replaces it with the other.
  
 
Cons:
 
Cons:
 
+
* writes are 1/2 as fast
    * writes are 1/2 as fast
+
* database is 2x as big  
    * database is 2x as big  
+
  
 
Pros:
 
Pros:
 
+
* the database cannot be corrupted
    * the database cannot be corrupted
+
* it's still *very* fast
    * it's still *very* fast
+
* it's free for commercial use
    * it's free for commercial use
+
* the size difference might not matter (current hard disks are typically over 100G, so a 500M database will still only take up less than 1% of the drive if doubled)
    * the size difference might not matter (current hard disks are typically over 100G, so a 500M database will still only take up less than 1% of the drive if doubled)  
+
  
 
==相关链接==
 
==相关链接==

2010年9月26日 (日) 10:10的最后版本

[编辑] 简介

TwinDB is an embedded key/value database based on BerkeleyDB. It basically adds security from database corruption on top of the non-transactional version of BerkeleyDB. I wrote it because the transactional version of Berkeley DB is expensive ($100,000 for a commercial license).

It accomplishes this by maintaining twin BerkeleyDB databases and using "lock" files to indicate when a set of writes are in progress.

Put and delete entries are cached in memory until TwinDB_sync() is called or a read occurs (by calling TwinDB_get()). Then, it:

  • 1. locks the first database
  • 2. writes to it
  • 3. unlocks it

and repeats this process for the backup database. Upon startup, it checks to see if a lock is on either file. If so, it assumes that database file is corrupt and replaces it with the other.

Cons:

  • writes are 1/2 as fast
  • database is 2x as big

Pros:

  • the database cannot be corrupted
  • it's still *very* fast
  • it's free for commercial use
  • the size difference might not matter (current hard disks are typically over 100G, so a 500M database will still only take up less than 1% of the drive if doubled)

[编辑] 相关链接

分享您的观点
个人工具
名字空间

变换
操作
导航
工具箱