Elasticsearch 是否适合作为最终的存储解决方案？
Is Elasticsearch suitable as a final storage solution?
我最近在学习Elasticsearch，发现很多修改索引的操作都需要对所有文档重新索引，比如给所有文档加一个字段，我的理解就是检索文档，执行理想的操作，从索引中删除原始文档并重新索引它。这似乎有点危险，并且在执行此操作之前备份原始索引似乎更可取（显然）。
这让我想知道 Elasticsearch 是否真的适合作为最终的存储解决方案，或者我是否应该单独存储构成索引的原始文档，以便在必要时能够从头开始重新创建索引。或者索引的定期备份是否足够安全？
我很确定，由于这些应用程序的性质，不应将搜索引擎视为一种存储解决方案。我从来没有听说过这种备份搜索引擎索引的做法。
使用 ElasticSearch 或 Solr 或您拥有的任何搜索引擎时的常用架构：
- 您有某种数据源（可能是数据库、遗留大型机、excel 论文、一些带有数据的 REST 服务或其他）
- 您的搜索引擎应该为该数据源编制索引以添加到您的系统搜索功能。当数据源改变时——你可以重新索引它，或者在增量索引的帮助下只索引改变的部分。
如果搜索引擎索引出现问题 - 您可以轻松地重新索引所有数据。
你在这里讨论了两个问题：
- 删除旧文档并根据架构更改重新编制索引： 添加新字段时不必总是删除旧文档。有多种选项可以更改模式。看看这个博客，它解释了在没有任何停机的情况下更改模式。
http://www.elasticsearch.org/blog/changing-mapping-with-zero-downtime/
此外，请查看更新 API，它使您能够 add/remove 字段。
The update API allows to update a document based on a script provided. The operation gets the document (collocated with the shard) from the index, runs the script (with optional script language and parameters), and index back the result (also allows to delete, or ignore the operation). It uses versioning to make sure no updates have happened during the "get" and "reindex".
Note, this operation still means full reindex of the document, it just removes some network roundtrips and reduces chances of version conflicts between the get and the index. The _source field need to be enabled for this feature to work.
- 完全使用Elasticsearch作为最终的存储解决方案：这取决于您打算如何将Elastic Search用作存储。您是否需要 RDBMS、键值存储、基于列的数据存储或像 MongoDb 这样的文档存储？当您需要具有基于 Lucene 的高级搜索功能的分布式文档存储（json、html、xml 等）时，Elastic Search 绝对适合。查看 ES 的各种用例，尤其是 The Guardian 的用法：http://www.elasticsearch.org/case-study/guardian/
我最近在学习Elasticsearch，发现很多修改索引的操作都需要对所有文档重新索引，比如给所有文档加一个字段，我的理解就是检索文档，执行理想的操作，从索引中删除原始文档并重新索引它。这似乎有点危险，并且在执行此操作之前备份原始索引似乎更可取（显然）。
这让我想知道 Elasticsearch 是否真的适合作为最终的存储解决方案，或者我是否应该单独存储构成索引的原始文档，以便在必要时能够从头开始重新创建索引。或者索引的定期备份是否足够安全？
我很确定，由于这些应用程序的性质，不应将搜索引擎视为一种存储解决方案。我从来没有听说过这种备份搜索引擎索引的做法。
使用 ElasticSearch 或 Solr 或您拥有的任何搜索引擎时的常用架构：
- 您有某种数据源（可能是数据库、遗留大型机、excel 论文、一些带有数据的 REST 服务或其他）
- 您的搜索引擎应该为该数据源编制索引以添加到您的系统搜索功能。当数据源改变时——你可以重新索引它，或者在增量索引的帮助下只索引改变的部分。
如果搜索引擎索引出现问题 - 您可以轻松地重新索引所有数据。
你在这里讨论了两个问题：
- 删除旧文档并根据架构更改重新编制索引： 添加新字段时不必总是删除旧文档。有多种选项可以更改模式。看看这个博客，它解释了在没有任何停机的情况下更改模式。
http://www.elasticsearch.org/blog/changing-mapping-with-zero-downtime/
此外，请查看更新 API，它使您能够 add/remove 字段。
The update API allows to update a document based on a script provided. The operation gets the document (collocated with the shard) from the index, runs the script (with optional script language and parameters), and index back the result (also allows to delete, or ignore the operation). It uses versioning to make sure no updates have happened during the "get" and "reindex". Note, this operation still means full reindex of the document, it just removes some network roundtrips and reduces chances of version conflicts between the get and the index. The _source field need to be enabled for this feature to work.
- 完全使用Elasticsearch作为最终的存储解决方案：这取决于您打算如何将Elastic Search用作存储。您是否需要 RDBMS、键值存储、基于列的数据存储或像 MongoDb 这样的文档存储？当您需要具有基于 Lucene 的高级搜索功能的分布式文档存储（json、html、xml 等）时，Elastic Search 绝对适合。查看 ES 的各种用例，尤其是 The Guardian 的用法：http://www.elasticsearch.org/case-study/guardian/