ここで聞くのが適切なのか分からないのですが、PGroongaのノーマライズ処理について、教えてください。

pgroongaでは、pgroonga_normalize() という関数でノーマライズ処理だけを実施することができるようですが、このノーマライズ処理ではタブや改行を含む0x01～0x1fの制御文字が削除されるようです。
これは、意図した設計なのでしょうか？

ちょっと実験してみたのですが、Python や .NET の実装では削除されないようでした
（Python3.9のunicodedata.normalize()と、.NET6.0のString.Normalize()で確認）

Unicode公式の仕様を確認しようと思い、以下のサイトにたどりつき、見てみると

they may impose their own limitations, such as removing certain control

との記述があるので、「各実装におまかせします」の世界なのかもしれません

https://unicode.org/reports/tr15/#:~:text=they%20may%20impose,control

groongaリポジトリをダウンロードしてみたのですが、ノーマライズ処理部分のソースを見つけることができませんでした。。。

ここで聞くのが適切なのか分からないのですが、PGroongaのノーマライズ処理について、教えてください。

pgroongaでは、pgroonga_normalize() という関数でノーマライズ処理だけを実施することができるようですが、このノーマライズ処理ではタブや改行を含む0x01～0x1fの制御文字が削除されるようです。
これは、意図した設計なのでしょうか？

ちょっと実験してみたのですが、Python や .NET の実装では削除されないようでした
（Python3.9のunicodedata.normalize()と、.NET6.0のString.Normalize()で確認）

Unicode公式の仕様を確認しようと思い、以下のサイトにたどりつき、見てみると

they may impose their own limitations, such as removing certain control

との記述があったので、「各実装におまかせします」の世界なのかもしれません

https://unicode.org/reports/tr15/#:~:text=they%20may%20impose,control

groongaリポジトリをダウンロードしてみたのですが、ノーマライズ処理部分のソースを見つけることができませんでした。。。

ここで聞くのが適切なのか分からないのですが、PGroongaのノーマライズ処理について、どなたか教えてください。

pgroongaでは、pgroonga_normalize() という関数でノーマライズ処理だけを実施することができるようですが、このノーマライズ処理ではタブや改行を含む0x01～0x1fの制御文字が削除されるようです。
これは、意図した設計なのでしょうか？

ちょっと実験してみたのですが、Python や .NET の実装では削除されないようでした
（Python3.9のunicodedata.normalize()と、.NET6.0のString.Normalize()で確認）

Unicode公式の仕様を確認しようと思い、以下のサイトにたどりつき、見てみると

they may impose their own limitations, such as removing certain control

との記述があったので、「各実装におまかせします」の世界なのかもしれません

https://unicode.org/reports/tr15/#:~:text=they%20may%20impose,control

groongaリポジトリをダウンロードしてみたのですが、ノーマライズ処理部分のソースを見つけることができませんでした。。。

ここで聞くのが適切なのか分からないのですが、PGroongaのノーマライズ処理について、どなたか教えてください。

pgroongaでは、pgroonga_normalize() という関数でノーマライズ処理だけを実施することができるようですが、このノーマライズ処理ではタブや改行を含む0x01～0x1fの制御文字が削除されるようです。
これは、意図した設計なのでしょうか？

ちょっと実験してみたのですが、Python や .NET の実装では削除されないようでした
（Python3.9のunicodedata.normalize()と、.NET6.0のString.Normalize()で確認）

Unicode公式の仕様を確認しようと思い、以下のサイトにたどりつき、見てみると

they may impose their own limitations, such as removing certain control codes.

との記述があったので、「各実装におまかせします」の世界なのかもしれません

https://unicode.org/reports/tr15/#:~:text=they%20may%20impose,codes.

groongaリポジトリをダウンロードしてみたのですが、ノーマライズ処理部分のソースを見つけることができませんでした。。。

ここで聞くのが適切なのか分からないのですが、PGroongaのノーマライズ処理について、どなたか教えてください。

pgroongaでは、pgroonga_normalize() という関数でノーマライズ処理だけを実施することができるようですが、このノーマライズ処理ではタブや改行を含む0x01～0x1fの制御文字が削除されるようです。
これは、意図した設計なのでしょうか？

ちょっと実験してみたのですが、Python や .NET の実装では削除されないようでした
（Python3.9のunicodedata.normalize()と、.NET6.0のString.Normalize()で確認）

Unicode公式の仕様を確認しようと思い、以下のサイトにたどりつき、見てみると

they may impose their own limitations, such as removing certain control codes.

との記述があったので、「各実装におまかせします」の世界なのかもしれません

https://unicode.org/reports/tr15/#:~:text=they%20may%20impose,codes.

ソースも見てみようと、groongaリポジトリをダウンロードしてみたのですが、ノーマライズ処理部分のソースを見つけることができませんでした。。。

In reply to @ktou:matrix.org
意図した設計です。
表示できない文字は削除しています。
https://github.com/groonga/groonga/blob/master/lib/normalizer.c#L2963-L2964

削除して欲しくないユースケースがあるということですよね？
どういうケースですか？

PGroongaの本来の使い方から、外れてしまっているのを理解しつつなのですが、
もろもろの事情(※)から、PGroongaのインデックスを張らずにあいまい一致検索をするため、

where pgroonga_normalize(カラム) like pgroonga_normalize('検索値'+'%')

のような条件で検索しております。
ですが、あいう(改行)かきくやあいう(タブ)かきくに対して、あいうかがヒットする、という状況になっており、ちょびっとだけ困っておりました。

と、思ったら "remove_new_line" なるオプションがあるのですね！
これで、半分くらいは問題がクリアします。
＃ソース共有ありがとうございました。

