2019-08-05
Groonga 9.0.6リリース
Groonga 9.0.6をリリースしました！
それぞれの環境毎のインストール方法: インストール
リリースに関する重要なお知らせ
本リリースには、検索結果に影響のある重要なバグの修正が含まれています。
変更内容
主な変更点は以下の通りです。
-
検索エスカレーションが起こった際に、検索がエラーになるバグを修正しま
した。
-
ネストされた等価演算を使った際に、マッチすべきではないレコードがマッチするバグを修正しました。
-
Debian 10 (buster) をサポートしました。
検索エスカレーションが起こった際に、検索がエラーになるバグを修正しました
以下の条件を満たした際に、検索がエラーとなり、マッチしたレコードを取得
できなくなるバグを修正しました。
- 語彙表が
TABLE_HASH_KEY
@演算子を使用した検索- 検索エスカレーションが発生
ネストされた等価演算を使った際に、マッチすべきではないレコードがマッチするバグを修正しました
selectコマンドのslicesパラメータを使った検索で、slicesで指定した条件とマッチしないレコードが出力されることがある問題を修正しました。
Debian 10 (buster) をサポートしました
Debian 10 (buster - 2019-07-06リリース)をサポートしました。
Debian 9 (stretch) と同じ方法でインストールできます。
さいごに
9.0.5からの詳細な変更点は9.0.6リリース 2019-08-05を確認してください。
それでは、Groongaでガンガン検索してください！
2019-07-30
Groonga 9.0.5リリース
Groonga 9.0.5をリリースしました！
それぞれの環境毎のインストール方法: インストール
リリースに関する重要なお知らせ
本リリースには、以下の問題が含まれていることがわかりました。近日中に以下の問題を修正した 9.0.6 をリリース予定です。
9.0.6 がリリースされるまでは、 9.0.5 は使わないことをおすすめいたします。
発見された問題は以下の通りです。
変更内容
主な変更点は以下の通りです。
-
logical_range_filter 検索対象のシャードが十分に大きい時にのみ最適化を適用するように改良しました。
-
ノーマライザー NormalizerNFKC100 に新しいオプション unify_to_katakana を追加しました。
- select
slices パラメーターでdrilldownsをサポートしました。
- select
slices パラメーターでcolumnsをサポートしました。
-
select initial ステージ内でslicesパラメーターが _score を参照できるよう改良しました。
-
highlight_html、 snippet_html slicesパラメータ指定時に、slices実行前の式からもキーワードを抽出するように改良しました。
-
highlight_html、 snippet_html slicesパラメータ指定時に、slices実行前の式からもスコアーを収集するように改良しました。
-
ポスティングリストにポスティングを追加する際に自動的にスコアーを1増やすのをやめました。
-
XXX.YYY.ZZZ == AAA のようなネストされた等価演算のインデックス検索をサポートしました。
-
ハッシュテーブル使用時にハッシュの再構築の間隔を少なくしました。
-
クエリーログにプレフィックスを追加できるようになりました。
-
Apache Arrow 1.0.0 をサポートしました。
-
Amazon Linux 2 をサポートしました。
-
"[1, 2, 3]" のようなJSONのベクター値がインデックスされないバグを修正しました。
-
table_create のテストのパラメーター名が誤っていたバグを修正しました。
-
command_version=3 でdrilldownコマンドが実行された際に、ドリルダウンのラベルが空になるバグを修正しました。
-
MinGWでWindows版のパッケージのビルドが失敗するバグを修正しました。
-
MinGWのWindows版パッケージにCOPYINGがインストールされないバグを修正しました。
-
ハイライト対象として、クエリーにテキスト以外を指定した際に、キーワードがハイライトされないバグを修正しました。
-
object_inspect のMessagePack形式の出力が壊れるバグを修正しました。
-
index_column_diff のMessagePack形式の出力が壊れるバグを修正しました。
-
suggest のMessagePack形式の出力が壊れるバグを修正しました。
-
パトリシアトライのテーブルの検索時などにreallocのサイズが十分に確保されないバグを修正しました。
groonga-release version 1.5.0より前から1.5.0-1へアップデートした際に groonga.repo が削除されるバグを修正しました。
この機能は、ソートキーが同じ時にオフセット間で検索結果が重複するのを減らします。
十分に大きいのしきい値はデフォルトで10000レコードです。
ノーマライザー NormalizerNFKC100 に新しいオプション unify_to_katakana を追加しました
このオプションは、平仮名を片仮名にノーマライズします。
例えば、 ゔぁゔぃゔゔぇゔぉ を ヴァヴィヴヴェヴォ にノーマライズします。
unify_to_katakana と unify_katakana_v_sounds を使って以下の語を同一視できます。
さいごに
9.0.4からの詳細な変更点は9.0.5リリース 2019-07-30を確認してください。
それでは、Groongaでガンガン検索してください！
2019-06-29
Groonga 9.0.4リリース
Groonga 9.0.4をリリースしました！
それぞれの環境毎のインストール方法: インストール
変更内容
主な変更点は以下の通りです。
-
配列リテラルの複数要素をサポートしました。
-
ベクターの等価演算をサポートしました。
-
logical_range_filter 出力するクエリーログを追加しました。
-
grndb 新しいオプション --since を追加しました。
-
query default_operator を追加しました。
-
[optimizer] 複数のfilter条件と xxx.yyy=="keyword" のような条件を指定した際にエラーが発生するバグを修正しました。
-
GroongaのWindows用のパッケージ(VC++版)に不足していたライセンスファイルを追加しました。
-
GroongaのWindows用のパッケージ(VC++版)UCRTランタイムを追加しました。
-
window_function メモリリークを修正しました。
- これは、複数のウインドウに対してソートキーを適用した際に発生します。
配列リテラルの複数要素をサポートしました。
以下のように filter 条件の中で複数要素を持った配列リテラルを使うことができます。
table_create Values TABLE_NO_KEY
column_create Values numbers COLUMN_VECTOR Int32
load --table Values
[
{"numbers": [2, 1, 3]},
{"numbers": [2, 3, 4]},
{"numbers": [8, 9, -1]}
]
select Values \
--filter 'numbers == [2, 3, 4]' \
--output_columns 'numbers'
[[0,0.0,0.0],[[[1],[["numbers","Int32"]],[[2,3,4]]]]]
ベクターの等価演算をサポートしました。
以下のようにベクターに対して等価演算を使うことができます。
table_create Values TABLE_NO_KEY
column_create Values numbers COLUMN_VECTOR Int32
load --table Values
[
{"numbers": [2, 1, 3]},
{"numbers": [2, 3, 4]},
{"numbers": [8, 9, -1]}
]
select Values \
--filter 'numbers == [2, 3, 4]' \
--output_columns 'numbers'
[[0,0.0,0.0],[[[1],[["numbers","Int32"]],[[2,3,4]]]]]
logical_range_filter コマンドが、以下のタイミングでログを出力するようになります。
logical_range_filter によるフィルター後logical_range_filter によるソート後- 動的カラム適用後
- 結果出力後
この機能によって、このコマンドがどこまで完了したかを見ることができます。
grndb Added support new option --since
検査の範囲を指定できます。
更新時刻は ISO 8601形式か -3days や -2.5weeksといった -NUNIT 形式で指定します。
以下は –since オプションをISO 8601形式で指定する例です。
% grmdb check --since=2019-06-24T18:16:22 /var/lib/groonga/db/db
上記の例では 2019-06-24T18:16:22 以降に更新されたオブジェクトをチェックします。
以下は –since オプションを -NUNIT 形式で指定する例です。
% grmdb check --since=-7d /var/lib/groonga/db/db
上記の例では、直近7日で更新されたものがチェックされます。
grndb#since も参考にしてください。
query default_operatorを追加しました。
"keyword1 keyword2"時の演算子をカスタマイズできます。
デフォルトでは、"keyword1 keyword2"はAND演算です。
以下のように、"keyword1 keyword2"の演算子をAND以外に変更できます。
table_create Products TABLE_NO_KEY
column_create Products name COLUMN_SCALAR ShortText
load --table Products
[
["name"],
["Groonga"],
["Mroonga"],
["Rroonga"],
["PGroonga"],
["Ruby"],
["PostgreSQL"]
]
select \
--table Products \
--filter 'query("name", "Groonga Mroonga", {"default_operator": "OR"})'
[
[
0,
0.0,
0.0
],
[
[
[
3
],
[
[
"_id",
"UInt32"
],
[
"name",
"ShortText"
]
],
[
1,
"Groonga"
],
[
4,
"PGroonga"
],
[
2,
"Mroonga"
]
]
]
]
さいごに
9.0.3からの詳細な変更点は9.0.4リリース 2019-06-29を確認してください。
それでは、Groongaでガンガン検索してください！
2019-05-29
Groonga 9.0.3リリース
Groonga 9.0.3をリリースしました！
それぞれの環境毎のインストール方法: インストール
変更内容
主な変更点は以下の通りです。
-
select クエリーログを追加しました。
-
logical_select クエリーログを追加しました。
-
logical_select limit オプションを使った際のソートのパフォーマンスを少し改善しました。
-
[index_column_diff] パフォーマンスを改善しました。
-
[Normalizers] Unicode 12.1 の Unicode NFKC (Normalization Form Compatibility Composition) をベースにしたノーマライザー NormalizerNFKC121 を追加しました。
-
[TokenFilters] Unicode 12.1のUnicode NFKC (Normalization Form Compatibility Composition)をベースにしたトークンフィルター TokenFilterNFKC121 を追加しました。
-
grndb 新しいオプション --log-flags を追加しました。
-
snippet_html 検索にマッチしなかったときの戻り値を変更する新しいオプションを追加しました。
-
plugin_unregister Windowsのフルパスに対応しました。
-
複数行に渡るログをサポートしました。
-
インデックスを使った検索の際、Groongaのログにキーを出力するようにしました。
-
mutch_columnsのドキュメント インデックスの重みを追加しました。
-
logical_range_filterのドキュメント order パラメータの説明を追加しました。
-
object_inspectのドキュメント 新しい統計 INDEX_COLUMN_VALUE_STATISTICS_NEXT_PHYSICAL_SEGMENT_ID と INDEX_COLUMN_VALUE_STATISTICS_N_PHYSICAL_SEGMENTS の説明を追加しました。
-
Ubuntu 14.04 のサポートをやめました。
-
[index_column_diff] remains を多く報告するバグを修正しました。
-
--without-onigmo オプションを使った際にビルドエラーになるバグを修正しました。
-
"CVE: 2019-11675"の脆弱性を修正しました。
-
Windows版のGroongaにて、拡張パスプレフィックス \\?\ を削除しました。
- この拡張プレフィックスは、プラグインを正確に見つけられないというバグを引き起こします。
select クエリーログを追加しました。
select コマンドが以下のタイミングでログを出力するようになります。
- ドリルダウンによるソート後
- ドリルダウンによるフィルター後
この機能によって、このコマンドがどこまで完了したかを見ることができます。
logical_select コマンドが、以下のタイミングでログを出力するようになります。
- 動的カラム作成後
- ドリルダウンによるグループ化後
- ドリルダウンによるソート後
- ドリルダウンによるフィルター後
logical_select によるフィルター後
この機能によって、このコマンドがどこまで完了したかを見ることができます。
[index_column_diff] パフォーマンスを改善しました。
このコマンドの実行速度を大幅に短くしました。
データにもよりますが、以前の数十倍から数百倍の速度で実行するようになり、メモリの使用量も少なくなっています。
この改善によって、このコマンドは十分に実用的になりました。
このコマンドの使い方は、Groonga 9.0.1 リリースで見ることができます。
grndb 新しいオプション --log-flags を追加しました。
groonga実行ファイルと同様、ログに出力する項目を指定できます。
サポートされているログフラグについては、groonga実行ファイルを参照してください。
snippet_html 検索にマッチしなかったときの戻り値を変更する新しいオプションを追加しました。
例えば、以下のように検索にマッチしなかったときの戻り値を"[]"に指定できます。
table_create Documents TABLE_HASH_KEY ShortText
[[0,0.0,0.0],true]
column_create Documents content COLUMN_SCALAR Text
[[0,0.0,0.0],true]
table_create Terms TABLE_PAT_KEY|KEY_NORMALIZE ShortText --default_tokenizer TokenBigram
[[0,0.0,0.0],true]
column_create Terms document_index COLUMN_INDEX|WITH_POSITION Documents content
[[0,0.0,0.0],true]
load --table Documents
[
["_key", "content"],
["Groonga", "Groonga can be used with MySQL."]
]
[[0,0.0,0.0],1]
select Documents --match_columns content --query 'MySQL' --output_columns '_key, snippet_html(_key, {"default": []})'
[
[
0,
0.0,
0.0
],
[
[
[
1
],
[
[
"_key",
"ShortText"
],
[
"snippet_html",
null
]
],
[
"Groonga",
[
]
]
]
]
]
さいごに
9.0.2からの詳細な変更点は9.0.3リリース 2019-05-29を確認してください。
それでは、Groongaでガンガン検索してください！
2019-04-29
Groonga 9.0.2リリース
Groonga 9.0.2をリリースしました！
今回のリリースから、VC++で作成したWindows版パッケージを提供します。
今までどおり、MinGWで作成したWindows版パッケージも提供しますが、近いうちにMinGWで作ったパッケージの代わりにVC++で作ったパッケージを提供する予定です。
それぞれの環境毎のインストール方法: インストール
変更内容
主な変更点は以下の通りです。
-
column_create 新しいフラグ INDEX_LARGE を追加しました。
-
object_inspect セグメントの新しい統計値 next_physical_segment_id と max_n_physical_segments を追加しました。
-
logical_select シャードをまたがったウインドウ関数をサポートしました。
-
logical_range_filter シャードをまたがったウインドウ関数をサポートしました。
-
logical_count シャードをまたがったウインドウ関数をサポートしました。
-
io_flush 新しいオプション --recursive dependent を追加しました。
-
一部の環境でコンパイルエラー "unknown type name 'bool'" が発生する問題を修正しました。
-
mrubyを経由して実行するコマンド(例えば、 logical_select、 logical_range_filter、 logical_count 等)で、Int32を超える数を正しく出力できない問題を修正しました。
column_create 新しいフラグ INDEX_LARGE を追加しました。
このフラグによって、デフォルトの2倍の領域を持つインデックスカラムを作成できますが、メモリ使用量も2倍となることに注意して下さい。
このフラグは、インデックス対象のデータが大きい時に有用です。
大きいデータとは、大量のレコード（通常は少なくとも1000万レコード以上）があり、少なくとも次のうちの1つ以上の特徴があります。
- インデックス対象が複数のカラム
- インデックステーブルにトークナイザーが付いている
以下は大きなインデックスカラムを作る例です。
column_create \
--table Terms \
--name people_roles_large_index \
--flags COLUMN_INDEX|WITH_POSITION|WITH_SECTION|INDEX_LARGE \
--type People \
--source roles
[[0, 1337566253.89858, 0.000355720520019531], true]
object_inspect セグメントの新しい統計値 next_physical_segment_id と max_n_physical_segments を追加しました。
next_physical_segment_id は調査対象のインデックスガラムが次に使うセグメントのIDです。
つまり、この数字は、現在のセグメントの使用量を表しています。
max_n_physical_segments は調査対象のインデックスカラムのセグメントの最大値です。
これらの統計値の最大値は、インデックスカラムのサイズに依存します。:
| インデックスカラムのサイズ |
最大セグメント数 |
INDEX_SMALL |
2**9 (512) |
INDEX_MEDIUM |
2**16 (65536) |
INDEX_LARGE |
2**17 * 2 (262144) |
| デフォルト |
2**17 (131072) |
ウインドウ関数を複数のテーブルをまたがって適用できます。
ただし、先頭のグループキーまたは、ソートキーがシャードキーと同じ順番で並んでいる必要があります。
例えば、以下のケースは、先頭のグループキーがシャードキーと同じ順番で並んでいるため、複数のテーブルをまたがってウインドウ関数を適用できます。
以下の例では、先頭のグループキーは price でシャードキーは timestamp です。:
plugin_register sharding
table_create Logs_20170415 TABLE_NO_KEY
column_create Logs_20170415 timestamp COLUMN_SCALAR Time
column_create Logs_20170415 price COLUMN_SCALAR UInt32
column_create Logs_20170415 n_likes COLUMN_SCALAR UInt32
table_create Logs_20170416 TABLE_NO_KEY
column_create Logs_20170416 timestamp COLUMN_SCALAR Time
column_create Logs_20170416 price COLUMN_SCALAR UInt32
column_create Logs_20170416 n_likes COLUMN_SCALAR UInt32
load --table Logs_20170415
[
{"timestamp": "2017/04/15 00:00:00", "n_likes": 2, "price": 100},
{"timestamp": "2017/04/15 01:00:00", "n_likes": 1, "price": 100},
{"timestamp": "2017/04/15 01:00:00", "n_likes": 2, "price": 200}
]
load --table Logs_20170416
[
{"timestamp": "2017/04/16 10:00:00", "n_likes": 1, "price": 200},
{"timestamp": "2017/04/16 11:00:00", "n_likes": 2, "price": 300},
{"timestamp": "2017/04/16 11:00:00", "n_likes": 1, "price": 300}
]
logical_select Logs \
--shard_key timestamp \
--columns[count].stage initial \
--columns[count].type UInt32 \
--columns[count].flags COLUMN_SCALAR \
--columns[count].value 'window_count()' \
--columns[count].window.group_keys price \
--output_columns price,count
[
[
0,
0.0,
0.0
],
[
[
[
6
],
[
[
"price",
"UInt32"
],
[
"count",
"UInt32"
]
],
[
100,
2
],
[
100,
2
],
[
200,
2
],
[
200,
2
],
[
300,
2
],
[
300,
2
]
]
]
]
ウインドウ関数を複数のテーブルをまたがって適用できます。
ただし、logical_selectと同様、先頭のグループキーまたは、ソートキーがシャードキーと同じ順番で並んでいる必要があります。
以下は、logical_range_filterで、複数のテーブルをまたいでウインドウ関数を適用する例です。:
plugin_register sharding
table_create Logs_20170415 TABLE_NO_KEY
column_create Logs_20170415 timestamp COLUMN_SCALAR Time
column_create Logs_20170415 price COLUMN_SCALAR UInt32
column_create Logs_20170415 n_likes COLUMN_SCALAR UInt32
table_create Logs_20170416 TABLE_NO_KEY
column_create Logs_20170416 timestamp COLUMN_SCALAR Time
column_create Logs_20170416 price COLUMN_SCALAR UInt32
column_create Logs_20170416 n_likes COLUMN_SCALAR UInt32
load --table Logs_20170415
[
{"timestamp": "2017/04/15 00:00:00", "n_likes": 2, "price": 100},
{"timestamp": "2017/04/15 01:00:00", "n_likes": 1, "price": 100},
{"timestamp": "2017/04/15 01:00:00", "n_likes": 2, "price": 200}
]
load --table Logs_20170416
[
{"timestamp": "2017/04/16 10:00:00", "n_likes": 1, "price": 200},
{"timestamp": "2017/04/16 11:00:00", "n_likes": 2, "price": 300},
{"timestamp": "2017/04/16 11:00:00", "n_likes": 1, "price": 300}
]
logical_range_filter Logs \
--shard_key timestamp \
--columns[count].stage initial \
--columns[count].type UInt32 \
--columns[count].flags COLUMN_SCALAR \
--columns[count].value 'window_count()' \
--columns[count].window.group_keys price \
--output_columns price,count
[
[
0,
0.0,
0.0
],
[
[
[
6
],
[
[
"price",
"UInt32"
],
[
"count",
"UInt32"
]
],
[
100,
2
],
[
100,
2
],
[
200,
2
],
[
200,
2
],
[
300,
2
],
[
300,
2
]
]
]
]
logical_count シャードをまたがったウインドウ関数をサポートしました。
ウインドウ関数を複数のテーブルをまたがって適用できます。
ただし、logical_selectと同様、先頭のグループキーまたは、ソートキーがシャードキーと同じ順番で並んでいる必要があります。
以下は、logical_countで、複数のテーブルをまたいでウインドウ関数を適用する例です。:
plugin_register sharding
table_create Logs_20170415 TABLE_NO_KEY
column_create Logs_20170415 timestamp COLUMN_SCALAR Time
column_create Logs_20170415 price COLUMN_SCALAR UInt32
column_create Logs_20170415 n_likes COLUMN_SCALAR UInt32
table_create Logs_20170416 TABLE_NO_KEY
column_create Logs_20170416 timestamp COLUMN_SCALAR Time
column_create Logs_20170416 price COLUMN_SCALAR UInt32
column_create Logs_20170416 n_likes COLUMN_SCALAR UInt32
load --table Logs_20170415
[
{"timestamp": "2017/04/15 00:00:00", "n_likes": 2, "price": 100},
{"timestamp": "2017/04/15 01:00:00", "n_likes": 1, "price": 100},
{"timestamp": "2017/04/15 01:00:00", "n_likes": 2, "price": 200}
]
load --table Logs_20170416
[
{"timestamp": "2017/04/16 10:00:00", "n_likes": 1, "price": 200},
{"timestamp": "2017/04/16 11:00:00", "n_likes": 2, "price": 300},
{"timestamp": "2017/04/16 11:00:00", "n_likes": 1, "price": 300}
]
logical_count Logs \
--shard_key timestamp \
--columns[count].stage initial \
--columns[count].type UInt32 \
--columns[count].flags COLUMN_SCALAR \
--columns[count].value 'window_count()' \
--columns[count].window.group_keys price \
--filter 'count >= 1'
[
[
0,
0.0,
0.0
],
[
4
]
]
io_flush 新しいオプション --recursive dependent を追加しました。
このオプションによって、書き出し対象とその子オブジェクトだけでなく、関連したオブジェクトも書き出せます。
関連するオブジェクトは次の通りです。:
- 参照されているテーブル
- 関連するインデックスカラム(対象の
TABLE_NAME にソースカラムがある)
- 関連するインデックスカラムのテーブル(対象の
TABLE_NAME にソースカラムがある)
以下は、このオプションを使った例です。:
io_flush --recursive "dependent" --target_name "Users"
さいごに
9.0.1からの詳細な変更点は9.0.2リリース 2019-04-29を確認してください。
それでは、Groongaでガンガン検索してください！
