BloGroonga

2021-06-29

Groonga 11.0.4リリース

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

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

変更内容

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

改良

  • [Normalizer] カスタマイズされたノーマライザーを使えるようになりました。

  • 新しいコマンド object_warm を追加しました。

    このコマンドは、GroongaのDBをOSのページキャッシュに乗せます。 OS起動後、Groongaを一度も起動していない場合、GroongaのDBはOSのページキャッシュ上に存在しません。 そのため、Groongaに対する最初の操作は遅くなります。

    予めこのコマンドを実行した場合、Groongaへの最初の操作は速くなります。 Linuxでは、 cat *.db > dev/null で同等のことができますが、Windowsでは、いままで同様のことはできませんでした。

    このコマンドを使うことで、LinuxでもWindowsでもGroongaのDBをOSのページキャッシュへ乗せることができます。 また、テーブル、カラム、インデックス単位でも同様のことができます。 したがって、よく使うテーブルやカラム、インデックスのみをOSのページキャッシュに乗せることができます。

  • select --filter 内で特定のレコードのスコアーを調整できるようにしました。

    *~ という演算子を使うことで、特定のレコードのスコアーを調整できます。 *~&&|| と同じ論理演算子です。したがって、 &&|| と同じように使えます。 *~ のデフォルトの重みは -1 です。

    したがって、例えば、 'content @ "Groonga" *~ content @ "Mroonga"' は以下の操作を意味します。

    1. 'content @ "Groonga"content @ "MySQL" にマッチしたレコードを抽出します。
    2. 以下のようにスコアーを追加します。
    a. 'content @ "Groonga"' のスコアーを計算します。
    b. 'content @ "Mroonga"' のスコアーを計算します。
    c. bのスコアーを -1 倍します。
    d. このレコードのスコアーは a + b です。したがって、 aのスコアー 1 で bのスコアーが1 の場合、
       このレコードのスコアーは 1 + (1 * -1) = 0 です。
    

    また、 *~${score_quantity} とすることで、スコアーの量を指定できます。

    具体的には、 以下の条件( 'content @ "Groonga" *~2.5 content @ "MySQL"' ) にマッチしたレコードのスコアーを調整します。

      table_create Memos TABLE_NO_KEY
      column_create Memos content COLUMN_SCALAR ShortText
    
      table_create Terms TABLE_PAT_KEY ShortText \
        --default_tokenizer TokenBigram \
        --normalizer NormalizerAuto
      column_create Terms index COLUMN_INDEX|WITH_POSITION Memos content
    
      load --table Memos
      [
      {"content": "Groonga is a full text search engine."},
      {"content": "Rroonga is the Ruby bindings of Groonga."},
      {"content": "Mroonga is a MySQL storage engine based of Groonga."}
      ]
    
      select Memos \
        --command_version 3 \
        --filter 'content @ "Groonga" *~2.5 content @ "Mroonga"' \
        --output_columns 'content, _score' \
        --sort_keys -_score,_id
      {
        "header": {
          "return_code": 0,
          "start_time": 1624605205.641078,
          "elapsed_time": 0.002965450286865234
        },
        "body": {
          "n_hits": 3,
          "columns": [
            {
              "name": "content",
              "type": "ShortText"
            },
            {
              "name": "_score",
              "type": "Float"
            }
          ],
          "records": [
            [
              "Groonga is a full text search engine.",
              1.0
            ],
            [
              "Rroonga is the Ruby bindings of Groonga.",
              1.0
            ],
            [
              "Mroonga is a MySQL storage engine based of Groonga.",
              -1.5
            ]
          ]
        }
      }
    

    adjuster を使っても同様のことができます。 adjuster を使う場合、アプリケーション上で、 --filter 条件と --adjuster 条件を作る必要がありますが、この改良で、 --filter 条件のみを作成すればよくなりました。

    以下のように、 query() を使って、filter条件を記述することもできます。

    • --filter 'content @ "Groonga" *~2.5 content @ "Mroonga"'
  • select 重み付き && をサポートしました。

    *<*> を使うことで、重み付きの && を使えます。 *< のデフォルトの重みは 0.5です。 *> のデフォルトの重みは 2.0 です。

    *<${score_quantity}*>${score_quantity} とすることで、スコアーの量を指定できます。 また、 *<${score_quantity} と指定した場合は、 ${score_quantity} の正負の符号が反転します。

    例えば、 'content @ "Groonga" *<2.5 query("content", "MySQL")' は以下の操作を意味します。

    1. 'content @ "Groonga"content @ "MySQL" にマッチしたレコードを抽出します。
    2. 以下のようにスコアーを追加します。
    a. 'content @ "Groonga"' のスコアーを計算します。
    b. 'query("content", "MySQL") のスコアーを計算します。
    c. bのスコアーは、 *< によって -2.5倍されます。
    d. このレコードのスコアーは a + b です。したがって、 aのスコアー 1 で bのスコアーが1 の場合、
       このレコードのスコアーは 1 + (1 * -2.5) = −1.5 です。
    

    具体的には、 以下の条件( 'content @ "Groonga" *~2.5 query("content", "MySQL")' ) にマッチしたレコードのスコアーを調整します。

      table_create Memos TABLE_NO_KEY
      column_create Memos content COLUMN_SCALAR ShortText
    
      table_create Terms TABLE_PAT_KEY ShortText \
        --default_tokenizer TokenBigram \
        --normalizer NormalizerAuto
      column_create Terms index COLUMN_INDEX|WITH_POSITION Memos content
    
      load --table Memos
      [
      {"content": "Groonga is a full text search engine."},
      {"content": "Rroonga is the Ruby bindings of Groonga."},
      {"content": "Mroonga is a MySQL storage engine based of Groonga."}
      ]
    
      select Memos \
        --command_version 3 \
        --filter 'content @ "Groonga" *<2.5 query("content", "Mroonga")' \
        --output_columns 'content, _score' \
        --sort_keys -_score,_id
      {
        "header": {
          "return_code": 0,
          "start_time": 1624605205.641078,
          "elapsed_time": 0.002965450286865234
        },
        "body": {
          "n_hits": 3,
          "columns": [
            {
              "name": "content",
              "type": "ShortText"
            },
            {
              "name": "_score",
              "type": "Float"
            }
          ],
          "records": [
            [
              "Groonga is a full text search engine.",
              1.0
            ],
            [
              "Rroonga is the Ruby bindings of Groonga.",
              1.0
            ],
            [
              "Mroonga is a MySQL storage engine based of Groonga.",
              -1.5
            ]
          ]
        }
      }
    
  • Log 標準出力、標準エラー出力への出力をサポートしました。

    プロセスログクエリーログ が標準出力と標準エラー出力への出力をサポートしました。

    • --log-path ---query-log-path - と指定した場合、Groongaはログを標準出力に出力します。
    • --log-path +--query-log-path + と指定した場合、Groongaはログを標準エラー出力に出力します。

    プロセスログ は、Groongaの動作全てに関することのログです。 クエリーログ は、クエリー処理に関することだけのログです。

    この機能はDocker上でGroongaを実行する際に有用です。 Dockerは標準で標準出力と標準エラー出力を記録する機能を持っています。したがって、Groongaのログを取得するために、 Dockerの環境にログインする必要がなくなります。

  • [ドキュメント] string_substring に不足している内容を追加しました。

