0

とても簡単な質問があります。

1600000 の比較的大きなドキュメントを含む Elasticsearch インデックスがあり、インデックスをスキャンして従来の SQL データベースと同期する必要があります。

私のドキュメントには、SQL ID とタイムスタンプが含まれています。

次に、SQL データベースとエラスティック インデックスを同期するために、行とドキュメントを順番に読み取り、両方とも ID で並べ替え、ID を比較して、ドキュメントを削除する必要があるかどうかを判断し (比較は負)、新しいドキュメントを追加します。 SQL 行 (比較は正) であり、比較が 0 の場合は、タイムスタンプを比較して、ドキュメントを更新する必要があるかどうかを確認します。

それは機能しますが、読み進めるにつれてドキュメントの読み取りが非常に遅くなることがわかりました。

インデックスで検索を繰り返し、リクエストの「from」フィールドを毎回シフトすることで、ドキュメントをチャンクで取得します。次のようになります。

{
    "from" : 0, "size" : 10000,
    "fields" : ["idannonce","ts"],
    "sort" : ["idannonce"],
    "query" : "match_all" {}
}

この単純なクエリは、「from」が 0 の場合よりも 1000000 の場合の方がはるかに遅くなります。

これは正常な動作ですか? 「idannonce」フィールドにインデックスを付けるのとほぼ同じ時間がかかるはずだと思いました。

何か考えはありますか？一定時間内に実行されるように同じクエリを作成する方法はありますか?

ありがとう

4

2 に答える 2

1

私も同様のことをしていましたが、https：//github.com/jprante/elasticsearch-river-jdbcの方が便利でした。非常にシンプルな統合です。これを使ってみてください。コードの要点を投稿してください。また 、 https：//github.com/lukas-vlcek/bigdeskは、クエリを実行しているときにグラフを観察します。

于 2012-06-23T06:18:39.497 に答える
1

Search API は、このユース ケース用に設計されていません。パフォーマンスが最適化されていないだけでなく、変更がインデックスにコミットされたときに取得ウィンドウを「シフト」することで、削除と追加がelasticsearchの結果に干渉しているため、おそらくいくつかの変更も見逃されています。この操作により適した Scroll APIに切り替える必要があります。

于 2012-06-21T23:25:16.947 に答える