加载中…
正文 字体大小:

关于LevelDB

(2011-11-10 09:24:24)
标签:

杂谈

1)关于max_open_files

   LevelDB的默认打开文件数为1000,低于linux默认的1024最大文件打开数。

   在完成插入记录做库时,前3亿条插入都非常快速,后面则非常龟速,如果你把默认打开文件调大到10000,则做库完数据(总共7亿数据)不可查,返回Corruption: partial record without end错误,全库作废,无法使用。(这个bug是在ulimit -n 65535的情况下,即系统支持的最大打开文件数远大于10000).

   结论:慎用options.max_open_files这个option选项。可能有bug。

 

2)还是max_open_files

   如果插入的记录非常多,LevelDB会吃满1000个文件句柄的份额,还有其他系统进程需要文件句柄,因此,如果在你的程序中在插入到一定记录量时(1000个文件句柄用尽时),整个系统可用文件句柄也耗尽,如果此时程序要打开其他文件就会报错,因此必须把系统最大打开文件数调大,而leveldb在运行时默认系统有足够多的文件句柄。

    另外要指出,如果你在正常情况下ulimit -n 65535情况下做库(比如有9000个sst),并且能查到记录,如果再ulimit -n 1024一下,则整个库废掉,不能查询,这个太诡异,应该属于明显bug。

    结论:用LevelDB时ulimit -a一下,看看你机器上最大文件打开数,如果是1024,没有调过的,就直接调到65535吧。因为ulimit -n是只对当前batch有效,所以要调的彻底,在bashrc里面加上,ulimit -HSn 65535这一条。

 

3)sst文件的大小

   LevelDB的sst文件大小默认是2M起,如果想入库时把这个搞大,只需要把options.write_buffer_size搞大,比如options.write_buffer_size = 100000000。这样一上来sst就是32M起。大规模数据入库,速度会快到惊人,有多快呢,把我的THUIRDB也打败了(在7亿数据量插入的情况下)。

   结论:write_buffer可以调大,可以让写的次数降低,写的强度提高

 

4)batch写入

   LevelDB加快写操作还可以用batch写入的方式,我尝试了用4096个记录打一个batch写入,从sst文件看,是直接将这个batch看做一个整体插入的,如果你有40960条记录,4096个记录打一个batch,其实对于leveldb只看到10次真正的插入,这每次插入的数据都是明文可见的,vim一个sst就能看到。

   结论:多大batch为好,要根据实验,有batch可以加快做库过程

 

以上是我的一些经验,在一个7.2亿条记录插入的数据集上获得,数据集17GB,key是一个在1-73字节的变长的且符合正态分布的string,value是6-11字节的一个变长string,记录下来,仅供朋友们参考。

 

0

阅读 评论 收藏 转载 喜欢 打印举报
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 电话:4006900000 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有