スキーマで uninvertible=true を設定する方法について助けが必要です
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/d343scvlg0ssdsvsprmjyjorb4z2t0fz into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
皆さんこんにちは、
スキーマを 1.6 から 1.7 にアップグレードするにあたって、皆さんの知恵をお借りしたいです。現在のデプロイはスキーマ 1.6 を使っており、この場合は各フィールドの uninvertible 属性がデフォルトで true になっています。そのためソートやファセットがサポートされています。ただし、これらのフィールドで docValues は使用していません。
ところが、スキーマを 1.7 にアップグレードすると、docValues=true かつ uninvertible=false がデフォルトになります。つまり、このままでは既存のインデックスを利用できません。なぜなら uninvertible 属性を有効にしないと、フィールドがソートやファセットをサポートしないからです。そこで質問なのですが、スキーマの各フィールドに対して uninvertible 属性を true に設定しても安全でしょうか？ いくつかの記事で、uninversion はファセットクエリ処理時に大量のメモリを消費し、クラッシュを引き起こす可能性があると読みました。私の環境では非常に大規模なコレクションを扱っており、多くのフィールドでソートやファセットをサポートする必要があります。それでも uninversion を有効にするのは賢明でしょうか？
追記：現時点では docValues を追加することはできません。なぜなら再インデックスのコストが高すぎるためです。Solr 10 までは再インデックスを待つつもりです。
よろしくお願いします。
Sandeep
デフォルトの設定値が変更される前の動作は、今の動作と同じだったと思います。ですので、もし以前うまく動いていたのであれば、今も同じように動くはずです。デフォルト値が false に変わったことで、非効率になったとは思いません。
既存のスキーマを使って、既存のインデックスをそのまま利用することはまったく問題ありません。
新しいバージョンの Solr でデフォルトの configset が変わったからといって、既存のコレクションで既存の configset を使い続けられないということにはなりません。（必要なら 新しい コレクションでも既存の configset を使うことができます。）
もし全てのフィールドに uninvertible=true を個別に設定するつもりなら、スキーマの version=1.7 に変更する理由はありません。
フィールドを「Un-Invert」することによる「コスト」やリスクは変わっていません。変わったのは、新しい Solr コレクションがデフォルトでそのリスクに直面するかどうかだけです。
トピックへ返信するには、ログインが必要です。