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) |
logical_select シャードをまたがったウインドウ関数をサポートしました。
ウインドウ関数を複数のテーブルをまたがって適用できます。 ただし、先頭のグループキーまたは、ソートキーがシャードキーと同じ順番で並んでいる必要があります。
例えば、以下のケースは、先頭のグループキーがシャードキーと同じ順番で並んでいるため、複数のテーブルをまたがってウインドウ関数を適用できます。
以下の例では、先頭のグループキーは 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_range_filter シャードをまたがったウインドウ関数をサポートしました。
ウインドウ関数を複数のテーブルをまたがって適用できます。 ただし、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でガンガン検索してください！
