通过Tire gem实现Elasticsearch版本控制

Question

我有一个现有的Rails应用程序，它使用轮胎(0.4.0)与Elasticsearch (0.17.4)引擎进行交互。它已经有几个使用Tire::Persistence的模型。我想添加一个利用Elasticsearch版本控制的新模型，以跟踪所有更改，并能够恢复到以前的版本。

现在，当我检索任何“持久化”的模型实例时，我检查_version，它总是nil。我还没有找到任何与版本控制相关的轮胎文档。我是否必须以某种方式激活它，或者手动保存带有版本值的记录？我在这里的轨道是对的吗？

我确实看到某些方法会为项返回_version值，但其他方法不会...

Article.first._version                          # => nil
Article.search("sample query").first._version   # => nil
Article.find("id_123")._version                 # => 8

此外，版本化似乎增加了2。也许轮胎还没有完全准备好处理版本化。它正在保存以前的版本吗？如何检索记录的以前版本？

编辑我可能误解了Elasticsearch中的“版本控制”到底是什么。看起来它主要是为了并发控制。哦，好吧。(不过，我很乐意听到不同的说法)

Answer 1

首先，是的，正如您在编辑中所写的那样，ElasticSearch中的版本不是用于存储文档的修订版本，而是用于并发控制(例如，不用陈旧版本覆盖文档)。

第二，你必须声明你想要从搜索返回的版本；http://www.elasticsearch.org/guide/reference/api/search/version.html

这段代码向你展示了如何在Tire中做到这一点。

require 'tire'

Tire.index('articles') do
  delete
  create
  store id: 1, title: 'One'
  store id: 2, title: 'Two'
  store id: 2, title: 'Two again'

  refresh
end

articles = Tire.search('articles') do
             query { all } 

             version true
           end.results

articles.each do |article|
  puts "Article '#{article.title}' has version #{article._version}"
end

目前，最好阅读Tire集成测试套件中的文档。当然，文档是应该而且将会改进的东西。

至于你的原始需求本身，在过去，类似的问题经常出现在CouchDB上。Simple Document Versioning with CouchDB的博客文章描述了一个很好的策略。由于文档模型类似，因此研究CouchDB解决方案会对您很有帮助。(当然，与ElasticSearch相反，CouchDB确实以物理方式存储文档修订，因此它开启了一系列不同的策略。)

在ElasticSearch中，关于使用修订的基本决策是：

我是否希望将完整的修订直接存储在本身中？

这对于较小的文档和较小的数据库可能是有意义的。根据您的需求，它可以使搜索历史文档变得非常简单。

ElasticSearch中的将使得将这些“修订作为嵌套文档”处理起来既方便又容易。

(您也可以在JSON本身中存储文档的“差异”，但我敢打赌，这会给应用程序逻辑带来更大的压力。)

是否要将修订存储为单独的文档？

您可能希望单独存储修订，并将它们“链接”到它们的基本文档。ElasticSearch中的将使处理这些关系和查询成为可能。