ネストしたファセットとSortableTextField
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/0sdtpmhgxgn9fwfnsg11hyjjmxvpglqv into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは、
こんにちは、
Nested Facets（https://solr.apache.org/guide/8_11/json-facet-api.html#nested-facets）が _txt_sort フィールド（SortableTextField）で機能しない理由が分かりません。
問題を再現するために、新しいコレクション（設定セット: _default）を作成し、次のようにコレクションに追加しました。
{
"name_txt_sort": ["Amelia Harris"],
"name_txt": ["Amelia Harris"],
"sex_s": "female"
},
{
"name_txt_sort": ["Olivia Wilson"],
"name_txt": ["Olivia Wilson"],
"sex_s": "female"
},
{
"name_txt_sort": ["George Smith"],
"name_txt": ["George Smith"],
"sex_s": "male"
}
もし私のクエリが以下のようであれば：
{
"query": "*:*",
"facet": {
"categories": {
"type": "terms",
"field": "name_txt",
"limit": -1,
"facet": {
"sex_s": {
"type": "terms",
"field": "sex_s",
"limit": -1
}
}
}
}
}
出力は正しいです：
"facets":{
"count":3,
"categories":{
"buckets":[{
"val":"amelia",
"count":1,
"sex_s":{
"buckets":[{
"val":"female",
"count":1}]}},
{
"val":"george",
"count":1}]}}
しかし、もし私がクエリ内の "field": "name_txt" を "field": "name_txt_sort" に変更すると、1階層のグループ結果しか表示されません。
「facets」の出力は以下の通りです：
"facets": {
"count": 3,
"categories": {
"buckets": [
{
"val": "Amelia Harris",
"count": 1
},
{
"val": "George Smith",
"count": 1
},
{
"val": "Olivia Wilson",
"count": 1
}
]
}
}
_txt フィールドの場合、その fieldType は "text_general" で、クラスは "solr.TextField" です。
一方、_txt_sort フィールドの場合、その fieldType は "text_gen_sort" で、クラスは "solr.SortableTextField" です。
SortableTextField が Nested Facets に影響を与えるようですが、関連するドキュメントを見つけることができませんでした。
これはバグなのか、SortableTextField が Nested Facets で使用できないのでしょうか？
どうぞよろしくお願いします。
Zhiqing
この問題は https://issues.apache.org/jira/browse/SOLR-13056 に関連しています。
私の疑問点は次のとおりです：もしトップレベルのファセットに method:uif を設定した場合、望ましい結果を得ることができるのでしょうか？（method:uif を設定すると、通常の TextField をファセット化する際と同様に、インデックスされた値の無反転化が発生します）。もしこれが機能すれば、SortableTextField でのファセット化に関する主要な問題、つまり、SortableTextField の DocValues がソートには適していますが、精度やネストしたドメインフィルタリングに使用されるインデックスされた値とは異なる点を解決できるかもしれません。
また、https://issues.apache.org/jira/browse/SOLR-8362 も参照してください。
こんにちは、Michael
迅速な返信と関連情報をありがとうございます。
私は「method":"uif」を3か所で追加しましたが、問題は解決されませんでした。
1.
{
"query": "*:*",
"method":"uif",
"facet": {
"categories": {
"type": "terms",
"field": "name_txt_sort",
"limit": -1,
"facet": {
"sex_s": {
"type": "terms",
"field": "sex_s",
"limit": -1
}
}
}
}
}
レスポンス：
"error":{
"metadata":[
"error-class"...]}
2.
{
"query": "*:*",
"facet": {
"method":"uif",
"categories": {
"type": "terms",
"field": "name_txt_sort",
"limit": -1,
"facet": {
"sex_s": {
"type": "terms",
"field": "sex_s",
"limit": -1
}
}
}
}
}
レスポンス：
"error":{
"metadata":[
"error-class", ...]}
3.
{
"query": "*:*",
"facet": {
"categories": {
"method":"uif",
"type": "terms",
"field": "name_txt_sort",
"limit": -1,
"facet": {
"sex_s": {
"type": "terms",
"field": "sex_s",
"limit": -1
}
}
}
}
}
レスポンス：
"facets":{
"count":3,
"categories":{
"buckets":[{
"val":"Amelia Harris",
"count":1},
{
"val":"George Smith",
"count":1},
{
"val":"Olivia Wilson",
"count":1}]}}
別の場所で「method":"uif」を試してみるべきでしょうか？
よろしくお願いします。
Zhiqing
期待通りに機能するかと思っていましたが、それがうまくいかなかったので、さらに調査しました。残念ながら、明示的にmethod:uifを設定しても効果がありません。もしDocValuesが存在すれば、それが使用されます：
SOLR-8362（または他のより具体的な解決策）が実装されるまでの間、責任を持って推奨できるのは、SortableTextFieldをファセットに使用しないことです。TextFieldを使用することは可能でしょうか？TextFieldは uninverted される必要がありますが、少なくとも大規模なファセット収集に適したインデックスされた値の要件を満たします。
こんにちは、Michael
責任ある推奨事項をいただき、ありがとうございます。はい、私たちのアプリケーションではTextFieldを使用できますが、ソート機能を持つSortableTextFieldを使用したいと考えています。以前のコメント（2019年3月）を https://issues.apache.org/jira/browse/SOLR-13056 で読ませていただきましたが、以前のパッチはこの問題を解決または部分的に解決することができましたか？
よろしくお願いします。
Zhiqing
ご希望は、ファセットをトークン化された値に基づかせるのか、または元の入力を単一の文字列として使うのか、どちらですか？とにかく、SOLR-13056に添付されたパッチは役立つ可能性が低いです。SOLR-8362に関連付けられたパッチは役立つかもしれません（実際にはこの種の状況を改善するために設計されています）。ただし、それはかなりの大規模なパッチであり、仮にそれを使うことは推奨しません。
良いニュースは、SortableTextFieldはある種の便宜上のものであり、トークン化後の値であるか、元の文字列であるかに応じて、クリエイティブなcopyFieldsなどを活用することで、おそらく望む結果を得ることができるということです。
私が常に疑問に思っていることの一つは、SortableTextFieldの有用性です。なぜなら、ソート値が正規化されていない可能性があるからです（大文字小文字の統一など）。1つだけのインデックスタイムアナライザを構成する必要があり、それがトークン化に使用される（再び、私の理解では）。しかし、ソート値（通常はKeywordTokenizerなどで正規化されるかもしれない値）は、解析前の生の入力に基づいています。
私はいくつかの仮定をしていますが、もし全体の値に正規化されたソートとトークン化後の値に基づくファセットが必要ならば、ICUCollationFieldなどを使って入力を2つの別々のフィールドにコピーすることをお勧めします。1つはソート用に（おそらくICUCollationField）、もう1つはファセット用に（TextField）。ファセットにはuninversionが必要です（TextFieldにはdocValuesがありません）。トークン化後のファセットの使用ケースに関する一般的な興味深い議論は、こちらで見つけることができます [1]。
[1] https://issues.apache.org/jira/browse/LUCENE-10023
Michael
トピックへ返信するには、ログインが必要です。