C++博客-那谁的技术博客-随笔分类-tokyo cabinet

C++博客-那谁的技术博客-随笔分类-tokyo cabinethttp://www.cppblog.com/converse/category/12481.html感兴趣领域:高性能服务器编程,存储,算法,Linux内核zh-cnTue, 26 Jan 2010 20:20:43 GMTTue, 26 Jan 2010 20:20:43 GMT60tokyocabinet1.4.19阅读笔记（五）hash数据库插入数据流程http://www.cppblog.com/converse/archive/2010/01/25/106425.html那谁那谁Mon, 25 Jan 2010 15:21:00 GMThttp://www.cppblog.com/converse/archive/2010/01/25/106425.htmlhttp://www.cppblog.com/converse/comments/106425.htmlhttp://www.cppblog.com/converse/archive/2010/01/25/106425.html#Feedback0http://www.cppblog.com/converse/comments/commentRss/106425.htmlhttp://www.cppblog.com/converse/services/trackbacks/106425.html阅读全文

那谁 2010-01-25 23:21 发表评论

]]>tokyocabinet1.4.19阅读笔记（四）hash数据库freepool的组织与管理http://www.cppblog.com/converse/archive/2010/01/22/106249.html那谁那谁Fri, 22 Jan 2010 14:38:00 GMThttp://www.cppblog.com/converse/archive/2010/01/22/106249.htmlhttp://www.cppblog.com/converse/comments/106249.htmlhttp://www.cppblog.com/converse/archive/2010/01/22/106249.html#Feedback1http://www.cppblog.com/converse/comments/commentRss/106249.htmlhttp://www.cppblog.com/converse/services/trackbacks/106249.html在第一节中已经提到,这一个部分,在初始化的时候会全部读入采用malloc从堆中分配的内存中,所以对它的大部分操作都是直接在内存中进行的---除了要同步到数据库文件中时.

所有的freepool,以数组形式组织在一起,每个freepool元素结构体的定义是:

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

可见,每个freepool关注的仅有两个因素:所保存block在数据库文件中的offset,以及这块block的尺寸.

当需要插入新的记录时,需要在当前的freepool中进行查询,看有没有适合的freepool可以回收利用,因此需要根据尺寸进行查询,所以为了提高查询速率,freepool数组中的元素是根据每个freepool的尺寸进行排序的,这样根据尺寸进行查找时就可以采用二分查找提高效率了,但是要注意到可能出现的找到的尺寸不符合要求,过大了(大于所需尺寸的一倍以上),这个时候会将这块freepool进行拆分,一部分给予使用,剩余的回收到freepool中.另外,如果在freepool中查找所需尺寸出现了很多次失败的情况(一旦失败表示没有符合要求的freepool可以回收利用,这时就需要增加数据库文件大小以加入新的记录了),就需要对freepool进行一次合并操作,将相邻的freepool合并起来形成尽可能大的freepool,而判断是否相邻的依据就是根据在数据库文件中的offset,此时又会将所有的freepool根据offset进行一次排序,然后再进行前面的合并操作.

以上就是freepool数组的大体组织情况,因为它保存在内存里面的,而且会经常有更新,那么就会出现当前的freepool与数据库文件中保存的freepool情况不一致的可能,所以在关闭/拷贝数据库的时候还要将内存中的freepool信息一次性的同步到数据库文件中,但是我注意到,在数据库运行期间是没有这个同步操作的,所以,一旦数据库被非法关闭,那么数据库文件中里面的freepool信息将完全的错乱,我想这也是TC不够安全的一个佐证吧.

下面简单的介绍TC hash数据库中与freepool相关的API:
1)static bool tchdbsavefbp(TCHDB *hdb)
将当前内存中freepool数组信息同步到数据库文件中,仅当关闭/拷贝数据库时被调用.

2) static bool tchdbloadfbp(TCHDB *hdb)
加载数据库文件中的freepool信息到内存中,与tchdbsavefbp 是两个互逆的过程.

3) static void tcfbpsortbyoff(HDBFB *fbpool, int fbpnum)
根据offset对freepool数组进行排序

4) static void tcfbpsortbyrsiz(HDBFB *fbpool, int fbpnum)
根据size对freepool数组进行排序

