我们知道kafka使用内存Map文件作为索引文件，但是它的日志文件不使用内存Map文件技术。我的问题是为什么索引文件使用内存Map文件，而日志文件不使用？
5fjcxozz1#
在只附加写的数据库中，使用快速索引来提高读性能是一种常见的优化方法（几乎所有lstm数据库都会这样做）。也正如其他人所指出的：索引是稀疏的，所以内存占用更小。即使索引的稀疏性也是可配置的，这在数据增长时也很有用。只附加写模式比随机寻道更快（对于ssd尤其如此），因此在优化时不需要太多注意。
a0zr77ik2#
可以Map到内存中的字节数与地址空间有关。例如，32位体系结构只能处理4gb甚至更小的文件部分。Kafka日志通常足够大，可能一次只Map部分，因此使读取变得复杂。但是，索引文件是稀疏的，这意味着它们的大小相对较小。将它们Map到内存可以加快查找过程，这是内存Map文件提供的主要好处。
fdbelqdn3#
日志是存储消息的地方，索引文件指向日志中的位置。有一个很好的，丰富多彩的博客文章，解释是怎么回事。
4xy9mtcn4#
用mmap方法实现日志和索引并置会带来数据一致性问题。mmap不能100%保证将数据从内存刷新到文件（假设操作系统上的flush应答而不是显式调用munmap（2）），如果索引更新被刷新，但是由于某种原因日志数据没有被成功刷新，那么日志中的数据就不能再被理解了。顺便说一句，对于一个只追加的数据，在写的方向上，我们只需要关心下一个写块（buffer），所以庞大的数据应该不会影响这一点。
4条答案
按热度按时间5fjcxozz1#
在只附加写的数据库中，使用快速索引来提高读性能是一种常见的优化方法（几乎所有lstm数据库都会这样做）。也正如其他人所指出的：
索引是稀疏的，所以内存占用更小。即使索引的稀疏性也是可配置的，这在数据增长时也很有用。
只附加写模式比随机寻道更快（对于ssd尤其如此），因此在优化时不需要太多注意。
a0zr77ik2#
可以Map到内存中的字节数与地址空间有关。例如，32位体系结构只能处理4gb甚至更小的文件部分。Kafka日志通常足够大，可能一次只Map部分，因此使读取变得复杂。
但是，索引文件是稀疏的，这意味着它们的大小相对较小。将它们Map到内存可以加快查找过程，这是内存Map文件提供的主要好处。
fdbelqdn3#
日志是存储消息的地方，索引文件指向日志中的位置。
有一个很好的，丰富多彩的博客文章，解释是怎么回事。
4xy9mtcn4#
用mmap方法实现日志和索引并置会带来数据一致性问题。mmap不能100%保证将数据从内存刷新到文件（假设操作系统上的flush应答而不是显式调用munmap（2）），如果索引更新被刷新，但是由于某种原因日志数据没有被成功刷新，那么日志中的数据就不能再被理解了。
顺便说一句，对于一个只追加的数据，在写的方向上，我们只需要关心下一个写块（buffer），所以庞大的数据应该不会影响这一点。