Elasticsearch refresh vs. flush【转载】

源地址：    http://www.jianshu.com/p/0e9f6346f1fe

问：

若一个新的文档索引进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何时发生。