Elasticsearch是否适合作为最终存储解决方案？

Question

我目前正在学习Elasticsearch，我注意到很多修改索引的操作都需要重新索引所有文档，比如在所有文档中添加一个字段，从我的理解意味着检索文档，执行理想的操作，从索引中删除原始文档并重新索引。这似乎有些危险，在执行此操作之前（显然），原始索引的备份似乎更可取。

这让我想知道Elasticsearch是否真的适合作为最终存储解决方案，或者我是否应该保留构成索引的原始文档单独存储，以便能够在必要时从头开始重新创建索引。或者是足够安全的索引的定期备份？

Answer 1

我非常确定，由于这些应用程序的性质，搜索引擎不应被视为存储解决方案。我从来没有听说过这种备份搜索引擎索引的做法。

使用 ElasticSearch 或Solr或您拥有的任何搜索引擎时的常用架构：

1. 你有某种数据源（它可能是数据库，遗留大型机，excel论文，一些带数据的REST服务或其他）
2. 您的搜索引擎应该将此数据源编入索引，以添加到您的系统搜索功能中。更改数据源时 - 您可以重新索引它，或者在增量索引的帮助下仅索引更改的部分。

如果搜索引擎索引出现问题 - 您可以轻松地重新索引所有数据。

Answer 2

你在这里谈论两个问题：

1. 删除旧文档并重新编制架构更改索引：添加新字段时，不必总是删除旧文档。有多种选项可以更改架构。看一下这个博客，它解释了在没有任何停机时间的情况下更改架构。

http://www.elasticsearch.org/blog/changing-mapping-with-zero-downtime/

另外，请查看Update API，它可以添加/删除字段。

  

更新API允许根据提供的脚本更新文档。该操作从索引获取文档（与分片并置），运行脚本（使用可选的脚本语言和参数），并对结果进行索引（也允许删除或忽略操作）。它使用版本控制来确保在“get”和“reindex”期间没有发生更新。   注意，此操作仍然意味着文档的完全重新索引，它只是删除了一些网络往返，并减少了get和索引之间版本冲突的可能性。需要启用_source字段才能使此功能正常工作。

1. 完全使用Elasticsearch作为最终存储解决方案：这取决于您打算如何将Elastic Search用作存储。您是否需要RDBMS，密钥值存储，基于列的数据存储或MongoDb等文档存储？当你需要一个基于Lucene的高级搜索功能的分布式文档存储（json，html，xml等）时，弹性搜索绝对是非常适合的。查看ES的各种用例，尤其是“卫报”中的用法：http://www.elasticsearch.org/case-study/guardian/