既知の問題

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

  • [ブラウザーベースの管理ツール] 現在Groongaには、レコード一覧の管理モードのチェックボックスにチェックを入れても、 非管理モードに入力された検索クエリーが送信されるという問題があります。

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

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

さいごに

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

お知らせ 11.0.4リリース

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

2021-05-29

Groonga 11.0.3リリース

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

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

変更内容

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

改良

  • query クエリー毎に TokenFilterStem を無効にできるようになりました。

  • query クエリー毎に TokenFilterStopWord を無効にできるようになりました。

  • NormalizerNFKC 新しいオプション remove_new_line を追加しました。

  • string_slice() 新しい関数 string_slice() を追加しました。

    • string_slice() は、文字列の部分文字列を抽出します。
  • Ubuntu Ubuntu 16.04 LTS (Xenial Xerus)のサポートをやめました。

  • Visual Studio 用の EditorConfig を追加しました。

    • 多くの設定は、Visual Studio 専用です。
  • [httpd] バンドルしているnginxのバージョンを1.20.1に更新しました。

    • CVE-2021-23017のセキュリティの修正が含まれています。

修正

  • オプションをサポートしているトークナイザーやノーマライザー、トークンフィルターが使われている際、多くの検索クエリーを送信するとGroongaが応答を返さなくなることがある問題を修正しました。

