BloGroonga

2024-03-14

Groonga 14.0.1リリース

Groonga 14.0.1をリリースしました!

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

変更内容

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

改良

  • [load] ノーマライズによって空のキーとなったキーをloadする時のエラーを止めました。

    "-"は、NormalizerNFKC150("remove_symbol", true)によって""になります。 そのため、以下のケースでは"empty key"エラーが報告されます。

    table_create Values TABLE_HASH_KEY ShortText \
      --normalizers 'NormalizerNFKC150("remove_symbol", true)'
    table_create Data TABLE_NO_KEY
    column_create Data value COLUMN_SCALAR Values
    load --table Data
    [
    {"value": "-"}
    ]
    

    しかし、このようなデータを大量にloadした場合、多くのエラーログが生成されます。 Groongaは空の文字列をインデックスに登録できないため、"empty key"エラーを大量に出力するためです。

    ただ、このようなケースで空の文字列がインデックスへ登録できなくても問題ありません。 空の文字列で検索しても何も一致しないためです。そのため、このようなケースの時に"empty key"エラーを報告するのを止めました。

修正

  • [between] または、範囲検索時にリクエストキャンセルするとGroongaがクラッシュする問題を修正しました。

    この問題は必ず発生するわけではありません。特定のタイミングでリクエストキャンセルをすると発生します。 シーケンシャルサーチなどの検索時間が長い場合に発生しやすいです。

  • 以下の条件を満たした時に highlight_html が正しくない結果を返すことがあります。

    • NormalizerTableNormalizerNFKC150のように複数のノーマライザーを使っている。
    • 空白を含む文字列をハイライトする。

    例えば、以下のようなケースでこの問題は発生します。

    table_create NormalizationsIndex TABLE_PAT_KEY ShortText --normalizer NormalizerAuto
    
    table_create Normalizations TABLE_HASH_KEY UInt64
    column_create Normalizations normalized COLUMN_SCALAR LongText
    column_create Normalizations target COLUMN_SCALAR NormalizationsIndex
    
    column_create NormalizationsIndex index COLUMN_INDEX Normalizations target
    
    
    table_create Lexicon TABLE_PAT_KEY ShortText \
      --normalizers 'NormalizerTable("normalized", \
                                     "Normalizations.normalized", \
                                     "target", \
                                     "target"), NormalizerNFKC150'
    
    table_create Names TABLE_HASH_KEY UInt64
    column_create Names name COLUMN_SCALAR Lexicon
    
    load --table Names
    [
    ["_key","name"],
    [1,"Sato Toshio"]
    ]
    
    select Names \
      --query '_key:1 OR name._key:@"Toshio"' \
      --output_columns 'highlight_html(name._key, Lexicon)
    
    [
      [
        0,
        1710401574.332274,
        0.001911401748657227
      ],
      [
        [
          [
            1
          ],
          [
            [
              "highlight_html",
              null
            ]
          ],
          [
            "sato <span class=\"keyword\">toshi</span>o"
          ]
        ]
      ]
    ]
    
  • [Ubuntu] Ubuntu向けパッケージを提供できるようになりました。

    Groonga 14.0.0では、GroongaのUbuntu向けパッケージを提供していませんでした。 Ubuntu向けパッケージのビルド環境の問題で、パッケージを作るのに失敗したためです。

    14.0.1でこの問題を修正したので、今回のリリースからGroongaのUbuntu向けパッケージを提供できるようになりました。

  • clangを使ってソースからビルドした時にビルドエラーになる問題を修正しました。

2024-02-29

Groonga 14.0.0リリース

Groonga 14.0.0をリリースしました!

メジャーバージョンアップです! メジャーバージョンアップですが、互換性は壊れていないので、データベースを再構築することなく14.0.0へアップグレードできます!

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

変更内容

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

