BloGroonga

2022-04-29

Groonga 12.0.3リリース

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

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

変更内容

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

改良

  • logical_count logical_count 実行中のメモリー使用量を改善しました。

    いままで、Groongaは logical_count 実行中に確保したオブジェクト(オブジェクトとは、テーブルやカラム、インデックスなどです。)と一時テーブルを logical_count の実行完了まで保持し続けていました。

    この機能によって、Groongaは、1つのシャードを処理した後すぐに参照を減らします。 そのため、Groongaは、 logical_count の実行中にメモリーを解放できるようになり、Groongaのメモリー使用量を削減できることがあります。

    この機能は参照カウントモードのときのみ有効です。 GRN_ENABLE_REFERENCE_COUNT=yes と設定することで、参照カウントモードを有効にできます。

    加えて、Groongaは、この機能によって logical_count 実行中に一時テーブルを動的に解放します。 そのため、Groongaのメモリー使用量を削減できます。この改善は、参照カウントモードが有効でなくても効果があります。

  • dump MISSING_IGNORE/MISSING_NIL をサポートしました。

    MISSING_IGNORE/MISSING_NIL を持つカラムがある場合、これらのカラムのダンプに失敗していました。このリリースから、 dump コマンドはこれらのカラムをサポートしました。

  • snippet,snippet_html 入力としてベクターをサポートしました。

    例えば、以下のようにJSONデータ内のベクターに対して検索キーワードの周辺テキストを抽出できます。

       table_create Entries TABLE_NO_KEY
       column_create Entries title COLUMN_SCALAR ShortText
       column_create Entries contents COLUMN_VECTOR ShortText
    
       table_create Tokens TABLE_PAT_KEY ShortText   --default_tokenizer TokenNgram   --normalizer NormalizerNFKC130
       column_create Tokens entries_title COLUMN_INDEX|WITH_POSITION Entries title
       column_create Tokens entries_contents COLUMN_INDEX|WITH_SECTION|WITH_POSITION   Entries contents
    
       load --table Entries
       [
       {
         "title": "Groonga and MySQL",
         "contents": [
           "Groonga is a full text search engine",
           "MySQL is a RDBMS",
           "Mroonga is a MySQL storage engine based on Groonga"
         ]
       }
       ]
    
       select Entries\
         --output_columns 'snippet_html(contents), contents'\
         --match_columns 'title'\
         --query Groonga
       [
         [
           0,
           0.0,
           0.0
         ],
         [
           [
             [
               1
             ],
             [
               [
                 "snippet_html",
                 null
               ],
               [
                 "contents",
                 "ShortText"
               ]
             ],
             [
               [
                 "<span class=\"keyword\">Groonga</span> is a full text search engine",
                 "Mroonga is a MySQL storage engine based on <span class=\"keyword\">Groonga</span>"
               ],
               [
                 "Groonga is a full text search engine",
                 "MySQL is a RDBMS",
                 "Mroonga is a MySQL storage engine based on Groonga"
               ]
             ]
           ]
         ]
       ]
    

    今までも、 --output_columns 'snippet_html(contents[1])' のように snippet* を指定することで以下のようにベクターに対して検索キーワードの周辺テキストを抽出できますが、この方法ではどの要素を出力すればよいかわかりません。どの要素が検索にヒットしたかわからないためです。

       select Entries\
         --output_columns 'snippet_html(contents[0]), contents'\
         --match_columns 'title'\
         --query Groonga
       [
         [
           0,
           0.0,
           0.0
         ],
         [
           [
             [
               1
             ],
             [
               [
                 "snippet_html",
                 null
               ],
               [
                 "contents",
                 "ShortText"
               ]
             ],
             [
               [
                 "<span class=\"keyword\">Groonga</span> is a full text search engine"
               ],
               [
                 "Groonga is a full text search engine",
                 "MySQL is a RDBMS",
                 "Mroonga is a MySQL storage engine based on Groonga"
               ]
             ]
           ]
         ]
       ]
    
  • [vector_join] 新しい関数 vector_join() を追加しました。

    この関数は各要素を結合します。この関数の第二引数で区切り文字を指定できます。 例えば、以下のようにベクターに対して snippet()snippet_html() を実行できます。

       plugin_register functions/vector
    
       table_create Entries TABLE_NO_KEY
       column_create Entries title COLUMN_SCALAR ShortText
       column_create Entries contents COLUMN_VECTOR ShortText
    
       table_create Tokens TABLE_PAT_KEY ShortText   --default_tokenizer TokenNgram   --normalizer NormalizerNFKC130
       column_create Tokens entries_title COLUMN_INDEX|WITH_POSITION Entries title
       column_create Tokens entries_contents COLUMN_INDEX|WITH_SECTION|WITH_POSITION   Entries contents
    
       load --table Entries
       [
       {
         "title": "Groonga and MySQL",
         "contents": [
           "Groonga is a full text search engine",
           "MySQL is a RDBMS",
           "Mroonga is a MySQL storage engine based on Groonga"
         ]
       }
       ]
    
       select Entries\
         --output_columns 'snippet_html(vector_join(contents, "\n")), contents'\
         --match_columns 'title'\
         --query Groonga --output_pretty yes
       [
         [
           0,
           1650849001.524027,
           0.0003361701965332031
         ],
         [
           [
             [
               1
             ],
             [
               [
                 "snippet_html",
                 null
               ],
               [
                 "contents",
                 "ShortText"
               ]
             ],
             [
               [
                 "<span class=\"keyword\">Groonga</span> is a full text search engine\nMySQL is a RDBMS\nMroonga is a MySQL storage engine based on <span class=\"keyword\">Groonga</span>"
               ],
               [
                 "Groonga is a full text search engine","MySQL is a RDBMS","Mroonga is a MySQL storage engine based on Groonga"
               ]
             ]
           ]
         ]
       ]
    
  • インデックス構築 動的インデックス構築のようにとても大きなトークンを無視するようにしました。

    Groongaはエラーを発生しなくなり、静的インデックス構築を実行する時に大きなトークンを無視し警告を出力します。