既知の問題

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

  • [ブラウザーベースの管理ツール] 現在Groongaには、レコード一覧の管理モードのチェックボックスにチェックを入れても、非管理モードに入力された検索クエリーが送信されるという問題があります。

さいごに

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

お知らせ 11.0.3リリース

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

2021-05-10

Groonga 11.0.2リリース

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

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

変更内容

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

改良

  • [Documentation] ruby_load コマンドのリファレンスを削除しました。

    • このコマンドはすでに削除されているためです。
  • Debian GNU/Linux Debian 11 (Bullseye) をサポートしました。

  • select --post_filter をサポートしました。

  • select --slices[].post_filter をサポートしました。

  • select --sort_keys 内に式を記述できるようになりました。

  • Token filters オプションをつけた複数のトークンカラムを使えるようにしました。

    • --token_filters 'TokenFilterStopWord("column", "ignore"), TokenFilterNFKC130("unify_kana", true)' のように複数のトークンフィルターを指定できます。
  • query 複雑な式で result_set ステージの動的カラムを扱えるようにしました。

    • 複雑な式とは、以下のように一時的な内部結果セットが必要な式です。

      '(true && query("name * 10", "ali", {"score_column": "ali_score"})) || \
       (true && query("name * 2", "li", {"score_column": "li_score"}))'
      
      • 上記の式では、 true の評価結果を格納するために一時的な結果セットを使用します。
      • したがって、例えば、以下の式では、式の中で result_set ステージの動的カラムの値を使えます。以下の式では、一時的な内部結果セットが必要ないためです。

        '(query("name * 10", "ali", {"score_column": "ali_score"})) || \
         (query("name * 2", "li", {"score_column": "li_score"}))'
        
    • 今回のリリースでは、以下のように li_score に値を設定できます。(以前のバージョンでは、2番めの式が動的カラムの値を取得出来なかったため、 li_score の値は 0 になっていました。)

      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 \
        --columns[ali_score].stage result_set \
        --columns[ali_score].type Float \
        --columns[ali_score].flags COLUMN_SCALAR \
        --columns[li_score].stage result_set \
        --columns[li_score].type Float \
        --columns[li_score].flags COLUMN_SCALAR \
        --output_columns name,_score,ali_score,li_score \
        --filter '(true && query("name * 10", "ali", {"score_column": "ali_score"})) || \
                  (true && query("name * 2", "li", {"score_column": "li_score"}))'
      [
        [
          0,
          0.0,
          0.0
        ],
        [
          [
            [
              2
            ],
            [
              [
                "name",
                "ShortText"
              ],
              [
                "_score",
                "Int32"
              ],
              [
                "ali_score",
                "Float"
              ],
              [
                "li_score",
                "Float"
              ]
            ],
            [
              "Alice",
              14,
              10.0,
              2.0
            ],
            [
              "Alisa",
              14,
              10.0,
              2.0
            ]
          ]
        ]
      ]
      
    • 以下のように、 result_set ステージの動的ベクターカラムも扱えるようにしました。

      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 \
        --columns[tags].stage result_set \
        --columns[tags].type ShortText \
        --columns[tags].flags COLUMN_VECTOR \
        --output_columns name,tags \
        --filter '(true && query("name", "al", {"tags": ["al"], "tags_column": "tags"})) || \
                  (true && query("name", "sa", {"tags": ["sa"], "tags_column": "tags"}))'
      [
        [
          0,
          0.0,
          0.0
        ],
        [
          [
            [
              2
            ],
            [
              [
                "name",
                "ShortText"
              ],
              [
                "tags",
                "ShortText"
              ]
            ],
            [
              "Alice",
              [
                "al"
              ]
            ],
            [
              "Alisa",
              [
                "al",
                "sa"
              ]
            ]
          ]
        ]
      ]
      
  • Ubuntu Ubuntu 21.04 (Hirsute Hippo) をサポートしました。

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

