Solr 4.7は顧客が望むようにこれを処理しますが、Solr 9.1ではそうではありません。

これはレースコンディションのように思えます。ソートを行っているのがSolrであり、ネットワークスタックなどではないと確信していますか？

私が確認したところ、"add"リクエストが先に来ると、少なくともSolr 8.11.2では、新しい無用なドキュメントが作成されます。私はそれが失敗してくれた方がよいと思います。

Dima

更新とインデックス作成はかつてシングルスレッドで行われていましたが、しばらく前（おそらくSolr 6.xの頃）に、インデックス作成が複数のCPUを使用できるように、一連のロックが削除されました。おそらくそれが今回の現象の原因だと思います。

Solrは、たとえうまく動作したとしても、更新の順序を保証したことはないと思います。

更新の前にリアルタイムでドキュメントが本当に存在するかを確認するために、リアルタイムゲットを使用するのも一つの方法かもしれません。それは比較的速く実行できるはずです。

wunder
Walter Underwood
wunder@wunderwood.org
http://observer.wunderwood.org/ (私のブログ)

ログで確認したところ、インデックスリクエストを送信する2つのシステムのリクエストと、それに対応するSolr 9.xのsolr.logのエントリが見られました。"更新"リクエストが"作成"リクエストの1ミリ秒前に送信されています。"更新"リクエストには、"作成"リクエストよりもかなり多くのフィールドデータが含まれているため、処理に時間がかかっていると確信しています。

これらのリクエストを4.7クラスターに送信すると、最終的には更新されたレコードが保持されます。これは、2つの更新の処理時間の違いによるもので、受信順序が無視された結果だと思います。

同じリクエストを9.1.1クラスターに送信した場合、"更新"レコードではなく"作成"レコードが保持されます。顧客はこれを9.1.1のバグだと考えていますが、私はSolr 9が実際には正しく動作しており、受信順序を尊重していると思います。Solr 4は、バグの結果として顧客の期待を偶然満たしていたに過ぎないのではないかと考えています。

私が確認したところ、"add"リクエストが先に来ると、少なくともSolr 8.11.2では、新しい無用なドキュメントが作成されます。私はそれが失敗してくれた方がよいと思います。

希望する動作を実現するには、オプティミスティック同時実行機能を使用できるかもしれません。

オプティミスティック同時実行機能が、顧客のセットアップでも役立つかもしれません。

ありがとうございます。
Shawn

私の場合はそうではありませんが、ヒントをありがとうございます。今後の参考としてもう一つ記録しておきます。

とにかく、Walterが言ったように、スレッド間で競合しています。

（あなたの説明からすると、4.xの動作に依存するのは最初から悪いアイデアでした。例えば、「作成」リクエストが非TLERドライブの悪いセクターに当たって、100倍長くI/Oが詰まってしまったらどうなりますか？）

Dima

異なるサービスから送信された2つのリクエストの調整は難しいと思われるため、問題を解決するために最も簡単な変更は、オプティミスティック同時実行を使用し、「作成」リクエストでフィールドを0に設定して、ドキュメントがすでに存在する場合にリクエストが失敗するようにすることだと思います。もちろん、結果として発生するエラーは明示的に検出される必要があり、無視することができる一方で、他のエラーは正しく処理する必要があります。SolrJコードで実際にインデックス作成リクエストを行う部分は見たことがありません。

この前提で、オプティミスティック同時実行が未コミットのドキュメントをチェックすることを期待しています。なぜなら、2回目の更新が来たときに、最初の更新が実際にコミットされている可能性は非常に低いためです。

ありがとうございます。
Shawn

現在の運用方法が完全に間違っているという点には同意しますし、それがうまくいったことに驚いています。彼らは非常にラッキーでした。

ありがとうございます。
Shawn

http://www.catb.org/jargon/html/S/schroedinbug.html

よろしくお願いします、
Dima