5) static void tchdbfbpmerge(TCHDB *hdb)
将地址相邻的freepool进行合并,内部实现中首先会调用tcfbpsortbyoff 对freepool根据offset进行排序,这样才方便合并操作.

6) static void tchdbfbpinsert(TCHDB *hdb, uint64_t off, uint32_t rsiz)
将一块block插入到合适的freepool中,插入之前和插入之后freepool数组都是根据size排序好的.

7) static bool tchdbfbpsearch(TCHDB *hdb, TCHREC *rec)
根据rec所要求的尺寸,查找一块合适的freepool回收利用,如果找到的freepool过大(大于所要求的一倍),那么就分为两份,一份负责插入rec,一份重新插入到合适的freepool中.

8) static bool tchdbfbpsplice(TCHDB *hdb, TCHREC *rec, uint32_t nsiz)
查看紧跟着rec的数据库文件空间是否是空闲的,如果是就合并进来,也就是加大rec的尺寸,以满足nsiz大小的要求.

9) static bool tchdbwritefb(TCHDB *hdb, uint64_t off, uint32_t rsiz)
将一块block置位空闲的(就是写它的magic number为0xb0)

总体来看,freepool是TC hash数据库中操作很频繁的一块数据区,在删除一条记录时需要将这条记录放到合适的freepool中,而新增记录时还需要从当前的freepool中查找合适的block,但是由于freepool是保存在内存中的,而且又进行过排序因此可以使用二分查找算法,所以对它进行的管理操作还是较为高效的.

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

]]>tokyocabinet1.4.19阅读笔记（三）hash数据库删除数据流程http://www.cppblog.com/converse/archive/2010/01/19/105898.html那谁那谁Tue, 19 Jan 2010 13:18:00 GMThttp://www.cppblog.com/converse/archive/2010/01/19/105898.htmlhttp://www.cppblog.com/converse/comments/105898.htmlhttp://www.cppblog.com/converse/archive/2010/01/19/105898.html#Feedback4http://www.cppblog.com/converse/comments/commentRss/105898.htmlhttp://www.cppblog.com/converse/services/trackbacks/105898.html
先来看这个过程的流程图，其实很简单，包括以下几个按部就班的步骤：

a) 首先，根据key查找对应的记录，这个在上一节已经完整的介绍过了，当时也提到，查找操作是后续进行删除和插入新数据时的基础。
如果没有找到记录，说明原来就没有，那么就不必继续下去了。
假设现在找到了所要删除的数据，接着以下几步：
b) 将该记录的magic number置为0xb0，第一节讲解hash数据库概述的时候提到过，每条记录的头部信息中有两种不同magic number，根据这个判断一条记录是否被删除了，现在将这个magic number置为0xb0就是表示这条记录已经被删除了。
c) 将这条被删除的记录插入到free pool数组中的合适位置，这是下一节的重点，这里先知道这个操作就好。
d) 上一节提到过，同一个bucket index是以二叉树形式组织在一起的，虽然不是平衡的二叉树，但是删除了一个数据之后会破坏二叉树的性质，所以需要在二叉树中找到合适的记录来替换删除这条记录之后剩下的位置。
熟悉数据结构与算法的都知道，一个排序二叉树如果按照中序遍历的话，那么是有序的。所以要在删除一个记录之后仍然保持排序二叉树的有序性，是删除操作的重点，下面就是TC中删除一个记录时的调整算法：

if rec.left is not null and rec.right is null
    child = rec.left
else if rec.left is null and rec.right is not null
    child = rec.right
else if rec.left is null and rec.right is null
    child = null
else
    child = rec.left
    right = rec.right
   rec.right = child
    while (rec.right is not null)
        rec = rec.right

    rec.right = right

replace rec's original place with child

也可以从下图中来理解当删除一个记录时，它的左右子节点都不为空时的处理：

从图中可以看出，当所要删除的节点左右子节点都不为空时，会去寻找左子树中的最右边的子节点，然后将待删除记录的右子树变成这个最右子节点的右子树。

需要注意到的是，经典的数据结构算法中，当在排序二叉树中删除一个节点之后，所做的调整与上面的流程有所不同，虽然也是找到的原记录的左子树的最右节点，但是是将这个最右节点直接替换掉原来记录的位置，也就是如下图：