既知の問題

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

  • [ブラウザーベースの管理ツール] 現在Groongaには、レコード一覧の管理モードのチェックボックスにチェックを入れても、非管理モードに入力された検索クエリーが送信されるという問題があります。

さいごに

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

お知らせ 11.0.2リリース

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

2021-03-31

Groonga 11.0.1リリース

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

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

変更内容

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

改良

  • Debian GNU/Linux ARM64向けのパッケージをサポートしました。

  • select キーワードごとに重みをカスタマイズできるようにしました。

    • 今まで、スコアーを調整するには、すべてのキーワードに対して <> を指定する必要がありました。デフォルトのスコアの重み(1)より、デフォルトの重みの調整量(6 または 4)のほうが大きいためです。
    • 例えば、 A <B では、 "A" の重みは1、 "B" の重みは4になります。デクリメントされていない "A" の重み(1)より、デクリメントされた "B" の重み(4)のほうが大きくなります。これは、期待した動作ではありません。"B" に "A" より小さい重みを使うためには、 >A <B と指定する必要があります。 >A <B では、 "A" の重みは6、 "B" の重みは4になります。
    • 今回のリリースから、対象のキーワードに <${WEIGHT} または >${WEIGHT} と指定するだけで、キーワードごとに重みの調整量をカスタマイズできます。例えば、 A <0.1B では、 "A" の重みは1、 "B" の重みは0.9になります。("B" の重みを0.1デクリメントしています。)
    • ただし、これらの形式( >${WEIGHT}...<${WEIGHT}...~${WEIGHT}... )は互換性が無いことに注意してください。
  • select Apache Arrow形式で FloatFloat32 の値を出力できるようにしました。

  • select 結果出力時に、インデックスカラム経由で参照先のデータを取得できるようになりました。

    • 今までは、 出力値に index_column.xxx のように指定すると、Groongaは意図しない値を返していました。例えば以下の例では、 --columns[tags].value purchases.tag の値は、 ["apple",["many"]],["banana",["man"]],["cacao",["man"]] になりました。このケースでは、期待される値は、 ["apple",["man","many"]],["banana",["man"]],["cacao",["woman"]] でした。今回のリリースから、以下のように、インデックスカラム経由で参照先の正しい値を取得できます。

      table_create Products TABLE_PAT_KEY ShortText
      
      table_create Purchases TABLE_NO_KEY
      column_create Purchases product COLUMN_SCALAR Products
      column_create Purchases tag COLUMN_SCALAR ShortText
      
      column_create Products purchases COLUMN_INDEX Purchases product
      
      load --table Products
      [
      {"_key": "apple"},
      {"_key": "banana"},
      {"_key": "cacao"}
      ]
      
      load --table Purchases
      [
      {"product": "apple",  "tag": "man"},
      {"product": "banana", "tag": "man"},
      {"product": "cacao",  "tag": "woman"},
      {"product": "apple",  "tag": "many"}
      ]
      
      select Products \
        --columns[tags].stage output \
        --columns[tags].flags COLUMN_VECTOR \
        --columns[tags].type ShortText \
        --columns[tags].value purchases.tag \
        --output_columns _key,tags
      [
        [
          0,
          0.0,
          0.0
        ],
        [
          [
            [
              3
            ],
            [
              [
                "_key",
                "ShortText"
              ],
              [
                "tags",
                "ShortText"
              ]
            ],
            [
              "apple",
              [
                "man",
                "many"
              ]
            ],
            [
              "banana",
              [
                "man"
              ]
            ],
            [
              "cacao",
              [
                "woman"
              ]
            ]
          ]
        ]
      ]
      
  • select ネストされたインデックスの一部として直接インデックスカラムを指定できるようになりました。

    • index_column.except_source_column を使ってフィルター後にソーステーブルを検索できます。例えば、以下の例では、検索時に comments.content を指定しています。この場合、最初に、このクエリは Comments テーブルの content カラムを全文検索し、次に Comments テーブルを検索した結果のレコードを参照する Articles テーブルのレコードを取得します。

      table_create Articles TABLE_HASH_KEY ShortText
      
      table_create Comments TABLE_NO_KEY
      column_create Comments article COLUMN_SCALAR Articles
      column_create Comments content COLUMN_SCALAR ShortText
      
      column_create Articles content COLUMN_SCALAR Text
      column_create Articles comments COLUMN_INDEX Comments article
      
      table_create Terms TABLE_PAT_KEY ShortText \
        --default_tokenizer TokenBigram \
        --normalizer NormalizerNFKC130
      column_create Terms articles_content COLUMN_INDEX|WITH_POSITION \
        Articles content
      column_create Terms comments_content COLUMN_INDEX|WITH_POSITION \
        Comments content
      
      load --table Articles
      [
      {"_key": "article-1", "content": "Groonga is fast!"},
      {"_key": "article-2", "content": "Groonga is useful!"},
      {"_key": "article-3", "content": "Mroonga is fast!"}
      ]
      
      load --table Comments
      [
      {"article": "article-1", "content": "I'm using Groonga too!"},
      {"article": "article-3", "content": "I'm using Mroonga!"},
      {"article": "article-1", "content": "I'm using PGroonga!"}
      ]
      
      select Articles --match_columns comments.content --query groonga \
        --output_columns "_key, _score, comments.content
      [
        [
          0,
          0.0,
          0.0
        ],
        [
          [
            [
              1
            ],
            [
              [
                "_key",
                "ShortText"
              ],
              [
                "_score",
                "Int32"
              ],
              [
                "comments.content",
                "ShortText"
              ]
            ],
            [
              "article-1",
              1,
              [
                "I'm using Groonga too!",
                "I'm using PGroonga!"
              ]
            ]
          ]
        ]
      ]
      
  • load オブジェクトリテラルを使って、参照先のレコードをロードできるようにしました。

    • 例えば、以下のように、 "key" : "[ { "key" : "value", ..., "key" : "value" } ]" のようなデータをロードできます。

      table_create Purchases TABLE_NO_KEY column_create Purchases item COLUMN_SCALAR ShortText column_create Purchases price COLUMN_SCALAR UInt32

      table_create Settlements TABLE_HASH_KEY ShortText column_create Settlements purchases COLUMN_VECTOR Purchases column_create Purchases settlements_purchases COLUMN_INDEX Settlements purchases

      load –table Settlements [ { "_key": "super market", "purchases": [ {"item": "apple", "price": 100}, {"item": "milk", "price": 200} ] }, { "_key": "shoes shop", "purchases": [ {"item": "sneakers", "price": 3000} ] } ] ```

    • この機能によって、参照カラムにJSONデータを追加しやすくなります。
    • 現状、この機能は、JSONの入力のみをサポートしています。
  • load JSON文字列で、参照先のレコードをロードできるようにしました。

    • 以下のように、JSONテキストを使ってソーステーブルから参照ベクターへデータをロードできます。

      table_create Purchases TABLE_HASH_KEY ShortText
      column_create Purchases item COLUMN_SCALAR ShortText
      column_create Purchases price COLUMN_SCALAR UInt32
      
      table_create Settlements TABLE_HASH_KEY ShortText
      column_create Settlements purchases COLUMN_VECTOR Purchases
      
      column_create Purchases settlements_purchases COLUMN_INDEX Settlements purchases
      
      load --table Settlements
      [
      {
        "_key": "super market",
        "purchases": "[{\"_key\": \"super market-1\", \"item\": \"apple\", \"price\": 100}, {\"_key\": \"super market-2\", \"item\": \"milk\",  \"price\": 200}]"
      },
      {
        "_key": "shoes shop",
        "purchases": "[{\"_key\": \"shoes shop-1\", \"item\": \"sneakers\", \"price\": 3000}]"
      }
      ]
      
      dump \
        --dump_plugins no \
        --dump_schema no
      load --table Purchases
      [
      ["_key","item","price"],
      ["super market-1","apple",100],
      ["super market-2","milk",200],
      ["shoes shop-1","sneakers",3000]
      ]
      
      load --table Settlements
      [
      ["_key","purchases"],
      ["super market",["super market-1","super market-2"]],
      ["shoes shop",["shoes shop-1"]]
      ]
      
      column_create Purchases settlements_purchases COLUMN_INDEX Settlements purchases
      
    • 現状、この機能は、ネストされた参照レコードをサポートしていません。

  • [Windows] time_classify_* 関数で UNIXエポック を扱えるようになりました。

  • query_parallel_or クエリーを並行して実行できる新しい関数を追加しました。

  • select 存在しないソートキーを無視するようにしました。

    • 今まで、存在しないソートキーを指定したとき、Groongaはエラーを出力していましたが、今回のリリースから存在しないソートキーを無視します。(エラーを出力しなくなります。)
    • この機能は、一貫性のために実装しています。 output_columns も無効な値を無視します。また、 sort_keys も無効な値のほとんどを無視します。
  • select drilldowns[].table で存在しないテーブルを無視します。

    • 今まで、 drilldowns[].table で存在しないテーブルを指定したとき、Groongaはエラーを出力していましたが、今回のリリースから存在しないテーブルを無視します。(エラーを出力しなくなります。)
    • この機能は、一貫性のために実装しています。 output_columns も無効な値を無視します。また、 sort_keys も無効な値のほとんどを無視します。
  • [httpd] バンドルしているnginxのバージョンを1.19.8に更新しました。

修正

  • reference_acquire 参照の自動リリースが発生する前に、テーブルにカラムが追加されテーブルの参照が獲得されたときにGroongaがクラッシュする問題を修正しました。

    • 追加されたカラムの参照は獲得されませんが、自動リリースの対象になるためです。
  • [Windows] 別のスレッドで、他のバックトレースロギングプロセスが動作しているときに、新しくバックトレースロギングプロセスが開始されると、1つ以上のプロセスがSEGVのバックトレースの出力に失敗する問題を修正しました。

既知の問題

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

さいごに

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

お知らせ 11.0.1リリース

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

2021-02-09

Groonga 11.0.0リリース

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

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

変更内容

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

  • select ネストされたインデックス経由でスカラーカラムとベクターカラムの値を出力できるようになりました。
    • ネストされたインデックスとは、以下のような構造です。

      table_create Products TABLE_PAT_KEY ShortText
      
      table_create Purchases TABLE_NO_KEY
      column_create Purchases product COLUMN_SCALAR Products
      column_create Purchases tag COLUMN_SCALAR ShortText
      
      column_create Products purchases COLUMN_INDEX Purchases product
      
    • 上記の例では、 Products.purchases カラムは Purchases.product カラムのインデックスです。また、 Purchases.product カラムは、 Products テーブルへの参照です。

  • [Windows] Linux上のMinGWを使ってクロスコンパイルしていたWindows向けパッケージの提供をやめました。

    • おそらく、ほとんどの人がこのパッケージを使っていないためです。
    • これからは、以下のパッケージを使用してください。

      • groonga-latest-x86-vs2019-with-vcruntime.zip
      • groonga-latest-x64-vs2019-with-vcruntime.zip
    • 既に Microsoft Visual C++ Runtime Library がインストール済みのシステムの場合は、以下のパッケージを使用してください。

      • groonga-latest-x86-vs2019.zip
      • groonga-latest-x64-vs2019.zip
  • インデックス内のデータを大量に追加、削除、更新した際にインデックスが破損することがある問題を修正しました。

    • この問題は、インデックス内のデータを大量に削除しただけでも発生します。ただ、インデックスにデータを追加しただけでは発生しません。
    • この問題によって破損したインデックスは、インデックスを再構築することで修復できます。
    • この問題は、壊れたインデックスを参照しない限り発覚しません。したがって、既にインデックスが破損しているかもしれません。
    • index_column_diff コマンドを使うことで、インデックスが破損しているかどうかを確認できます。

さいごに

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

お知らせ 11.0.0リリース

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