BloGroonga

2020-09-29

Groonga 10.0.7リリース

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

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

変更内容

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

  • [highlight], [highlight_full] ノーマライザーにオプションを指定できるようになりました。

  • return code 新しいリターンコード GRN_CONNECTION_RESET を追加しました。

    • このリターンコードは、リモートホストから強制的に接続を切断されたときに返されます。

  • Ubuntu 19.10(Eoan Ermine)のサポートをやめました。

    • このバージョンはEOLになっているためです。

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

  • grndb キーの重複を検出できるようになりました。

    • 今回のリリースから、　grndb check でキーの重複も検出できるようになりました。
    • このチェックは、 TABLE_NO_KEY のテーブル以外で有効です。
    • grndb check で重複が検出されたテーブルにインデックスカラムしかない場合は、 grndb recover で復旧できます。

  • [table_create], [column_create] 新しいオプション --path を追加しました。

  • [dump] 新しいオプション --dump_paths を追加しました。

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

    • この関数は、第二引数に指定されたカラムの値を、第一引数に指定されたトークナイザーでトークナイズします。

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

    • このトークナイザーは、TF-IDFで文書ベクトルを自動で生成します。

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

    • このトークナイザーは、BM25で文書ベクトルを自動で生成します。

  • [select] 同一センテンス内での、近傍検索をサポートしました。

  • 257個のカラムに対して load を実行すると load の応答が返らなくなる問題を修正しました。

    • この問題は、10.0.4以降で発生する可能性があります。
    • この問題は、 [a, b, c, ...] の形式でデータをロードした時にのみ発生します。
      • [{...}] を使ってデータをロードした場合は発生しません。

  • [MessagePack] float32の値を正しくアンパックできない問題を修正しました。

  • マルチカラムインデックス関連の問題を修正しました。

    • _score の値が壊れることがあります。
    • ヒットしないはずのレコードがヒットすることがあります。

[highlight], highlight_full ノーマライザーにオプションを指定できるようになりました

  • highlight() と highlight_full() にノーマライザーのオプションを指定できるようになりました。

  • 設定可能なオプションについては、以下を参照してください。

    • https://groonga.org/ja/docs/reference/normalizers/normalizer_nfkc100.html#parameters

  • 例えば、 unify_hyphen を使ってコードポイントの異なるハイフンを同一視できます。

    table_create Entries TABLE_NO_KEY
column_create Entries body COLUMN_SCALAR ShortText

load --table Entries
[
{"body": "full-text-search. Use U+002D HYPHEN-MINUS"},
{"body": "full֊text֊search. Use U+058A ARMENIAN HYPHEN"},
{"body": "full˗text˗search. Use U+02D7 MODIFIER LETTER MINUS SIGN"}
]

select Entries --output_columns \
  'highlight_full(body, \
                  "NormalizerNFKC121(\\"unify_hyphen\\", true)", \
                  true, \
                  "full-text-search", \
                  "<span class=\\"keyword1\\">", \
                  "</span>")' --output-pretty yes
[
  [
    0,
    0.0,
    0.0
  ],
  [
    [
      [
        3
      ],
      [
        [
	  "highlight_full",
	  null
	]
      ],
      [
        "<span class=\"keyword1\">full-text-search</span>. Use U+002D HYPHEN-MINUS"
      ],
      [
        "<span class=\"keyword1\">full֊text֊search</span>. Use U+058A ARMENIAN HYPHEN"
      ],
      [
        "<span class=\"keyword1\">full˗text˗search</span>. Use U+02D7 MODIFIER LETTER MINUS SIGN"
      ]
    ]
  ]
]

  • unify_hyphen オプションを指定しない場合、 以下のように {"body": "full-text-search. Use U+002D HYPHEN-MINUS"} のみハイライトされます。

    • その他のレコードは、検索キーワードに含まれるハイフンとコードポイントが異なるためです。
    select Entries --output_columns \
  'highlight_full(body, \
                  "NormalizerNFKC121()", \
                  true, \
                  "full-text-search", \
                  "<span class=\\"keyword1\\">", \
                  "</span>")'
[
  [
    0,
    0.0,
    0.0
  ],
  [
    [
      [
    3
  ],
  [
    [
      "highlight_full",
      null
    ]
  ],
  [
    "<span class=\"keyword1\">full-text-search</span>. Use U+002D HYPHEN-MINUS"
  ],
  [
    "full֊text֊search. Use U+058A ARMENIAN HYPHEN"
  ],
  [
    "full˗text˗search. Use U+02D7 MODIFIER LETTER MINUS SIGN"
  ]
    ]
  ]
]

table_create, column_create 新しいオプション --path を追加しました。

  • このオプションによって指定したテーブルまたは、カラムを任意のパスに格納できます。

  • このオプションは、高速なストレージ(SSDなど)によく使うテーブルやカラムを格納し、低速なストレージ(HDDなど)にあまり使わないテーブルやカラムを格納したいときに有用です。

  • このオプションは、相対パス、絶対パスの両方が指定できます。

    • 相対パスを指定した場合は、 groonga プロセスのパスを起点に指定したパスが解決されます。

  • --path を指定した場合、 dump コマンドの結果に --path の情報が含まれます。

    • したがって、 --path を指定した場合、 異なる環境のホストではリストアできなくなります。
    • --path の情報を dump に含みたくない場合は、 dump コマンド実行時に --dump_paths no を指定する必要があります。

