ElasticSearch与MongoDB用于缓存用户数据

到目前为止，我一直在使用MongoDB（Node.js+Mongoose）保存属于某个用户的帖子，以便以后可以检索到这些帖子并显示在流中（就像Facebook、Twitter等）

最近有必要允许用户深入搜索他的流；MongoDB的搜索不足，所以我在我的服务器上实现了ElasticSearch（Amazon EC2 m1.large instances，运行CentOS，FWIW）

我的问题：我现在的位置是在MongoDB（缓存用户流的地方）和ElasticSearch（搜索它的地方）之间复制数据

将我的缓存完全移动到ElasticSearch中，同时摆脱MongoDB有什么缺点吗？将存储空间翻一番似乎是一种浪费，而且我没有其他地方可以访问这些数据（它仅在呈现/搜索帖子流时使用）

---

具体来说，我想确保我没有忽视任何关于性能的事情。我喜欢减少MongoDB作为瓶颈的想法，但我担心ElasticSearch的内存开销。MongoDB在my cloud设置中自己的服务器上运行，而ElasticSearch与node.js在相同的实例上运行。这意味着我将拥有更多的ElasticSearch服务器（node.js服务器位于自动缩放阵列中），但它们都不是专用的服务器（与MongoDB不同）。

使用ES作为“主要数据源”的唯一大障碍是目前没有良好的备份机制。ES团队正在进行这项工作，并预计它将在今年年底推出，但与此同时，您必须实现自己的备份脚本

至于表现，这真的很难说，因为几乎每种情况都是独一无二的。ES得益于记忆，所以越多越好。特别是，排序/过滤器/方面/地理位置都喜欢消耗内存。例如，如果你在刻面方面做得不多，那么你的内存可能会少一些

---

ES不需要在专用节点上运行……但它会很高兴地使用您提供的尽可能多的资源。

另一种选择是只使用弹性搜索索引。您可以选择不以可读格式保存数据，因此您可以在ES中搜索，然后根据需要从MongoDB向用户检索文档

下面的问题正好说明了这一点。

---

很有趣。当我使用“EC2上的Elasticsearch”教程时，我想数据都存储在S3存储桶中了？虽然这本身可能不是“备份”，但它至少提供了持久性（即，如果给定的服务器宕机，数据不会丢失，对吗？）您是正确的，尽管应该注意到S3网关已经贬值（）。一般来说，这就是我的意思……您需要一些东西（S3网关、快照的cron脚本等）来提供恢复机制，而其他数据存储隐含地提供了这种机制。这不是什么大不了的事，ES正在积极努力自己提供这一功能。