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

皆さん、こんにちは。

私のユーザー向けに実装に苦労しているユースケースがあります。ここで洞察を見つけられることを期待しています。

私たちは、ユーザーがほぼすべてのコンテンツデータを検索できるようにしたいと考えていますが、アクセス制御ポリシーを尊重します。私のユーザーはチームにグループ化されており、ポリシーはチームに基づいてコンテンツに適用されます。

現在の実装方法は、任意のデータをドキュメントとして保存することです。

{
type: contact_number,
value: 1234567890,
aclId: 1_contact_number
}

（コンテンツインデックス内で6百万のドキュメント）

および

{
aclId: 1_contact_number,
canRead: TEAM_A
}

（ACLインデックス内で200万のドキュメント）

両方のインデックスでaclIdのDocValuesが有効になっています。

クエリ中に、コンテンツインデックスをクエリし、fqでJoinクエリパーサーを使用して次のようにfq={!join from=aclId fromIndex=acl to=acl_id}canRead: TEAM_A OR TEAM_B、ユーザーがTEAM_AおよびTEAM_Bの一部である場合。 キャッシュされていないクエリには約8秒かかります。

私の理解に基づくと、これは遅いのは、Solrが以下の作業を行うためです。

1. ACLインデックスからすべてのヒットを取得します。
2. ACLインデックスからのヒットに一致するドキュメントを見つけるために、コンテンツインデックス全体を検索します。
3. 残りのコンテンツクエリを適用して、コンテンツインデックスからの結果をフィルタリングします。

また、私たちは「{!join ... score=none}」を使用してみました（Googleで見つけたものに基づいて）。

これを改善するための考え：

• ストリーミング式を使用することを考えましたが、コンテンツインデックスで/exportを使用すると、スコア以外のフィールドでソートする必要があります。
• コンテンツインデックスを単にコンテンツでクエリし、結果を取得してバックエンドでaclに基づいてフィルタリングを行う。最初の10件の結果が得られるまで。
• これには全体のACLをロードする必要があります。
• ACLのためにドキュメントが削除され続ける場合は、繰り返しコンテンツインデックスをクエリします。
• 利点は、コンテンツインデックス全体を検索する必要がないことです。
• これはプラグインになるかもしれませんか？（労力に値するかどうかはわかりません）

私は間違った道を進んでいますか？