改良

  • 新しいトークナイザーTokenH3Indexを追加しました。(実験的)

    TokenH3Indexは、WGS84GetPointUInt64(H3 index)にトークナイズします。

  • 非テキストベースのトークナイザーを使ったインデックスのオンライン構築とオフライン構築をサポートしました。(実験的)

    TokenH3Index は、非テキストベースのトークナイザーの一つです。

  • [select] 非テキストベースのトークナイザーを使ったインデックスでの検索をサポートしました。(実験的)

    TokenH3Index は、非テキストベースのトークナイザーの一つです。

  • 新しい関数 distance_cosine(), distance_inner_product(), distance_l2_norm_squared(), distance_l1_norm() を追加しました。

    これらの関数とlimit Nを使うことで、ベクトル的に距離の近いレコードのみを取得することができます。

    これらの関数は、outputステージで距離を計算します。ただ、これらの関数はまだ最適化できていません。

    • distance_cosine(): コサイン類似度を計算します。
    • distance_inner_product(): 内積を計算します。
    • distance_l2_norm_squared(): ユークリッド距離を計算します。
    • distance_l1_norm(): マンハッタン距離を計算します。
  • 新しい関数number_round()を追加しました。

  • [load] loadを並列に実行できるようになりました。

    この機能は、loadinput_typeapache-arrowの時のみ有効です。

    この機能は、一つのカラムに対し一つのスレッドを割り当てます。対象のカラムがたくさんある時に、ロード時間の短縮が期待できます。

  • [select] --filter内で配列リテラルをなるべく、uvectorとして使えるようにしました。

    uvectorは、要素が固定長サイズのベクターです。 すべての要素の型が同じ場合、ベクターの変わりにuvactorを使えます。

  • [status] statusの結果にn_workersを追加しました。

  • 動的カラムの作成を最適化しました。

  • [WAL] 壊れたインデックスの再構築を並列で実行できるようになりました。

  • [select] output_type=apache-arrowの時に、_keyInt64型のテーブルへの参照カラムを表示できるようにしました。

修正

  • [Windows] Windows向けパッケージ内のgroonga-normalizer-mysqlのドキュメントのパスを修正しました。

    Documents of groonga-normalizer-mysql put under the share/ in this release.

  • [select] ビットごとの演算を行うとGroongaがクラッシュすることがある問題を修正しました。

2024-01-10

PostgreSQL用高速日本語全文検索モジュールPGroonga(ぴーじーるんが) 3.1.6リリース

PostgreSQLで高速日本語全文検索をできるようにするPGroongaの3.1.6をリリースしました!

ハイライト

今回のリリースの主な変更点は下記の通りです。

