rocksdb-doc-cn

迭代器

一致性视图

如果ReadOptions.snapshot被给出,那么迭代器会从一个快照里面返回数据。如果这是一个nullptr,迭代器隐式创建一个迭代器创建的时间节点的快照。该隐式快照会通过固定资源来提供数据。隐式快照无法转换为显式快照。

错误处理

Iterator::status()会返回迭代过程中的错误。错误包括IO错误,校验和错误,不支持的操作,内部错误,或者其他错误。

如果没有错误,会返回Status::OK()。如果不是OK,迭代器会马上失效。换句话说,如果Iterator::Valid()为true,status()会被保证为OK(),所以你不检查status也是可以的:

for (it->Seek("hello"); it->Valid(); it->Next()) {
  // Do something with it->key() and it->value().
}
if (!it->status().ok()) {
  // Handle error. it->status().ToString() contains error message.
}

换句话说,如果Iterator::Valid()为false,有两种可能:(1)我们已经读完所有数据了。这个时候,status()是OK();(2)确实出错了。这种情况下,status()不会是OK()。在迭代器失效的时候检查一下status是非常好的习惯。

Seek()和SeekForPrev()会丢弃之前的状态。

注意,在5.13.x和之前的版本(在2018年5月17日合并的PR之前),status()和Valid()的行为是有所不同的:

迭代边界

你可以通过在调用NewIterator的时候,给传入的option设定ReadOptions.iterate_upper_bound来为你的迭代范围设置一个上边界。通过这个设定,RocksDB就不用继续查找这个key之后的内容了。在一些情况下,可以节省一些IO和计算。在特定的工作载荷下,它带来的改善是显著的。这个选项可以同在正向和反向迭代。

同理 ReadOptions.iterate_lower_bound 也可以给反向迭代提高性能

参考该选项的注释以了解更多内容。

迭代器使用的资源以及迭代器更新

迭代器自身并不怎么使用内存,但是他会阻止一些资源释放。包括:

所以使用迭代器最好是短期使用,这样资源可以被正确释放。

迭代器在构建的时候会有一些花销。在一些应用场景(特别是纯内存的场景),人们可能会希望通过重用迭代器来减少构建的开销。如果你也这么做,请记住,迭代器是可能过期的,他会阻止一些资源的释放。所以请一定要记得在他们一段时间(例如,1秒钟)没有使用后销毁,或者更新他们。如果你希望处理这个过期的迭代器,在5.7版本前,你只能销毁,然后重建这个迭代器。5.7版本之后,你可以使用接口Iterator::Refresh()来更新他。通过这个函数,迭代器会更新到当前的数据状态,过期的资源会被清理。

(笔者注) 长时间的执行iterator占用的内存非常可观,如果有内存监控,是可以看到内存波涌的

前缀迭代

前缀迭代允许用户在迭代中使用bloom filter或者哈希索引,以此来改善性能。然而,这个功能有一定限制,而且,如果你误用他们,他还会返回错误的结果而不报任何错误。我们希望你使用这个功能的时候小心谨慎。更多关于这个功能的内容,参考 前缀迭代。选项total_order_seek和prefix_same_as_start只在前缀迭代过程中有用。

预读取

迭代过程中,如果注意到同一个表文件有需要被读2次以上IO的数据,rocksDB会自动预读,预取数据。预读的大小从8KB开始,然后会在每次额外的顺序IO之后指数增长,最大增长到256KB( BlockBasedTableOptions.max_auto_readahead_size)。这可以帮助减少完成一个区间扫描的IO数量。这个自动预读只有在ReadOptions.readahead_size = 0(默认值)的时候开启(从5.12开始,迭代器自动预读功能可以用于带缓冲的文件IO,5.15开始可用于无缓冲文件IO)

如果是Direct IO 用AlignedBuffer存

如果你的整个应用都是不断迭代,而你又依赖OS的页缓存(例如,使用带缓冲的文件IO),你可以选择通过设置DBOptions.advise_random_on_open = false手动打开预读取。你如果使用硬盘或者远程存储的时候会更加有用,但是如果是挂载在本地的SSD设备,效果就不明显了。

ReadOptions.readahead_size为RocksDB的一些非常特定的使用场景提供预读功能。他的局限就是,如果这个功能打开了,构建迭代器的开销会大很多。所以,只在你需要迭代相当大量的数据、而且又没有其他更好的办法的时候,你才应该打开它。一个典型的场景就是,存储介质是远程存储,并且延迟比较大,OS的页缓存不可用,然后又有大量数据需要扫描的时候。通过打开这个功能,每次SST文件的读都会根据这个设定进行预读取。注意,一个迭代器可能会在每一层都打开一个文件,同时也会打开L0的所有文件。你需要为你的预读准备足够的内存。而且预读的内存无法被自动追踪。

如果设置了ReadOptions.async_io,可以不阻塞iterate同时prefetch 我们还在尝试改善RocksDB的预读取。

看到这里或许你有建议或者疑问或者指出错误,请留言评论! 多谢! 你的评论非常重要!也可以帮忙点赞收藏转发!多谢支持! 觉得写的不错那就给点吧, 在线乞讨 微信转账