3

弾性検索をほぼキャッシュとして使用し、時間枠で見つかったドキュメントを保存します。さまざまなサイズのドキュメントを継続的に挿入し、日付フィルターと組み合わせたテキスト クエリを使用して ES を検索し、現在のスレッドが既に表示されているドキュメントを取得しないようにします。このようなもの：

"((単語 1 AND 単語 2) OR (単語 3 AND 単語 4)) AND 挿入日 > 1389000"

TTL 機能を使用して、エラスティック検索でデータを 30 分間維持します。現在、少なくとも 3 台のマシンが、マシンごとに 1 分ごとに一括リクエストで新しいドキュメントを挿入し、実質的に継続的に上記のようなクエリを使用して検索しています。

これらのドキュメントのインデックス作成と取得に多くの問題が発生しており、ES によってインデックスが作成されて返されるドキュメントの十分なスループットが得られていません。毎秒 200 のドキュメントをインデックスに登録することすらできません。

問題は同時クエリ、挿入、および TTL 削除にあると考えています。古いデータをエラスティックに保持する必要はありません。特定の時間にエラスティックでインデックス付けされたドキュメントの小さな時間枠が必要なだけです。パフォーマンスを向上させるために何をすべきか?

前もって感謝します

マシンタイプ：

  • Amazon EC2 ミディアム インスタンス (3.7 GB の RAM)

追加情報：

編集

フィードバックをお送りするのが遅くなり、申し訳ありません。ここ私たちの会社では多忙を極めていたので、問題をどのように解決したかについてより詳細な説明をするために、落ち着いた時期を待つことにしました。実際の改善を測定するには、まだいくつかのベンチマークを実行する必要がありますが、ポイントは問題を解決したことです:)

まず、インデックス作成のパフォーマンスの問題は、out 部分の使用エラーが原因であると考えています。前に説明したように、Elasticsearch を一種のキャッシュとして使用して、30 分の時間枠内でドキュメントを検索しました。コンテンツがクエリに一致し、挿入日が特定の範囲内にあるドキュメントをelasticsearchで探しました。次に、Elastic は完全なドキュメント json を返します (インデックス化されたコンテンツの他に、大量のデータが含まれています)。私たちの構成では、誤ってドキュメントの json フィールド (content フィールドと insertDate フィールド以外) にエラスティック インデックスを作成していました。これが、インデックス作成のパフォーマンスの問題の主な原因であると考えられます。

ただし、ここでの回答で示唆されているように、多くの変更も行いました。これにより、パフォーマンスも向上したと考えられます。

  • 現在は TTL 機能を使用せず、代わりに共通のエイリアスで 2 つの「ローリング インデックス」を使用しています。インデックスが古くなったら、新しいものを作成し、それにエイリアスを割り当て、古いものを削除します。

  • 私たちのアプリケーションは、毎秒膨大な数のクエリを実行します。これはエラスティックに大きな打撃を与え、インデックス作成のパフォーマンスを低下させると考えています (エラスティック検索には 1 つのノードしか使用しないため)。ノードに 10 個のシャードを使用していたため、エラスティックに発行した各クエリは、シャードごとに 1 つずつ、合計 10 個のクエリに変換されました。いつでもエラスティックのデータを破棄できるため (したがって、シャードの数を変更しても問題ありません)、シャードの数を 1 に変更し、エラスティック ノードのクエリ数を大幅に削減しました。

  • インデックスには 9 つのマッピングがあり、各クエリは特定のマッピングに対して起動されます。これらの 9 つのマッピングのうち、挿入されたドキュメントの約 90% がこれらのマッピングのうちの 2 つに行きました。これらのマッピングごとに個別のローリング インデックスを作成し、残りの 7 つを同じインデックスに残しました。

  • 実際には変更ではありませんが、Sematext から SPM (スケーラブル パフォーマンス モニタリング) をインストールしました。これにより、エラスティック サーチを綿密に監視し、実行されたクエリの数などの重要なメトリックを学習することができました -> sematext.com/spm/index.html

私たちの使用数は比較的少ないです。毎秒約 100 件のドキュメントが到着しており、インデックスを作成する必要があります。ピーク時は毎秒 400 件です。検索に関しては、1 分あたり約 1500 件の検索があります (シャード数を変更する前は 15000 件)。これらの変更の前は、パフォーマンスの問題が発生していましたが、現在は発生していません。

4

3 に答える 3

1

パフォーマンスを向上させるその他の方法Elasticsearch:

  • インデックスの更新間隔を増やします。1 秒から 10 秒または 30 秒に短縮すると、パフォーマンスに大きな違いが生じる可能性があります。
  • 過度にアグレッシブな場合はマージを抑制します。index.merge.policy.max_merge_at_onceとを下げることで、同時マージの数を減らすこともできますindex.merge.policy.max_merge_at_once_explicit。を下げるindex.merge.scheduler.max_thread_countことも役立ちます

SPM をご利用いただきありがとうございます。EDIT の URL はハイパーリンクではありませんでした - http://sematext.com/spmにあります。" Indexing" グラフは、マージ関連の設定の変更がパフォーマンスに与える影響を示します。

于 2013-12-31T02:58:01.243 に答える