所以，这里出现了一个新的问题，TC中的调整算法是有可能导致删除记录之后二叉树不平衡的，那么为什么不选用第二种方法呢？
我的理解是：
1）如前一节所述，TC中的二叉树本来就不是必然平衡的，所以TC中的这种调整算法有可能会有“负负得正”的结果。
2）第二种经典的做法中，需要的调整包括：a）将最右子节点从原来的父节点上删除 b）最右子节点要替换原记录的位置，那么要将原记录的左右子树分别赋值变为最右子节点的左右子树。上面的这个调整，每次调整都是需要修改节点的，而每次修改都会有对磁盘的I/O操作。
而第一种做法呢，仅需要一次修改操作-----将原记录的右子树变成最右子节点的右子树即可。

综合这几个因素，TC选择了I/O较少的做法。
我不清楚我的理解是否合理，欢迎补充。

e）删除了记录，也跳整了树的结构之后，最后的工作就是更新数据库文件header的信息---因为当前记录少了一条。

最后分析一下整个删除操作的最坏复杂度，还是以1G的bucket对16G的数据库文件记录为例：
1）首先查找元素，前面一节说了，需要O(4)次磁盘I/O+O(1)读取内存
2）接着置所删除记录的magic number，一次磁盘I/O
3）将删除插入到合适的free pool位置，这个下一节会提到，是在内存中进行的。
4）调整树结构，在所删除记录左右子树都存在的情况下，首先要找到最右子节点，这又是一个O(4)的磁盘I/O操作，最后将原记录的右子树赋值给最右子节点，又是一次磁盘I/O。不过，上面这个推断与前面是有矛盾的，假如在第一步查找中已经需要O(4)的代价才能定位到所删除元素了，那么最后的这个调整根本没有必要了。

那谁 2010-01-19 21:18 发表评论

]]>tokyocabinet1.4.19阅读笔记（二）hash数据库查找key流程http://www.cppblog.com/converse/archive/2010/01/12/105500.html那谁那谁Tue, 12 Jan 2010 11:25:00 GMThttp://www.cppblog.com/converse/archive/2010/01/12/105500.htmlhttp://www.cppblog.com/converse/comments/105500.htmlhttp://www.cppblog.com/converse/archive/2010/01/12/105500.html#Feedback2http://www.cppblog.com/converse/comments/commentRss/105500.htmlhttp://www.cppblog.com/converse/services/trackbacks/105500.html
从上一节的概述中,可以看到record结构体中有两个成员left,right:

typedef struct {                         // type of structure for a record
  uint64_t off;                          // offset of the record
  uint32_t rsiz;                         // size of the whole record
  uint8_t magic;                         // magic number
  uint8_t hash;                          // second hash value
  uint64_t left;                         // offset of the left child record
  uint64_t right;                        // offset of the right child record
  uint32_t ksiz;                         // size of the key
  uint32_t vsiz;                         // size of the value
  uint16_t psiz;                         // size of the padding
  const char *kbuf;                      // pointer to the key
  const char *vbuf;                      // pointer to the value
  uint64_t boff;                         // offset of the body
  char *bbuf;                            // buffer of the body
} TCHREC;

说明,每个record是存放在一个类二叉树的结构中的.

实际上,TC会首先根据一个record的key去算出该key所在的bucket index以及hash index,代码如下:

/* Get the bucket index of a record.
   `hdb' specifies the hash database object.
   `kbuf' specifies the pointer to the region of the key.
   `ksiz' specifies the size of the region of the key.
   `hp' specifies the pointer to the variable into which the second hash value is assigned.
   The return value is the bucket index. */
static uint64_t tchdbbidx(TCHDB *hdb, const char *kbuf, int ksiz, uint8_t *hp){
  assert(hdb && kbuf && ksiz >= 0 && hp);
  uint64_t idx = 19780211;
  uint32_t hash = 751;
  const char *rp = kbuf + ksiz;
  while(ksiz--){
    idx = idx * 37 + *(uint8_t *)kbuf++;
    hash = (hash * 31) ^ *(uint8_t *)--rp;
  }
  *hp = hash;
  return idx % hdb->bnum;
}

需要特别提醒的一点是,上面的算法中,根据key算出所在的bucket index,是经过模TCHDB->bnum之后的结果,也就是说,这个值是有限制的---最大不能超过TCHDB初始化时得到的bucket最大数量;而算出的二级hash值,我是没有看出来有数值上的限制的,为什么?看了后面的内容就明白了.