修正

  • パトリシアトライのテーブルにキーを追加できなくなることがある問題を修正しました。

    この問題は、以下の条件で発生します。

    • パトリシアトライのテーブルにすでにキーがある場合。
    • 4096バイトのキーを追加する場合。

既知の問題

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

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

    'content @ "Groonga" *< content @ "Mroonga"'
    
  • GRN_II_CURSOR_SET_MIN_ENABLE が原因でマッチするはずのレコードを返さないことがあります。

さいごに

詳細については、以下のお知らせも参照してください。

お知らせ 12.0.3リリース

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

2022-03-29

Groonga 12.0.2リリース

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

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

変更内容

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

改良

  • logical_range_filter シャードを処理した直後に参照を減らすようにしました。

    今までGroongaは、 logical_range_filter 終了時にすべてのシャードの参照を減らしていました。この機能によって、Groongaは、シャードを処理した後すぐに参照を減らします。この機能によって、 logical_range_filter 実行中のメモリー使用量を削減できることがあります。

    この機能は参照カウントモードのときのみ有効です。 GRN_ENABLE_REFERENCE_COUNT=yes と設定することで、参照カウントモードを有効にできます。

    通常、Groongaは一度でも開いたオブジェクト(テーブル、カラム、インデックスなど)をメモリ上に保持し続けますが、たくさんのオブジェクトを開いた場合、Groongaはたくさんのメモリーを使用します。参照カウントモードでは、どこからも参照されてないオブジェクトをメモリーから開放します。これにより、Groongaのメモリー使用量が減ることがあります。

  • クラッシュリカバリー機能の安定性が向上しました。

    この機能は実験的で、デフォルトで無効です。したがって、以下の改良は。一般的なユーザーには影響ありません。

    • Groongaがクラッシュしたときにインデックスが破損する問題を修正しました。
    • ロックが残留する問題を修正しました。
    • クラッシュリカバリー中にGroongaがクラッシュする問題を修正しました。
  • 無名マッピングが利用可能な時のmmapのパフォーマンスを向上しました。

    この改善によって、Groongaのパフォーマンスが少し向上します。

  • インデックス構築 以下のタイプのカラムで静的インデックス構築をサポートしました。サポートしました。

    • 非参照重み付きベクターカラム
    • 参照重み付きベクターカラム
    • 参照スカラーカラム

    これらのカラムは、いままで、静的インデックス構築をサポートしていませんでした。そのため、これらのカラムにデータをロードしたあとに、インデックスを構築しても、インデックスの構築時間が長くなっていました。この改良によって、このケースでインデックス構築時間が短くなります。

  • column_create 新しいフラグ MISSING_*INVALID_* を追加しました。

    column_create に以下の新しいフラグを追加しました。

    • MISSING_ADD
    • MISSING_IGNORE
    • MISSING_NIL
    • INVALID_ERROR
    • INVALID_WARN
    • INVALID_IGNORE

    通常、データカラムが参照データカラムで存在しないキーを指定された場合、自動的に存在しないキーを作成し、新しいレコードを作ります。 このGroongaが参照先のカラムにキーを自動的に追加する挙動は、タグ検索のような検索で便利です。Groongaがロード時に自動的にデータを追加してくれるためです。

    しかしながら、この挙動は、キー以外の値が必要な場合に不便です。キーしか存在しないレコードがあるためです。 このリリースで追加したフラグを使ってこの挙動を変更できます。

    • MISSING_ADD: デフォルト値です。現在と同じ挙動になります。

      データカラムが参照データカラムで、存在しないキーを指定された場合、自動的にキーを作成し、新しいレコードを追加します。

    • MISSING_IGNORE:

      データカラムが参照データカラムで、存在しないキーを指定された場合、存在しないキーを無視します。参照データカラムがスカラーカラムの場合、値は GRN_ID_NIL になります。参照データカラムがベクターカラムの場合、以下のようにその要素のみを無視します。

      ["existent1", "nonexistent", "existent2"] ->
      ["existent1" "existent2"]
      
    • MISSING_NIL:

      データカラムが参照データカラムで、存在しないキーを指定された場合、スカラーカラムとベクターカラムは存在しないキーを GRN_ID_NIL として扱います。

      ["existent1", "nonexistent", "existent2"] ->
      ["existent1", "" (GRN_ID_NIL), "existent2"]
      
    • INVALID_ERROR: デフォルト値です。 ベクターカラムのエラー応答を除いて、現在と同じ挙動になります。

      無効な値を設定した場合(e.g.: XXX for UInt8 scalar column)、設定操作をエラーとして扱います。データカラムがスカラーカラムの場合、 load は応答とログにエラーを報告します。データカラムがベクターカラムの場合、 load はログにエラーを報告しますが、応答にエラーを報告しません。これは非互換の変更です。

    • INVALID_WARN:

      無効な値を設定した場合(e.g.: XXX for UInt8 scalar column)、警告メッセージをログに記録し、設定操作を無視します。対象のデータカラムが参照ベクターカラムの場合、 MISSING_IGNOREMISSING_NIL を使って挙動を決定します。

    • INVALID_IGNORE:

      無効な値を設定した場合(e.g.: XXX for UInt8 scalar column)、設定操作を無視します。対象のデータカラムが参照ベクターカラムの場合、 MISSING_IGNOREMISSING_NIL を使って挙動を決定します。

  • dump column_list MISSING_*INVALID_* フラグをサポートしました。

    これらのコマンドは、後方互換性を維持するため、 MISSING_ADDINVALID_ERROR フラグを表示しません。これらのフラグはデフォルトの挙動を表すためです。

  • schema MISSING_* と INVALID_* フラグをサポートしました。

    後方互換性を維持するため、 MISSING_ANDINVALID_ERROR フラグを flag に表示しませんがそれぞれのカラムに、新しく missinginvalid キーが追加されます。

  • Amazon Linux 2 向けのパッケージを提供するようにしました。

  • [Windows] Visual Studio 2017 でのビルドをやめました。

    GitHub Actionsで windows-2016 のイメージが使えなくなったためです。