がんばって修正して、PRするほどの困り具合ではないので、
今回はそういう仕様なんですねーっていうことで承知しました!!

早速のコメントありがとうございました🙇‍♂️

※ もろもろの事情：
pgroongaのインデックスが思ったよりもディスク容量を必要とすること、等価条件で1023文字(4096バイト)の制約があること、インデックスを利用しない実行計画の場合ノーマライズが働かないこと、などから、ノーマライズ処理だけを利用する方針としています。

In reply to @ktou:matrix.org
意図した設計です。
表示できない文字は削除しています。
https://github.com/groonga/groonga/blob/master/lib/normalizer.c#L2963-L2964

削除して欲しくないユースケースがあるということですよね？
どういうケースですか？

PGroongaの本来の使い方から、外れてしまっているのを理解しつつなのですが、
もろもろの事情(※)から、PGroongaのインデックスを張らずにあいまい一致検索をするため、

where pgroonga_normalize(カラム) like pgroonga_normalize('検索値') || '%'

のような条件で検索しております。
ですが、あいう(改行)かきくやあいう(タブ)かきくに対して、あいうかがヒットする、という状況になっており、ちょびっとだけ困っておりました。

と、思ったら "remove_new_line" なるオプションがあるのですね！
これで、半分くらいは問題がクリアします。
＃ソース共有ありがとうございました。

がんばって修正して、PRするほどの困り具合ではないので、
今回はそういう仕様なんですねーっていうことで承知しました!!

早速のコメントありがとうございました🙇‍♂️

※ もろもろの事情：
pgroongaのインデックスが思ったよりもディスク容量を必要とすること、等価条件で1023文字(4096バイト)の制約があること、インデックスを利用しない実行計画の場合ノーマライズが働かないこと、などから、ノーマライズ処理だけを利用する方針としています。

なるほどー

等価条件で1023文字(4096バイト)の制約がある

本当にそんなに長い文字列に対して等価条件が必要な場合は正規表現用のインデックスを作ることで対応できます。

インデックスを利用しない実行計画の場合ノーマライズが働かない

これは https://pgroonga.github.io/ja/reference/operators/query-v2.html とかにあるpgroonga_full_text_search_conditionとかを使ってインデックスを指定するとシーケンシャルサーチのときもノーマライズされます。

In reply to @ktou:matrix.org

なるほどー

等価条件で1023文字(4096バイト)の制約がある

本当にそんなに長い文字列に対して等価条件が必要な場合は正規表現用のインデックスを作ることで対応できます。

インデックスを利用しない実行計画の場合ノーマライズが働かない

これは https://pgroonga.github.io/ja/reference/operators/query-v2.html とかにあるpgroonga_full_text_search_conditionとかを使ってインデックスを指定するとシーケンシャルサーチのときもノーマライズされます。

そうなんです。

実は話を端折ってしまったのですが、正規表現用のインデックスでは pgroonga_full_text_search_condition を指定できないこと、等価条件ではバイト数制限があること、から、全文検索インデックスだけ作って、↓のように等価判定を行う方式にしよう、と思ったこともあったのです。
＃ 前半の条件が等価条件で、後半の条件が一次絞り込み(速度改善)のための全文検索。

prroonga_normalize(カラム) = pgroonga_normalize('検索値') and カラム &@~ ('検索値', NULL, インデックス名)

でも、速度改善とディスク容量(+更新速度)を天秤にかけた結果、後半部分が無くなり今に至る、という状況でございます。

正規表現でもpgroonga_full_text_search_conditionを使えるようにするのが王道ですよねぇ。

ちなみに、ディスク容量ってどのくらい食っていました？
めちゃめちゃテキストデータが大きいんですか？
4KiB以上のテキストがゴロゴロあるのがにわかに信じがたいのですが。。。

ちなみに、ディスク容量ってどのくらい食っていました？

120のカラムに対して3つずつ(等価、全文、正規表現)インデックスを張って100MB → 10GB くらいです（スパースファイルの仮想サイズではなく実サイズで）
すいません。レコード数までは見ませんでした。

4KiB以上のテキストがゴロゴロあるのがにわかに信じがたいのですが。。。

無いです。全然無いです。

もともとのカラム定義が varchar(1024)となっていただけで、実際に入っているデータは数文字から数十文字くらいまでです。
ただ、大きかったものを小さくするっていうのは、怖くて手が出せなかった感じです。

数GBがしんどい

これ、私も思うところはいろいろあるんですが、、、諸事情です 😭

あと、正規表現を使う時は検索する値をエスケープしてあげないといけないところも少し課題になったところでした。
（こちらは、解決できない類の課題では無いですが、シンプルにしたいなぁ、、、と）

うーん、pgroonga.logにバックトレースとかもっとなにかあるはずなんですよねぇ。
これ以上の情報がないということであればちょっとこれ以上は助けになれそうにありません。
スキーマやデータ量を聞いたらなにかヒントがあるかもしれませんが、データに依存していると思うので、望み薄な気はします。。。

NDAを結んだ上であれば追加情報を提供できるということであれば、有償サポートをご検討ください。
https://www.clear-code.com/services/groonga.html

あ、pgpoolが関係している可能性は非常に低いと思います。

うーん、pgroonga.logにバックトレースとかもっとなにかあるはずなんですよねぇ。
これ以上の情報がないということであればちょっとこれ以上は助けになれそうにありません。
データに依存していると思うので、スキーマやデータ量を聞いたらなにかヒントがあるかもしれませんが、望み薄な気はします。。。

NDAを結んだ上であれば追加情報を提供できるということであれば、有償サポートをご検討ください。
https://www.clear-code.com/services/groonga.html

あ、pgpoolが関係している可能性は非常に低いと思います。