因此,所有根据记录的key算出bucket index相同的记录全都以二叉树的形式组织起来,而每个bucket array元素存放的整型值就是该bucket树根所在记录的offset.

到此,相关的结构体联系都清楚了,下面的流程图给出了查找一个key的记录是否存在的流程:

简单的解释一下,这个查找的流程就是首先根据查找的key算出所在的bucket,然后在这个bucket的二叉树中按照条件遍历的过程.

前面提到过,bucket array是整个被mmap映射到共享内存中去的.我们来做一个估计,假设存放bucket array的内存使用了1G,而真正存放record的文件长度有16G,也就是,bucket array的元素与记录大概是1:16的关系,假设所选的hash算法足够的好,以至于每个记录的key可以较为平均的分布在不同的bucket index上,也就是每个bucket array的元素组成的二叉树上平均有16个元素,那么也就最多需要O(4)次读取文件I/O(每次去读取记录的数据都是一次读磁盘操作) + O(1)次内存读操作(因为需要在bucket array中得到树根元素的offset).

但是等等,上面还有一些细节没有交待清楚.

首先,上面的二叉树不是类似AVL,红黑树这样的平衡二叉查找树,也就是说,很可能在极端的情况下演变成一个链表---树的一边没有元素,另一边有全部的元素.
其次,上面的流程图中还有一点就是每次比较首先比较的是hash值,这个值的奥秘就在于解决上面提到的那个问题.既然只是一个普通的二叉树,无法保证平衡,那么就通过算出这个二级的hash值来保证平衡---当然,前提依然是所选择的hash算法足够的好,可以保证key平均的分布.

前面提到过,非平衡的二叉树只会在极端的情况下才会演变为一个极端不平衡的二叉树--链表,而诸如AVL,红黑树之类的平衡二叉树,算法编码都相对复杂,调试起来也麻烦,出错了要跟进更麻烦,另外还别忘了,这些平衡二叉树之所以能保持平衡,在删除/增加元素时做的让树重新平衡的操作,比如旋转等,都是要涉及到读写树结点的,而这些,目前都是存放在磁盘上的---也就是这是相对较费时的操作,所以问题在于:是不是值得为这一个极端的情况去优化?另外,引入二级hash就是为了部分解决这个极端不平衡问题,它的思路简单也容易实现,但是引入的另外一个问题就是每次查找时根据key去算bucket index的时候,还要耗费时间去算hash index了.

平衡点,还是平衡点.时间还是空间,这是一个问题.

所以,经过对TC的hash数据库查找key流程的分析,最大的感受是:它没有使用复杂的算法与数据结构,而是通过一些巧妙的优化如二级hash的引入,达到了系统效率和编码调试复杂度之间一个较好的平衡.学会"平衡"各种因素,是做项目做事情,都要掌握的一个技能,而这个,只有多经历多想才能慢慢积累了.

好了,简单的回顾整个查找key的关键点:
1) 所有的record是以二叉树的形式组织在同一个bucket上面的.
2) 这个二叉树不是平衡的二叉树
3) 为了解决问题二造成的极端不平衡问题,TC引入了二级hash,以保证这个二叉树尽可能的平衡.

以上,就是TC对记录,bucket的组织情况,以及整个查找算法的流程.可以看到,算法,结构体定义等等都不复杂,但是由于巧妙的构思,既可以使用尽可能简单的算法/数据结构,又能规避可能出现的一些隐患,同时还能保证查找的高效率.

查找是key-value形式存储的核心流程,能够将这个流程优化,对整个系统的性能也有很大的影响.

那谁 2010-01-12 19:25 发表评论

]]>这是tokyo cabinet的一个BUG么http://www.cppblog.com/converse/archive/2009/12/03/102493.html那谁那谁Thu, 03 Dec 2009 14:09:00 GMThttp://www.cppblog.com/converse/archive/2009/12/03/102493.htmlhttp://www.cppblog.com/converse/comments/102493.htmlhttp://www.cppblog.com/converse/archive/2009/12/03/102493.html#Feedback0http://www.cppblog.com/converse/comments/commentRss/102493.htmlhttp://www.cppblog.com/converse/services/trackbacks/102493.html阅读全文

那谁 2009-12-03 22:09 发表评论

]]>