(The bot translated the original post https://lists.apache.org/thread/p3cnjb6311sm878n08zcn35ysvs0444n into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)

こんにちは。

お元気でいらっしゃいますか。

私たちが直面している問題の紹介から始めたいと思います。

私たち（CompanyBと呼び、WebBに取り組んでいます）の主な目標は、既存のWebアプリケーション（CompanyAが開発したWebA）の検索機能を拡張するWebアプリケーションを作成することです。

この既存のWebアプリケーションをWebAと呼びましょう。WebAは複数のクライアントに展開されており、各クライアントは独自のドキュメントセットを持っています。大規模なインスタンスでは、インデックスはほぼ毎分更新され、インデックスのサイズは数百GBにもなることがあります。WebAはCompanyAによって開発され、キーワード検索、著者のファセットなど、基本的な検索機能を提供しています。

次に、CompanyBがWebAのインスタンスを基にWebBを構築するプロジェクトに着手します。主な目標は、WebAのコンテンツを取り込み、自然言語処理を実行し、外部ソースからのドキュメントに関するメタデータを取得してインデックスに追加し、新しいWebBがこれらの追加されたメタデータに対して高度な検索機能を提供することです。WebBはまた、元のインデックスのフィールド（著者、タイトルなど）で検索できるだけでなく、これらの新しいフィールドでも検索できるようにし、結果を効果的に組み合わせることが必要です。

WebAとWebBは同じ顧客向けであるため、CompanyAとCompanyBの間で多少の協力が可能ですが、WebAに対してCompanyAが行う必要のある作業量は最小限に抑える必要があります。

問題は以下の通りです：
最初のアイデアは、WebBがWebAのインデックスを複製し、自分のインデックスのコピーを持つことでした。ドキュメントに新しいメタデータが収集されたとき、自分のインデックスでドキュメントを更新します。しかし、両方のプロジェクトが同じ顧客向けであるため、インデックスを二重にすることが問題となりました。また、このアイデアは元のインデックスが頻繁に更新されないという前提に基づいていましたが、それが事実でないことが判明しました。

次のアプローチは、既存のインデックスを使用することでしたので、2つのインデックスにデータを複製する必要はありません。しかし、元のインデックスはWebAによって使用され、別の会社によって作業されているため、それには多くの作業が必要であり、おそらく不可能でしょう。再インデックス時には、CompanyB/WebBによってインデックスに投稿された新しいメタデータにアクセスできず、WebBからのクエリがWebAのパフォーマンスに影響を与え、WebAがWebBによって追加されたフィールドを返さないように結果をフィルタリングする必要があるなどの問題が生じます。

3つ目のアイデアは現実に最も近いかもしれませんが、それでも現実的でないかもしれません。このアイデアは、WebAのSolrクラスタに新しいシャード/ノードを作成し、そこに新しいメタデータだけをインデックスするというものです。しかし、両方のノードから検索結果を返す必要があるため（例えば、「author:ABC && metadata_one:123」のようなクエリ）、それも不可能だと思います。新しいノードの追加メタデータのみを含むドキュメントは、レスポンスでは同じドキュメントとして表される必要があります。これは、結果が元のノード（著者、タイトルなど）と新しいノード（メタデータ1、名前付きエンティティなど）の両方のフィールドを含む必要があるためです。クエリ、ファセット、およびソートの結果も何らかの形で組み合わせる必要があります。

また、CDCR（クロスデータセンターレプリケーション）も検討しましたが、CDCRの使用例は少し異なり、ターゲットクラスタはソースクラスタの更新なしで更新されるべきではありません。これは私たちの望むことではありません。私たちは、追加のフィールドで強化された最新の元のインデックスを持ちたいと考えています。

私の説明が十分に明確であることを願っており、皆さんの助けを感謝いたします。

お時間をいただき、ありがとうございました。良い一日をお過ごしください。

Norbert Bodnar