0

アプリケーションにelasticsearchでmongodbを使用しています。Elasticsearch は、oplog コレクションを監視してインデックスを作成します。両方のアプリケーションが常に実行されている場合、mongodb のコレクションに対する変更はすぐにインデックス化されます。私が直面する唯一の問題は、何らかの理由でインデックスを削除して再作成する必要があり、インデックス作成が完了するまでに数日 (2 日) かかることです。

デフォルトで oplog のサイズを調べたところ、容量は 40 GB で、約 6,000 万のトランザクションを保持しているため、新しいインデックスの作成に時間がかかりました。新しいインデックスの作成を最適化する最良の方法は何ですか?

oplog のサイズを小さくして、保持するトランザクションの数を減らし、レプリケーションに影響を与えないようにするか、oplog で ttl インデックス (何度か試行して失敗しました) を作成することは可能ですか。

mongodb River https://github.com/richardwilly98/elasticsearch-river-mongodb/を使用して、mongodb で Elasticsearch を使用しています。

上記の問題を克服するための助けをいただければ幸いです。

4

2 に答える 2

0

私はElastic Searchのプロではありませんが、あなたの質問:

新しいインデックスの作成を最適化する最良の方法は何ですか?

MongoDB でサードパーティの FTS 技術を使用するすべての人に少し当てはまります。

最初に注意すべきことは、大量のレコードがある場合、それらの一部を失う覚悟がない限り、これを回避する簡単な方法はないということです。

これには oplog はあまり良い考えではありません。おそらく、メイン コレクションのタイマーを使用してカスタム スクリプトを使用してこれを個人的に行うか、単一の場所で新しいレコードまたは更新されたレコードをすばやくクエリできる変更テーブルを使用することを検討する必要があります。

特定のレコード、つまり挿入を取得するために oplog をフィルタリングしていない限り、削除、コレクション操作、さらにはデータベース操作を含むすべての oplog レコードを引き出すことができます。そのため、oplog 検索から不要なレコードを削除してみることができますが、これにより新しい問題が発生します。oplog にはインデックスもインデックスの更新もありません。

これは、より適切な方法で読み取りを開始すると、実際にはこれらの 6,000 万レコードに対してインデックスなしのクエリを使用することになることを意味します。これにより、パフォーマンスが低下します。

インデックスを更新しない oplog は、別の質問に答えます。

oplog で ttl インデックスを作成することは可能ですか (何度か失敗しました)。

いいえ。

あなたの質問のもう1つについては：

oplog のサイズを小さくして、保持するトランザクション数を減らすためですか?

はい。ただし、レプリケーションの回復期間が短くなるだけでなく、「新しい」インデックスからレコードが失われるため、実際にはデータの一部のみがインデックス化されます。あなたの質問から、これが問題かどうかはわかりません。

于 2013-07-15T10:50:31.023 に答える