http://blog.sina.com.cn/s/blog_593af2a70100ztjn.html
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，记录下来，仅供朋友们参考。