既知の問題

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

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

    'content @ "Groonga" *< content @ "Mroonga"'
    
  • GRN_II_CURSOR_SET_MIN_ENABLE が原因でマッチするはずのレコードを返さないことがあります。

さいごに

詳細については、以下のお知らせも参照してください。

お知らせ 12.0.2リリース

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

2022-02-28

Groonga 12.0.1リリース

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

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

変更内容

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

改良

  • query_expand 同義語グループをサポートしました。

    同義語検索をする場合、今までは、以下のようにキーワードとその同義語をそれぞれ定義していました。

    table_create Thesaurus TABLE_PAT_KEY ShortText --normalizer NormalizerAuto
    # [[0, 1337566253.89858, 0.000355720520019531], true]
    column_create Thesaurus synonym COLUMN_VECTOR ShortText
    # [[0, 1337566253.89858, 0.000355720520019531], true]
    load --table Thesaurus
    [
    {"_key": "mroonga", "synonym": ["mroonga", "tritonn", "groonga mysql"]},
    {"_key": "groonga", "synonym": ["groonga", "senna"]}
    ]
    

    上記のケースでは、 mroonga を検索した場合、 Groongaは、意図通り、 mroonga OR tritonn OR "groonga mysql" を検索しますが、 tritonn を検索した場合は、 Groongaは、 tritonn のみを検索します。 tritonn を検索した場合でも、 tritonn OR mroonga OR "groonga mysql" と検索した場合、以下のように定義を追加する必要がありました。

    load --table Thesaurus
    [
    {"_key": "tritonn", "synonym": ["tritonn", "mroonga", "groonga mysql"]},
    ]
    

    多くのケースでは、 mroongamroonga OR tritonn OR "groonga mysql" と展開した場合、 tritonn"groonga mysql"mroonga OR tritonn OR "groonga mysql" と展開して欲しくなりますが、 今までは、そのようなケースでは定義を追加する必要がありました。したがって、対象のキーワードに同義語がたくさんあると、 同じような定義をたくさん定義する必要があるため、同義語の定義が煩雑でした。

    加えて、同義語を削除する際も、多くのレコードを削除する必要があるので面倒でした。

    今回のリリースから同義語の代表値を決めることで一つのグループを作れるようになりました。例えば、以下のすべてのキーワードは、 "mroonga" グループです。

    load --table Synonyms
    [
      {"_key": "mroonga": "representative": "mroonga"}
    ]
    
    load --table Synonyms
    [
      {"_key": "tritonn": "representative": "mroonga"},
      {"_key": "groonga mysql": "representative": "mroonga"}
    ]
    

    このケースでは、 mroongamroonga OR tritonn OR "groonga mysql" と展開されます。 また、 tritonn"groonga mysql"mroonga OR tritonn OR "groonga mysql" と展開されます。

    同義語を削除する際も、対象のレコードを削除するだけです。例えば、同義語から "groonga mysql" を削除する場合は、 {"_key": "groonga mysql": "representative": "mroonga"} を削除するだけです。

  • query_expand 同義語グループにベクターを使えるようにしました。

    以下のように、同義語グループにベクターを使えます。

    table_create SynonymGroups TABLE_NO_KEY
    [[0,0.0,0.0],true]
    column_create SynonymGroups synonyms COLUMN_VECTOR ShortText
    [[0,0.0,0.0],true]
    table_create Synonyms TABLE_PAT_KEY ShortText
    [[0,0.0,0.0],true]
    column_create Synonyms group COLUMN_INDEX SynonymGroups synonyms
    [[0,0.0,0.0],true]
    load --table SynonymGroups
    [
    ["synonyms"],
    [["rroonga", "Ruby groonga"]],
    [["groonga", "rroonga", "mroonga"]]
    ]
    [[0,0.0,0.0],2]
    query_expand Synonyms.group "rroonga"
    [
      [
        0,
        0.0,
        0.0
      ],
      "((rroonga) OR (Ruby groonga) OR (groonga) OR (rroonga) OR (mroonga))"
    ]
    
  • 環境変数によって、バックトレースを無効にできるようにしました。

    GRN_BACK_TRACE_ENABLE を使うことで、バックトレースの出力を無効にできます。 GRN_BACK_TRACE_ENABLE=no と設定すると、 Groongaはバックトレースを出力しません。

    Groongaはバックトレースをスタック領域に保持します。したがって、OSによっては、Groongaがスタック領域を使い切ってしまいクラッシュする可能性があります。 GRN_BACK_TRACE_ENABLE=no を使うことで、このようなケースを避けることができます。

  • select --slices のパフォーマンスを改善しました。

  • [Windows] VisualStudio 2022 をサポートしました。

  • select 近傍検索でそれぞれの要素ごとの距離を指定できるようになりました。

    例えば、近傍フレーズ検索なら、フレーズごとに最大距離を指定できます。この機能は今後ドキュメント化されます。そのため、機能の詳細は後日、共有します。

  • Groonga HTTPサーバー RPMパッケージのGroongaであっても、 groonga-server-http を使えるようにしました。

