4

到目前为止，我一直在使用 MongoDB (Node.js + Mongoose) 来保存属于用户的帖子，以便以后检索它们以显示在流中（就像 Facebook、Twitter 等）

最近有必要让用户深入搜索他的流；MongoDB 的搜索不足，因此我在我的服务器（运行 CentOS、FWIW 的 Amazon EC2 m1.large 实例）上实现了 ElasticSearch。

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

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

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

4

2 回答 2

6

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

至于性能，真的很难说，因为几乎每种情况都是独一无二的。ES 受益于记忆——所以越多越好。特别是 sorts/filters/facets/geo 都喜欢吃内存。例如，如果您没有在刻面方面做太多事情，那么您可以用更少的内存来解决问题。

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

于 2013-02-01T19:07:02.080 回答
2

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

下面的问题正是对此进行了评论。 仅存储选定的字段而不将 _all 存储在 pyes/elasticsearch

于 2013-03-02T19:12:59.207 回答