BloGroonga

2022-10-03

Groonga 12.0.8リリース

Groonga 12.0.8をリリースしました！

それぞれの環境毎のインストール方法: インストール

変更内容

主な変更点は以下の通りです。

改良

  • escalate() 関数（実験的）の仕様を使いやすいように変更しました。

    escalate() の外部の結果セットを使用しないように変更しました。

    前回の仕様では、ユーザーはどのくらいの結果が escalate() に渡されるのか推測して最初のしきい値を決める必要があり、不便でした。

    以下は前回の escalate() の例です。

    number_column > 10 && escalate(THRESHOLD_1, CONDITION_1,
                               ...,
                               THRESHOLD_N, CONDITION_N)

    CONDITION1 は number_column > 10 の結果が THRESHOLD_1 以下の時に実行されます。 ユーザーは THRESHOLD_1 を決めるのに number_column > 10 がどのくらいの結果を返すのか推測する必要がありました。

    今回のリリースから、ユーザーが number_column > 10 がどのくらいの結果を返すのか推測する必要がなくなり、使いやすくなりました。

    この変更により、 escalate() の構文が以下の通り変更されています。

    前回の構文

    escalate(THRESHOLD_1, CONDITION_1,THRESHOLD_2, CONDITION_2, ..., THRESHOLD_N, CONDITION_N)

    新しい構文

    escalate(CONDITION_1, THRESHOLD_2, CONDITION_2, ..., THRESHOLD_N, CONDITION_N)

    以下は構文の変更の詳細です。

    • 最初の条件のためのしきい値は不要となりました。
    • 引数の指定を必須としました。最初の条件が必須となります。
    • 最初の引数を常に実行します。

    この関数は実験的な関数です。将来的にこれらの動作は変更になる可能性があります。

  • cmake CMakeを使ってビルドする方法を追加しました。

  • others GNU Autotoolsを使ってビルドする場合に、Apache Arrowの機能を有効化/無効化する方法について追加しました。

  • select drilldowns.table のドキュメントを追加しました。

  • i18n 翻訳方法を更新しました。

改良

  • NormalizerTable で冪等でない（繰り返し実行すると結果が変わることがある） 定義をした時に、Groongaが誤った結果を返すことがある問題を修正しました。

    これは、検索する値について、値を受け取った後と、トークナイズした後の二回ノーマライズしていたことが原因です。

    Groongaはレコードを追加する時に、インデックス用のテーブルに設定したトークナイザーとノーマライザーを使って、登録するデータをトークナイズしてからノーマライズしています。 検索する値についても、インデックス用のテーブルに設定したトークナイザーとノーマライザーを使って、トークナイズしてからノーマライズして、その後インデックスと照合します。 両者は同じトークナイザーとノーマライザーを使うので、検索する値がインデックスに登録したデータと同じであれば、インデックスに格納されている状態と同じ状態になります。

    しかし、いままでGroongaは検索する値だけを余分にノーマライズしていました。

    NormalizerAutoといった組み込みのノーマライザーは冪等である（繰り返し実行しても結果が変わらない）ため、この問題は発生しません。 一方で、NormalizerTableはユーザー自身がノーマライザーの定義をすることができます。 そのため、冪等でない（繰り返し実行すると結果が変わることがある）定義をすることができました。

    NormalizerTableに冪等でない定義が存在する場合、検索する値のみが余分にノーマライズされることで、インデックスに登録したデータと検索する値が一致しない場合がありました。

    そのような場合、ヒットするはずのデータがヒットしなかったり、ヒットしないはずのデータがヒットしたりしていました。

    以下はこの問題の例です。

    table_create ColumnNormalizations TABLE_NO_KEY
column_create ColumnNormalizations target_column COLUMN_SCALAR ShortText
column_create ColumnNormalizations normalized COLUMN_SCALAR ShortText

load --table ColumnNormalizations
[
{"target_column": "a", "normalized": "b"},
{"target_column": "b", "normalized": "c"}
]

table_create Targets TABLE_PAT_KEY ShortText
column_create Targets column_normalizations_target_column COLUMN_INDEX \
  ColumnNormalizations target_column

table_create Memos TABLE_NO_KEY
column_create Memos content COLUMN_SCALAR ShortText

load --table Memos
[
{"content":"a"},
{"content":"c"},
]

table_create \
  Terms \
  TABLE_PAT_KEY \
  ShortText \
  --default_tokenizer 'TokenNgram' \
  --normalizers 'NormalizerTable("normalized", \
                                "ColumnNormalizations.normalized", \
                                "target", \
                                "target_column")'

column_create Terms memos_content COLUMN_INDEX|WITH_POSITION Memos content

select Memos --query content:@a
[[0,1664781132.892326,0.03527212142944336],[[[1],[["_id","UInt32"],["content","ShortText"]],[2,"c"]]]]

    select Memos --query content:@a の結果の期待値は a ですが、Groongaは c を返していました。 これは、入力された a が ColumnNormalizations の定義にしたがって b にノーマライズされ、その後、ノーマライズされた b を更に c にノーマライズしていたためです。 結果的に、入力された a は c に変換され、 Memos テーブルの {\"content\":\"c\"} にマッチしていました。

既知の問題

  • 現在Groongaには、ベクターカラムに対してデータを大量に追加、削除、更新した際にデータが破損することがある問題があります。

  • *< と *> は、filter条件の右辺に query() を使う時のみ有効です。もし、以下のように指定した場合、 *< と *> は && として機能します。

    'content @ "Groonga" *< content @ "Mroonga"'

  • GRN_II_CURSOR_SET_MIN_ENABLE が原因でマッチするはずのレコードを返さないことがあります。

さいごに

詳細については、以下のお知らせ、リリース自慢会も参照してください。

お知らせ 12.0.8リリース

リリース自慢会

リリース自慢会は、リリースノートを見ながら、Groongaの新機能・バグ修正を開発者が自慢する会です。

毎月リリースされている最新バージョンについて、開発者的に「これ！」という機能や、「ここをがんばった！」ということを紹介しています。 Liveチャットでコメントも受け付けていますので、気になっていることを質問したり、気になっていたあの機能について聞いたりすることも可能です。

それでは、Groongaでガンガン検索してください！