dump 新しいオプション --dump_paths を追加しました。

  • --dump_paths オプションは --path をダンプするかどうかを制御します。

  • デフォルト値は、 yes です。

  • もし、テーブルやカラム作成時に --path を指定していて、 --path の情報を dump に含みたくない場合は、 dump コマンド実行時に --dump_paths に no を指定してください。

  • 従来の近傍検索では、同一センテンス内での検索はできませんでした。

  • 今回のリリースから同一センテンス内での検索ができます。

    table_create Memos TABLE_PAT_KEY ShortText
column_create Memos content COLUMN_SCALAR ShortText

table_create Terms TABLE_PAT_KEY ShortText \
  --default_tokenizer TokenBigram \
  --normalizer NormalizerAuto
column_create Terms memos_content COLUMN_INDEX|WITH_POSITION Memos content

load --table Memos
[
{"_key":"alphabets1", "content": "a c d ."},
{"_key":"alphabets2", "content": "a b c d e f ."},
{"_key":"alphabets3", "content": "a b x c d e f ."},
{"_key":"alphabets4", "content": "a b x x c d e f ."}
]

select \
  --table Memos \
  --match_columns content \
  --query '*NP3,-1"a c .$"' \
  --output_columns _score,_key,content
[
  [
    0,
    0.0,
    0.0
  ],
  [
    [
      [
        2
      ],
      [
        [
          "_score",
          "Int32"
        ],
        [
          "_key",
          "ShortText"
        ],
        [
          "content",
          "ShortText"
        ]
      ],
      [
        1,
        "alphabets1",
        "a c d ."
      ],
      [
        1,
        "alphabets2",
        "a b x c ."
      ]
    ]
  ]
]

  • 同一センテンス内の近傍検索は、以下の構文を使います。

    • '"NP${MAX_INTERVAL},${ADDITIONAL_LAST_INTERVAL}"'${FIRST_PHRASE},${LASR_PHRASE} ${SEPARATOR}$

      • ${ADDITIONAL_LAST_INTERVAL} に -1 を指定した場合、最初のフレーズと最後のフレーズの間隔が ${MAX_INTERVAL} 以下のレコードがヒットします。

        • このケースでは、最後のフレーズとセパレーターがどれほど離れていてもレコードはヒットします。

      • ${ADDITIONAL_LAST_INTERVAL} に 1 以上の整数を指定した場合は、 以下の条件のレコードがヒットします。

        • 最初のフレーズと最後のフレーズの間隔が ${MAX_INTERVAL} 以下。
        • 最初のフレーズとセパレーターの間隔が ${MAX_INTERVAL}+${ADDITIONAL_LAST_INTERVAL} 以下。

      • ${ADDITIONAL_LAST_INTERVAL} に 0 を指定した場合、近傍検索は従来の動作をします。

        • ${ADDITIONAL_LAST_INTERVAL} のデフォルト値は 0 です。

    • ${SEPARATOR} には任意の文字を指定できます。

マルチカラムインデックス関連の問題を修正しました。

  • _score が壊れることがあります。

  • ヒットしないはずのレコードがヒットすることがあります。

  • 例えば、以下のクエリを実行するとこの問題が発生します。

    select TABLE \
  --match_columns 'LEXICON.INDEX[10]' \
  --query 'XXX' \
  --output_columns _score

    • このケースでは、 LEXICON.INDEX[0] - LEXICON.INDEX[9] が未初期化でした。

      • Groongaは、検索対象のインデックスを各セクションの値が 0 かどうかで決定しています。

      • したがって、 LEXICON.INDEX[0] - LEXICON.INDEX[9] が未初期化の場合、Groongaは誤った検索対象を選択する可能性があります。

        • LEXICON.INDEX[0] - LEXICON.INDEX[9] の値が不定なためです。

      • また、 これらの値は、スコアの重みに使われます。

        • そのため、 _score の値も不定になります。

  • ただ、以下のクエリーでは、この問題は発生しません。未初期化の領域が発生しないためです。

    select TABLE \
  --match_columns 'LEXICON.INDEX[0]' \
  --query 'XXX' \
  --output_columns _score

  • つまり、以下のような場合にこの問題が発生します。

    • ソースカラムに a 、 b 、 c を持つマルチカラムインデックスがある時、以下のようにセクションを指定している場合。

      • a と c
      • b と c
      • b のみ
      • c のみ

  • 以下の条件ではこの問題は発生しません。未初期化の領域が発生しないためです。

    • 以下のように最初のセクションから途中間を空けずに指定している場合は発生しません。

      • a と b と c
      • a と b
      • a のみ

さいごに

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