ping :)

Vincenzo D'Amore

もしfieldTypeで使用するクラスがdocValuesをサポートしているものであれば、おそらくそれをfalseに設定すべきです。そして、そのフィールドでファセットなどの機能が必要な場合は、indexのuninvertedビューが必要であることを確認して、docValuesをtrueに設定してください。

一部のfieldTypeクラス（TextFieldがその1つです）は、docValuesをサポートできません。一般的に、そのようなフィールドではuninvertableをfalseに設定することを推奨しますが、もし実際にそのようなフィールドでファセットなどの操作を行いたい場合は、uninvertableをtrueに設定する必要があります。

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

（Shawnの意見を反映して送信するつもりだったので）

フィールドを「uninvert」するプロセスは、特定のフィールドに対するインデックスされた用語の辞書を走査し、"doc => term" のルックアップを提供するオンヒープのデータ構造を構築することを含みます（これはdocValuesに類似しています）。これは、通常のインデックスされたフィールドの "term => doc" ルックアップとは対照的です。欠点としては、フィールドをuninvertするときに（およびdocValuesライクなデータ構造を構築するときに）サーチャーのウォームアップの遅延コストが発生すること、そして（潜在的に非常に大きな）ヒープ領域の割り当てが静的オーバーヘッドとしてヒープ領域要件に寄与し、GC操作によって走査されることなどがあります。

ほとんどの場合、docValuesタイプのアクセスが必要な場合は実際のdocValues（つまり "docValues=true"）を使用することが推奨されます。これにより、これらのデータ構造が直接ディスクにバックアップされ、実質的にオフヒープになり、メモリマップドファイルに基づく効率的なOSレベルのキャッシングが可能になります。ただし、現在のところ、インデックスされた用語とdocValuesで表現される用語との間で互換性が必要なポスト分析docValuesを持つ方法がないため、テキストフィールドのトークン化された値でファセットを行いたい場合など、一部のケースでは "uninvertible=true" を引き続き使用する必要があります。

一般的に、"uninvertible=false" は、この古い/後方互換性の「uninversion」動作に依存していないことを確認するための健全性チェックとして役立ちます。もし可能であれば、"uninvertible" をグローバルにデフォルトで "false" に設定する方法があれば、それを推奨しますが、現時点ではそのような方法はないため、手動で "uninvertible=false" を設定し、必要に応じて "docValues=true" または "uninvertible=true" を追加する（この順序で好ましい）ことが一般的に良い推奨です。

Shawn, Michael, ありがとうございます。とても有益で、理解しやすい説明でした。

Vincenzo D'Amore

もう1つ質問があります。新しい schema.xml において、"id" フィールドやその他の pint/plong/string などのフィールド（つまり "docValues=true" に設定されているフィールド）に対して、uninvertible=false を適用すべきでしょうか？

Vincenzo D'Amore

はい。もしフィールドがdocValuesを持っているなら、それがuninvertableである理由はありません。厳密に必要な設定ではないかもしれませんが、それを設定することで（潜在的に）大きなオンヒープのメモリ構造が作成されることがないように保証されます。

Michaelの意見に同意しますが、uninvertableをグローバルにfalseに設定する方法が必要です。私は、現在の最大バージョンが1.6であると思いますが、スキーマバージョン1.7でそれを行うのが優れた方法だと考えます。そのため、uninvertableがデフォルトでfalseになるような設定を行うことを提案します。私はこの問題を開くつもりです。

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