当前的哈希索引实现只需要单个 i/o 进行读取，最多需要 3 个 i/o 进行写入，但我们仍然受到随机 I/O 开销的影响。 平均随机 I/O 需要 20 毫秒，这太慢了。 当前的写入缓存优化分摊了这种开销，但在大量插入的情况下我们仍然会受到影响。 为了避免这种开销，最好对 LSM 尝试进行优化。 简而言之，LSM 树是排序字典，其中一个实例在内存中，第二个在磁盘上，这些实例在后台使用非常大的数据块合并，因此我们将没有 3 个 I/O 用于写入，而是大约 3/16 个 IO对于单次写入，如果我们还考虑到将应用额外的写入缓存优化，我们将有非常非常快的索引实现。 额外的优化是布隆过滤器的使用，但不包括总的服务器资源浪费。
但也很耗费资源，单人4个月，2人2.5个月左右。 但结果应该是非常有价值的。
此优化应在https://github.com/orientechnologies/orientdb/issues/1756问题之后实施。
enhancement
laa
👍1
所有3条评论
@laa根据这份报告，我认为LSM 树的实现是发展 orientdb 最有价值的一步。
saeedtabrizi
于 2017-02-03
@saeedtabrizi这个报告有点作弊，它没有考虑 LSM 树有很多级别的情况，写入放大如此之大以至于所有写入都停在那里。
laa
于 2017-02-03
😄1
👍1
@saeedtabrizi也 WiredTiger 不使用事务，它使这些事情的实现变得更加简单，我们现在专注于分形索引，它具有很好的集成到基于事务的系统中的潜力
laa
于 2017-02-03
👍2
❤1
🎉1
此页面是否有帮助？
0 / 5 - 0 等级
相关问题
codelimner
·
4评论
f-hashemi
·
4评论
snig-b
·
5评论
akizze01
·
3评论
lightjiao
·
3评论
最有用的评论
@saeedtabrizi也 WiredTiger 不使用事务，它使这些事情的实现变得更加简单，我们现在专注于分形索引，它具有很好的集成到基于事务的系统中的潜力