bitcask下文件不到2G就切换了，为什么了？

[Marlon Yao]

rt.

$ ls -lh storage2/f/d/

total 68M

-rw-r--r-- 1 sankuai sankuai  68M Nov 27 17:50 000.data

-rw-r--r-- 1 sankuai sankuai  26K Nov 27 18:13 000.hint.qlz

-rw-r--r-- 1 sankuai sankuai 457K Dec  5 17:43 001.data

-rw-r--r-- 1 sankuai sankuai  241 Dec  5 20:14 001.hint.qlz

什么情况会造成这个现象？

[Marlon Yao]

明白了，每次重启都起一个新的bucket，而bucket数目限制为256，这意味着不能随便重启，这样不太合理吧。

另外，看代码里，hint文件和data文件好像必须是一致，假设hint必须恰好是对整个data文件，而不能只对部分。这样也很不好，这意味着，做备份时只能拷贝data文件，然后重建hint，因为线上可能在不断地写data文件，但重建会花费很长时间。

其实hint可以加上只对部分data文件的hint，这样对于前半部分使用hint，后面的部分直接扫描data，应该并不困难。

[Davies Liu]

重启一般不长发生，所以带来的问题不大。如果使用了200个文件，那数据量会有4T，短时间内应该不容易到这个上线。

如果觉得小文件太多，可以写个简单的脚本合并一下。有大量数据更新的和几次GC的集群会有用，我们内部已经有这样的脚本，下次会发布出去。

hint 文件必须跟data文件一致，它在关闭data文件时生成（或者重建），这样可以简化很多事情。做备份时，用 rsync --append 复制整个目录就可以了，只可能最后一个data文件会缺少 hint，重建也就1分钟左右。

hint 文件跟 data 文件同步写到磁盘也是可以的，你可以稍微改一下试试。

另外，现在内部的最新版会把内存中的索引快照到磁盘，启动会更快，过段时间我会发布出去。

2012/12/6 Marlon Yao <yaol...@gmail.com>

hint

--
 - Davies

[Marlon Yao]

多谢davies大神回复！

我之前以为rsync不可用，是以为它重启之后会写旧文件，这样可能导致data和hint文件不一致。如果每次都写一个新文件，就不会产生不一致了。

刚开始用时还是比较习惯重启的，比如配置不对什么的，导致创建一些小文件总是不爽，重启也总有一些顾虑。不知道豆瓣生产环境中的配置一般是怎样的？比如用线程数，最大并发连接数。

其实有个很容易的优化，仍然只在关闭data文件时生成（或者重建），但hint文件中记录当时data文件的长度。重启时，不是新写一个文件，而是从最后一个data文件的末尾开始写，这样data和hint可能不一致，第一次加载时就需要先读hint，再读剩下的data，实现起来应该不复杂，有空我会尝试一下。

p.s. 期待新的版本发布啊！

[Davies Liu]

豆瓣基本都是使用默认配置，比如 16 线程，最大 1024 连接等。

一个存储短文本的集群使用 -T 1 ， 单磁盘，

另一个存储图片的集群使用 -T 2,  -H /data1,/data2 等单机多磁盘

2012/12/6 Marlon Yao <yaol...@gmail.com>

hint 文件跟 data 文件同步写到磁盘也是可以的，你可以稍微改一下试试。

--
 - Davies