修正

  • [Windows] Groongaがバックトレースを出力時にクラッシュする問題を修正しました。

既知の問題

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

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

    • 'content @ "Groonga" *< content @ "Mroonga"'
  • GRN_II_CURSOR_SET_MIN_ENABLE が原因でマッチするはずのレコードを返さないことがあります。

さいごに

詳細については、以下のお知らせも参照してください。

お知らせ 12.0.1リリース

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

2022-02-09

Groonga 12.0.0リリース

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

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

変更内容

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

改良

  • sub_filter 新しいオプション pre_filter_threshold を追加しました。

    このオプションで、 GRN_SUB_FILTER_PRE_FILTER_THRESHOLD の値を変更できます。 Groongaが sub_filter 実行時に レコード数が GRN_SUB_FILTER_PRE_FILTER_THRESHOLD 以下だった場合、Groongaは既に絞り込んだレコードに対して sub_filter を実行します。

    -1 にすると、常にこの最適化を有効にできます。

  • [index_column_have_source_record] 新しい関数 index_column_have_source_record() を追加しました。

    インデックスに存在するトークンがGroongaに登録されているいずれかのレコードに含まれているかどうかを確認できます。

    Groongaは、レコードの更新によってどのレコードからも使われていないトークンがあっても、それを削除しません。 したがって、例えば、オートコンプリート機能を使っていると、検索候補としてどのレコードにも含まれていないトークンを返す可能性がありますが、 この関数をつかうことで、不要なトークンを返さないようにできます。

    この関数は、トークンがどのレコードにも含まれていないことを検出できるからです。

  • NormalizerNFKC130 新しいオプション strip を追加しました。

    このオプションは、以下のように先頭と末尾から空白を削除します。

    normalize \
    'NormalizerNFKC121("strip", true, \
                       "report_source_offset", true)' \
    "  hello world\t! \t " \
    WITH_CHECKS|WITH_TYPES
     [
       [
         0,
         0.0,
         0.0
       ],
       {
         "normalized": "hello world!",
         "types": [
           "alpha",
           "alpha",
           "alpha",
           "alpha",
           "alpha",
           "others",
           "alpha",
           "alpha",
           "alpha",
           "alpha",
           "alpha|blank",
           "symbol|blank"
         ],
         "checks": [
           3,
           1,
           1,
           1,
           1,
           1,
           1,
           1,
           1,
           1,
           1,
           2
         ],
         "offsets": [
           0,
           3,
           4,
           5,
           6,
           7,
           8,
           9,
           10,
           11,
           12,
           14
         ]
       }
     ]
    
  • select 新しい引数 drilldown_max_n_target_recordsdrilldown[${LABEL}].max_n_target_records を追加しました。

    ドリルダウン対象のテーブル(フィルター結果)の中のうち最大で何レコードをドリルダウンに使うかを指定します。 もし、フィルター結果のレコード数が指定した値より大きかったらフィルターした結果内のいくつかのレコードはドリルダウンには使われません。 これらの引数のデフォルト値は、 -1 です。これらの引数に -1 がセットされた場合、Groongaは全てのレコードをドリルダウンに使います。

    この機能はフィルター結果が非常に大きくなるかもしれない場合に有用です。 大きなフィルター結果に対するドリルダウンは遅くなることがあるためです。この機能を使うことでドリルダウンに使うレコード数を制限できます。

    以下はドリルダウンに使う最大レコード数を制限する例です。 最後の2レコード( {"_id": 4, "tag": "Senna"}{"_id": 5, "tag": "Senna"} )は使われていません。

    table_create Entries TABLE_HASH_KEY ShortText
    column_create Entries content COLUMN_SCALAR Text
    column_create Entries n_likes COLUMN_SCALAR UInt32
    column_create Entries tag COLUMN_SCALAR ShortText
    
    table_create Terms TABLE_PAT_KEY ShortText --default_tokenizer TokenBigram --normalizer NormalizerAuto
    column_create Terms entries_key_index COLUMN_INDEX|WITH_POSITION Entries _key
    column_create Terms entries_content_index COLUMN_INDEX|WITH_POSITION Entries content
    load --table Entries
    [
    {"_key":    "The first post!",
     "content": "Welcome! This is my first post!",
     "n_likes": 5,
     "tag": "Hello"},
    {"_key":    "Groonga",
     "content": "I started to use Groonga. It's very fast!",
     "n_likes": 10,
     "tag": "Groonga"},
    {"_key":    "Mroonga",
     "content": "I also started to use Mroonga. It's also very fast! Really fast!",
     "n_likes": 15,
     "tag": "Groonga"},
    {"_key":    "Good-bye Senna",
     "content": "I migrated all Senna system!",
     "n_likes": 3,
     "tag": "Senna"},
    {"_key":    "Good-bye Tritonn",
     "content": "I also migrated all Tritonn system!",
     "n_likes": 3,
     "tag": "Senna"}
    ]
    
    select Entries \
      --limit -1 \
      --output_columns _id,tag \
      --drilldown tag \
      --drilldown_max_n_target_records 3
    [
      [
        0,
        1337566253.89858,
        0.000355720520019531
      ],
      [
        [
          [
            5
          ],
          [
            [
              "_id",
              "UInt32"
            ],
            [
              "tag",
              "ShortText"
            ]
          ],
          [
            1,
            "Hello"
          ],
          [
            2,
            "Groonga"
          ],
          [
            3,
            "Groonga"
          ],
          [
            4,
            "Senna"
          ],
          [
            5,
            "Senna"
          ]
        ],
        [
          [
            2
          ],
          [
            [
              "_key",
              "ShortText"
            ],
            [
              "_nsubrecs",
              "Int32"
            ]
          ],
          [
            "Hello",
            1
          ],
          [
            "Groonga",
            2
          ]
        ]
      ]
    ]
    
  • [httpd] バンドルしているnginxのバージョンを1.21.6に更新しました。

