4

これまで、MongoDB（Node.js + Mongoose）を使用してユーザーに属する投稿を保存し、後でそれらを取得してストリームに表示できるようにしました（Facebook、Twitterなど）。

最近、ユーザーが自分のストリームを深く検索できるようにすることが必要になりました。MongoDBの検索が不十分だったため、サーバーにElasticSearchを実装しました（CentOS、FWIWを実行しているAmazon EC2 m1.largeインスタンス）。

私の質問：MongoDB（ユーザーのストリームがキャッシュされる場所）とElasticSearch（検索される場所）の間でデータを複製しているところにいます。

キャッシュをElasticSearchに完全に移動し、MongoDBをすべて一緒に削除することに不利な点はありますか？ストレージを2倍にするのはもったいないようで、このデータにアクセスしている場所は他にありません（投稿のストリームを表示/検索するときにのみ使用されます）。

具体的には、パフォーマンスに関して何も見逃していないことを確認したいと思います。私はMongoDBをボトルネックとして減らすというアイデアが好きですが、ElasticSearchのメモリオーバーヘッドについて心配しています。MongoDBは、私のクラウドセットアップでは独自のサーバーで実行されますが、ElasticSearchはnode.jsと同じインスタンスで実行されます。これは、ElasticSearchサーバーがもっとあることを意味します（node.jsサーバーは自動スケーリング配列にあります）が、それぞれが専用サーバーではありません（ MongoDBとは異なります）。

4

2 に答える 2

6

ESを「プライマリデータソース」として使用する際の唯一の大きな障害は、現在、適切なバックアップメカニズムがないことです。ESチームはこれに取り組んでおり、年末までにリリースされる予定ですが、それまでの間、独自のバックアップスクリプトを実装する必要があります。

パフォーマンスに関しては、ほとんどすべての状況が独特であるため、言うのは本当に難しいです。ESはメモリの恩恵を受けるので、常に多いほど良いです。特に、sorts / filters / facets/geoはすべてメモリを食べるのが好きです。たとえば、ファセットの方法で多くのことをしていない場合は、メモリが少なくても問題ない可能性があります。

ESは専用ノードで実行する必要はありません...しかし、ESはあなたがそれを与えるのと同じくらい多くのリソースを喜んで使用します。

于 2013-02-01T19:07:02.080 に答える
2

もう1つのオプションは、ElasticSearchインデックスのみを使用することです。読み取り可能な形式でデータを保存しないことを選択できるため、ESで検索し、必要に応じてMongoDBからユーザーにドキュメントを取得します。

以下の質問はそれについて正確にコメントしています。 選択したフィールドのみを保存し、pyes/elasticsearchに_allを保存しない

于 2013-03-02T19:12:59.207 に答える