Elasticsearch refresh vs. flush
问:
若一个新的文档索引进ES索引,则它在索引操作执行后约1s可以搜索到。然而我们可以直接调用_flush
或者_refresh
对索引进行操作。那么这两者有什么区别呢——看起来这两个操作的结果都类似,文档都是立即可以被搜索的?
答:
我们详细解释一下这两种操作:
refresh
操作有效地对Lucene index reader调用了reopen,使得在数据的那个时间快照进行了更新。这是Lucene拥有的近实时搜索api的特性。
ES refresh
让文档可以搜索到,但是不保证这些信息被写入disk进入一个永久的存储状态,因为它并没有调用fsync
,这就不能保证持久性了。让你数据获得持久性的是Lucene commit,这个操作代价比较大。
当你可以每秒都调用lucene reopen时,你不能这样使用lucene的commit。
借助lucene你可以尽可能频繁地调用reopen以使新的文档可以被搜索到,但是你仍然需要调用commit来确保数据写入disk并且fsynced,这样会安全。
ES通过增加了一个在每个shard(一个lucene的索引)上的事务解决这个问题,还未被commit的写操作会被存起来。事务log被fsynced,已经安全了,所以你每时每刻都获得了持久性,甚至对于那些没有被commit的文档,都是这样。因为refresh
每秒自动地发生,所以你可以近实时地搜索文档,并且如果有不好的事件发生,事务log可以被替代从而恢复那些丢失的文档。事务log的优越性是它可以被用来做其他的事情,例如提供实时的get_by_id
。
elasticsearch flush
高效地触发lucene commit,并同时清空事务log,因为一旦数据在lucene层面提交,持久性将会由lucene保证。Flush
同样是一个api,也可以进行微调,虽然通常没有必要这样。Flush
自动发生取决于事务log增加了多少操作、它们有多大、最后一次flush何时发生。
原文链接:http://www.jianshu.com/p/0e9f6346f1fe