既知の問題

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

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

    • 'content @ "Groonga" *< content @ "Mroonga"'
  • GRN_II_CURSOR_SET_MIN_ENABLE が原因でマッチするはずのレコードを返さないことがあります。

さいごに

詳細については、以下のお知らせも参照してください。

お知らせ 12.0.0リリース

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

2022-01-29

Groonga 11.1.3リリース

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

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

変更内容

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

改良

  • snippet 32個以上のキーワードを使えるようにしました。

    いままで、 snippet は32個以上のキーワードを指定できませんでしたが、この改良によって以下のように32個以上のキーワードを指定できます。

    table_create Entries TABLE_NO_KEY
    column_create Entries content COLUMN_SCALAR ShortText
    
    load --table Entries
    [
    {"content": "Groonga is a fast and accurate full text search engine based on inverted index. One of the characteristics of Groonga is that a newly registered document instantly appears in search results. Also, Groonga allows updates without read locks. These characteristics result in superior performance on real-time applications.\nGroonga is also a column-oriented database management system (DBMS). Compared with well-known row-oriented systems, such as MySQL and PostgreSQL, column-oriented systems are more suited for aggregate queries. Due to this advantage, Groonga can cover weakness of row-oriented systems.\nThe basic functions of Groonga are provided in a C library. Also, libraries for using Groonga in other languages, such as Ruby, are provided by related projects. In addition, groonga-based storage engines are provided for MySQL and PostgreSQL. These libraries and storage engines allow any application to use Groonga. See usage examples."},
    {"content": "In widely used DBMSs, updates are immediately processed, for example, a newly registered record appears in the result of the next query. In contrast, some full text search engines do not support instant updates, because it is difficult to dynamically update inverted indexes, the underlying data structure.\nGroonga also uses inverted indexes but supports instant updates. In addition, Groonga allows you to search documents even when updating the document collection. Due to these superior characteristics, Groonga is very flexible as a full text search engine. Also, Groonga always shows good performance because it divides a large task, inverted index merging, into smaller tasks."}
    ]
    
    select Entries \
      --output_columns ' \
      snippet(content, \
      "groonga", "inverted", "index", "fast", "full", "text", "search", "engine", "registered", "document", \
      "results", "appears", "also", "system", "libraries", "for", "mysql", "postgresql", "column-oriented", "dbms", \
      "basic", "ruby", "projects", "storage", "allow", "application", "usage", "sql", "well-known", "real-time", \
      "weakness", "merging", "performance", "superior", "large", "dynamically", "difficult", "query", "examples", "divides", \
      { \
        "default_open_tag": "[", \
        "default_close_tag": "]", \
        "width" : 2048 \
      })'
    [
      [
        0,
        1643165838.691991,
        0.0003311634063720703
      ],
      [
        [
          [
            2
          ],
          [
            [
              "snippet",
              null
            ]
          ],
          [
            [
              "[Groonga] is a [fast] and accurate [full] [text] [search] [engine] based on [inverted] [index]. One of the characteristics of [Groonga] is that a newly [registered] [document] instantly [appears] in [search] [results]. [Also], [Groonga] [allow]s updates without read locks. These characteristics result in [superior] [performance] on [real-time] [application]s.\n[Groonga] is [also] a [column-oriented] database management [system] ([DBMS]). Compared with [well-known] row-oriented [system]s, such as [MySQL] and [PostgreSQL], [column-oriented] [system]s are more suited [for] aggregate queries. Due to this advantage, [Groonga] can cover [weakness] of row-oriented [system]s.\nThe [basic] functions of [Groonga] are provided in a C library. [Also], [libraries] [for] using [Groonga] in other languages, such as [Ruby], are provided by related [projects]. In addition, [groonga]-based [storage] [engine]s are provided [for] [MySQL] and [PostgreSQL]. These [libraries] and [storage] [engine]s [allow] any [application] to use [Groonga]. See [usage] [examples]."
            ]
          ],
          [
            [
              "In widely used [DBMS]s, updates are immediately processed, [for] example, a newly [registered] record [appears] in the result of the next [query]. In contrast, some [full] [text] [search] [engine]s do not support instant updates, because it is [difficult] to [dynamically] update [inverted] [index]es, the underlying data structure.\n[Groonga] [also] uses [inverted] [index]es but supports instant updates. In addition, [Groonga] [allow]s you to [search] [document]s even when updating the [document] collection. Due to these [superior] characteristics, [Groonga] is very flexible as a [full] [text] [search] [engine]. [Also], [Groonga] always shows good [performance] because it [divides] a [large] task, [inverted] [index] [merging], into smaller tasks."
            ]
          ]
        ]
      ]
    ]
    
  • NormalizerNFKC130 新しいオプション remove_symbol を追加しました。

    このオプションは、以下のように正規化対象の文字列から記号(例えば #, !, ", &, % 等)を削除します。

    normalize   'NormalizerNFKC130("remove_symbol", true)'   "#This & is %% a pen."   WITH_TYPES
    [
      [
        0,
        1643595008.729597,
        0.0005540847778320312
      ],
      {
        "normalized": "this  is  a pen",
        "types": [
          "alpha",
          "alpha",
          "alpha",
          "alpha",
          "others",
          "others",
          "alpha",
          "alpha",
          "others",
          "others",
          "alpha",
          "others",
          "alpha",
          "alpha",
          "alpha"
        ],
        "checks": [
        ]
      }
    ]
    
  • AlmaLinux ARM64版 AlmaLinux 8 向けのパッケージをサポートしました。

  • [httpd] バンドルしているnginxのバージョンを1.21.5に更新しました。

  • [Documentation] ruby_eval の誤記を修正しました。

  • Ubuntu Ubuntu 21.04 (Hirsute Hippo) のサポートをやめました。

    Ubuntu 21.04 は、2022年1月20日でEOLとなったためです。

修正

  • load 存在しないカラムを指定してロードした時にクラッシュする問題を修正しました。

    この問題は、 load の引数として、 input_typeapache-arrow を指定したときのみ発生します。

  • Groongaが依存している arrow-libs がバージョンアップしたことによって、Groongaのバージョンアップが失敗する問題を修正しました。

    ただし、 arrow-libs がメジャーバージョンアップした場合は、この問題は再発します。その場合は、Groongaパッケージを再構築して対応する予定です。

既知の問題

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

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

    • 'content @ "Groonga" *< content @ "Mroonga"'
  • GRN_II_CURSOR_SET_MIN_ENABLE が原因でマッチするはずのレコードを返さないことがあります。

さいごに

詳細については、以下のお知らせも参照してください。

お知らせ 11.1.3リリース

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