那谁 — Sun, 10 Jan 2010 02:22:00 GMT

开始正式的研究key-value形式的持久化存储�Ҏ��了，�W�一个阅�ȝ��目是tokyo cabinet�Q�版本号�?.4.19.

tokyo cabinet支持几种数据库�Ş式，包括hash数据库，B+树数据库�Q�fix-length数据库，table数据库。目前我仅看了第一�U�hash数据库的实现。之所以选择�q�个�Q�是因�ؓ�W�一�q�种�c�d��的数据库��g��是TC中��用的最多的一�U�，其次它的��法比之B+树又更简单一些而效率上的表��C��丝毫不差�?br>
看看TC中代码的�l�织。关于上面几个分�cȝ��数据库实玎ͼ�实际上在TC��目的代码组�l�中各自以单个文件的形式出现�Q�比如hash数据库的代码全都集中�?tchdb.c/h中，也只不过4000多行�|�了。除去这几种数据库的实现文�g�Q�其余的代码文�g功能可以大体上分��Z��c�，一�c�L��辅助性质的代码，�l�项目中各个部分使用上的�Q�另一部分��是单独的管理数据库的CLI�E�序的代码，比如tchmgr.c/h��是用于��理HASH数据库的CLI�E�序的代码。之所以要交代一下项目中代码的组�l�，无非是�ؓ了说明，其实如果��问题集中在HASH数据库或者其他�Ş式的数据库实��C��Q��v码在TC中，所要关注的代码是不多的�?br>
首先来看数据库文件是如何�l�织的�?br>
从图中可以看刎ͼ�hash数据库文件大致分为四个部分：数据库文件头�Q�bucket 数组�Q�free pool数组�Q�最后的是真正存放record的部分。下面对�q�几部分做一个说明�?br>
1�Q�数据库文�g�?br>数据库文件头部分存放的是关于该数据库的一些��M��信息�Q�包括这些内容：

name	offset	length	feature
magic number	0	32	identification of the database. Begins with "ToKyO CaBiNeT"
database type	32	1	hash (0x01) / B+ tree (0x02) / fixed-length (0x03) / table (0x04)
additional flags	33	1	logical union of open (1<<0) and fatal (1<<1)
alignment power	34	1	the alignment size, by power of 2
free block pool power	35	1	the number of elements in the free block pool, by power of 2
options	36	1	logical union of large (1<<0), Deflate (1<<1), BZIP2 (1<<2), TCBS (1<<3), extra codec (1<<4)
bucket number	40	8	the number of elements of the bucket array
record number	48	8	the number of records in the database
file size	56	8	the file size of the database
first record	64	8	the offset of the first record
opaque region	128	128	users can use this region arbitrarily

需要说明的是，上面�q�个表格来自tokyocabinet的官�Ҏ��档说明，�?a >�q�里。同�Ӟ��数据库文件中需要存放数据的地方�Q��用的都是��端方式存放的，以下��׃��再就�q�点做说明了。从上面的表格可以看出，数据库文件头的尺��ؓ256 bytes�?br>在操作hash数据库的所有API中，都会用到一个对象类型�ؓTCHDB的指针，该结构体中存攄��信息��包括了所有数据库文�g头的内容�Q�所以每�ơ在打开或者创��Z��个hash数据库的时候，都会��数据库文�g头信息读入到�q�个指针中（函数tchdbloadmeta�Q��?br>
2�Q�bucket 数组
bucket array中的每个元素都是一个整敎ͼ�按照使用的是32位还�?4位系�l�，存放的也��是32位或�?4位的整数。这个数�l�存攄��q�个整数��|��是每次�?key �q�行hash之后得到的hash值所对应的第一个元素在数据库文件中的偏�U�量�?br>
3�Q�free pool数组
free pool数组中的每个元素定义�l�构体如下：

typedef struct {                         // type of structure for a free block
  uint64_t off;                          // offset of the block
  uint32_t rsiz;                         // size of the block
} HDBFB;

很明显，仅有两个成员�Q�一个存攄��是在数据库文件中的偏�U�量�Q�一个则是该free block的尺寸。free pool数组用于保存那些被删除的记录信息�Q�以便于回收利用�q�些数据区，后箋会针对free pool相关的操作，API做一个详�l�的分析�?br>
4�Q�record数据�?br>每个record数据区的�l�构如下表：

name	offset	length	feature
magic number	0	1	identification of record block. always 0xC8
hash value	1	1	the hash value to decide the path of the hash chain
left chain	2	4	the alignment quotient of the destination of the left chain
right chain	6	4	the alignment quotient of the destination of the right chain
padding size	10	2	the size of the padding
key size	12	vary	the size of the key
value size	vary	vary	the size of the value
key	vary	vary	the data of the key
value	vary	vary	the data of the value
padding	vary	vary	useless data

当然�Q�上面这个结构只是该record被��用时的结构图�Q�当某一��record被删除时�Q�它的结构就变�ؓ�Q?br>

name	offset	length	feature
magic number	0	1	identification of record block. always 0xB0
block size	1	4	size of the block

�Ҏ��两种情况�Q�首先是最开始的magic number是不同的�Q�当magic number�?XB0也就是该record是已�l�被删除的free record�Ӟ��那么紧跟着�?个字节存攄��是�q�个free record的尺寸，而record后面的部分可以忽略不计了�?br>
分析完了hash数据库文件的几个�l�成部分�Q�从最开始的数据库文件示意图中还看到�Q�从文�g头到bucket array�q�一部分��通过mmap映射到系�l�的�׃�n内存中，当然�Q�可以映��的内容可能不止到这里，但是�Q�数据库文�g�?bucket array�q�两部分是一定要映射到共享内存中的，也就是说�Q�hash数据库中映射到共享内存中的内容上限没有限�Ӟ��但是下限是文件头+bucket array部分�?br>
同时�Q�free pool也会通过malloc分配一个堆上的内存�Q�存攑ֈ�TCHDB的fbpool指针中�?br>
�q�几部分�Q�除了record zone�Q�，通过不同的方式都分别的读取到内存中，目的��是��Z��加快查找的速度�Q�后面会详细的进行说明�?br>

那谁 2010-01-10 10:22 发表评论