改良

  • 新しいオプション pgroonga.enable_row_level_security を追加しました。

    PGroongaのRLS(Row level security)サポートの有効/無効を設定できます。デフォルト値は有効です。 PGroongaのRLSサポートを無効にすることでパフォーマンスが向上するかもしれません。 しかし、PostgreSQLのRLS機能を使っている環境ではPGroongaのRLSサポートを無効にしてはいけません。無効にするとセキュリティーのリスクがあります。

    したがって、このオプションを使ってPGroongaのRLSサポートを無効にする場合は、事前にPostgreSQLのRLS機能を使っていないことを十分に確認してください。

    特定のセッションで一時的に設定をする場合は、下記のSQLで有効/無効を切り替えられます。

    • RLSサポートを無効にする場合

      SET pgroonga.enable_row_level_security = off
      
    • RLSサポートを有効にする場合

      SET pgroonga.enable_row_level_security = on
      

      設定を永続化する場合は、PostgreSQLの設定ファイルに以下のように記載してください。

    • RLSサポートを無効にする場合

      pgroonga.enable_row_level_security = off
      
    • RLSサポートを有効にする場合

      pgroonga.enable_row_level_security = on
      
  • 新しい型 pgroonga_condition を追加しました。関連して、新しい関数 pgroonga_condition() を追加しました。

    pgroonga_full_text_search_condition 型と pgroonga_full_text_search_condition_with_scorers 型は非推奨になります。 上記の型の代わりに、 pgroonga_condition を使ってください。

    pgroonga_full_text_search_condition 型と pgroonga_full_text_search_condition_with_scorers 型を使った クエリーは以下のように変化します。

    (変更前):

    column &@~ ('query', weights, 'scorers', index_name)::pgroonga_full_text_search_condition_with_scorers
    column &@~ ('query', weights, index_name)::pgroonga_full_text_search_condition
    

    (変更後):

    column &@~ pgroonga_conditon('query', weights, 'scorers', index_name => 'index_name')
    column &@~ pgroonga_conditon('query', weights, index_name => 'index_name')
    

    'index_name' は、index_name => 'index_name' のように 引数名 => '値' の形式で指定する必要があることに注意してください。 なぜ、 'index_name' をこのように指定しなければならないのかを解説します。

    pgroonga_condition() のシグネチャーは以下の通りで、指定が不要な引数は省略可能です。 引数を省略すると、どの位置になんの引数があるのかがわからなくなります。そのため、以下のシグネチャーと引数の位置が異なるものについては 引数名 => '値' の形式で書くことで、なんの引数の値なのかを指定します。

      pgroonga_condition(query text,
                         weights int[],
                         scorers text[],
                         schema_name text,
                         index_name text,
                         column_name text)
    
  • [開発者向け] ビルド環境をセットアップするスクリプトを新しく追加しました。 [GitHub#358][askdkcさんがパッチ提供]

    以下のように使用します。 Debian/Ubuntu環境で動作します。AlmaLinuxなどのRed Hat Enterprise Linux派生のディストリビューションでは動作しません。

      $ git clone https://github.com/pgroonga/pgroonga.git
      $ cd pgroonga
      $ ./setup.sh #PGroongaをビルドする環境を作ります。
      $ ./build.sh SOURCE_DIRECTORY BUILD_DIRECTORY #PGroongaをビルドします。
    

修正

  • PGroongaを2.4.1から2.4.2へバージョンアップすると、 pgroonga_snippet_html() が使えなくなる問題を修正しました。[takadatさんの報告]

  • pgroonga_query_expand() の第一引数にPostgreSQLの通常のテーブル以外を指定すると、PGroongaがクラッシュする問題を修正しました。

    例えば、以下のように pgroonga_query_expand() の第一引数に外部テーブルを指定すると、PGroongaはクラッシュします。

    CREATE EXTENSION IF NOT EXISTS postgres_fdw;
    
    CREATE SERVER remote_server
        FOREIGN DATA WRAPPER postgres_fdw
        OPTIONS (host 'localhost', port '5432', dbname 'remote_database');
    
    CREATE FOREIGN TABLE synonym_groups (
      synonyms text[]
    ) SERVER remote_server;
    
    SELECT pgroonga_query_expand('synonym_groups',
                                 'synonyms',
                                 'synonyms',
                                 'groonga');
    
    server closed the connection unexpectedly
    	This probably means the server terminated abnormally
    	before or while processing the request.
    The connection to the server was lost. Attempting reset: Failed.
    
  • PGroonga内で多くのエラーが発生した場合、エラー情報を記録するスタックを使い果たしてPostgreSQLがPANICを起こす問題を修正しました。

    この問題は、PGroonga 2.3.3以降で発生します。

感謝

  • askdkcさん
  • takadatさん

アップグレード方法

2.0.0以降を使っている場合はアップグレードの「互換性がある場合」用の手順でアップグレードしてください。

1.Y.Zを使っている場合はアップグレードの「非互換の場合」用の手順でアップグレードしてください。 PGroonga 1系と3系は互換性が無いためです。

サポートサービス

PGroongaのサポートサービスを提供しています。インデックスや検索の設計方法に関するコンサルティングやトラブル時の調査、パフォーマンス改善・新機能追加などの技術支援など、PGroongaに関わるサポートが必要な場合はご相談ください。

まとめ

PostgreSQLで高速に日本語全文検索をしたいという方はPGroongaを使ってガンガン検索してください!

2024-01-09

Groonga 13.1.1リリース

Groonga 13.1.1をリリースしました!

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

変更内容

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

改良

  • MinGW32 でビルドしているWindowsパッケージのサポートをやめました。 [GitHub#1654]

  • --match_columns--query の組み合わせで vector_column[N] OPERATOR literal をサポートしました。

    --filter では以前から vector_column[N] OPERATOR literal でベクターカラムの特定の特定の要素にマッチさせることができましたが 今回のリリースで --match_columns--query の組み合わせでもできるようになりました。

修正

  • [Windows] groonga-normalizer-mysql をバンドルしました。 [GitHub#1655]

    Windows版のGroonga 13.1.0に groonga-normalizer-mysql が含まれていませんでした。 この問題はGroonga13.1.0でのみ発生します。

2023-12-26

Groonga 13.1.0リリース

Groonga 13.1.0をリリースしました!

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

変更内容

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

改良

  • [select] トレースログもキャッシュするようにしました。

  • Apache Arrow フォーマットの応答で dict<string> の出力をサポートしました。

  • [Groonga HTTPサーバー] 新しい content type application/vnd.apache.arrow.stream をサポートしました。

  • [query] 以下のような空の入力をサポートしました。

    table_create Users TABLE_NO_KEY
    column_create Users name COLUMN_SCALAR ShortText
    
    table_create Lexicon TABLE_HASH_KEY ShortText   --default_tokenizer TokenBigramSplitSymbolAlphaDigit   --normalizer NormalizerAuto
    column_create Lexicon users_name COLUMN_INDEX|WITH_POSITION Users name
    load --table Users
    [
    {"name": "Alice"},
    {"name": "Alisa"},
    {"name": "Bob"}
    ]
    
    select Users   --output_columns name,_score   --filter 'query("name", "  	")'
    [
      [
        0,
        0.0,
        0.0
      ],
      [
        [
          [
            0
          ],
          [
            [
              "name",
              "ShortText"
            ],
            [
              "_score",
              "Int32"
            ]
          ]
        ]
      ]
    ]
    
  • BFloat16をサポートしました。(実験的)

    BFloat16のloadとselectができるだけです。 bfloat16_value - 1.2 のような算術演算はできません。

  • [column_create] 新しいフラグ WEIGHT_BFLOAT16 を追加しました。

修正

  • [select] Groonga が output_pretty=yes の結果をキャッシュした場合、 output_pretty をつけていないクエリーであっても、 output_pretty をつけて返してしまう問題を修正しました。

  • 誤ったデータを作り出してしまう問題を修正しました。

    通常、ユーザーはこれを明示的に実行できません。 数値の動的カラムや一時結果セットが作られたとき、あるいは使われているとき、かつ クエリーに OR を使っている場合に内部的に発生することがあります。

    例えば、以下のクエリーで誤ったデータを作り出すことがあります。

    select TABLE \
      --match_columns TEXT_COLUMN \
      --query 'A B OR C' \
      --columns[NUMERIC_DYNAMIC_COLUMN].stage result_set \
      --columns[NUMERIC_DYNAMIC_COLUMN].type Float32 \
      --columns[NUMERIC_DYNAMIC_COLUMN].flags COLUMN_VECTOR
    

    もしこの問題が起こった場合は、 NUMERIC_DYNAMIC_COLUMN は多くのごみ要素を含んでいます。そして、それは多くのメモリー消費の原因にもなります。

    この問題はスタック上の未初期化の変数が原因です。そのため、発生するかもしれないし、しないかもしれないことに注意してください。

  • 有効な normalizers/token_filters の設定が失敗することがある問題を修正しました。

  • [fuzzy_search] 以下の3つの条件が成立した時にクラッシュする問題を修正しました。

    1. クエリーが2つまたはそれ以上のマルチバイト文字を持っている場合。

    2. ${ASCII}${ASCII}${MULTIBYTE}* という形の文字列がパトリシアトライのテーブルにある場合。

    3. WITH_TRANSPOSITION が有効な場合。

    例えば、以下のようにパトリシアトライのテーブル内にある"aaあ"とクエリー"あiう"のペアは問題を起こします。

    table_create Users TABLE_NO_KEY
    column_create Users name COLUMN_SCALAR ShortText
    
    table_create Names TABLE_PAT_KEY ShortText
    column_create Names user COLUMN_INDEX Users name
    load --table Users
    [
    {"name": "aaあ"},
    {"name": "あうi"},
    {"name": "あう"},
    {"name": "あi"},
    {"name": "iう"}
    ]
    select Users \
      --filter 'fuzzy_search(name, "あiう", {"with_transposition": true, "max_distance": 3})' \
      --output_columns 'name, _score' \
      --match_escalation_threshold -1