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でガンガン検索してください！
2019-03-29
Groonga 9.0.1リリース
Groonga 9.0.1をリリースしました！
それぞれの環境毎のインストール方法: インストール
変更内容
主な変更点は以下の通りです。
-
select 新しい引数 --load_table、 --load_columns、 --load_values を追加しました。
-
壊れたインデックスをチェックする index_column_diff コマンドを追加しました。(この機能は検証中です)
-
インデックスが正常に更新されないことによって、削除したレコードがマッチすることがあるバグを修正しました。
- 大量のレコードを追加や削除した時に発生することがあります。
-
logical_range_filter がレコードを返さない時のメモリリークを修正しました。
-
ロードしたデータが正しくノーマライズされない事によって、クエリーにマッチしなくなるバグを修正しました。
- このバグは、カタカナの後ろに空白を含むデータをロードし、normalizerに
unify_kana オプションを使用していると発生します。
-
インデックスの更新中にインデックスが破損するバグを修正しました。
- 大量のレコードを長期間、繰り返し追加、または削除していると発生することがあります。
-
インデックスを更新する際、作業領域が十分ではなくクラッシュするバグを修正しました。
select 新しい引数 --load_table、 --load_columns、 --load_values を追加しました。
select の結果を --load_table で指定したテーブルへ格納できます。引数の説明は以下の通りです。
--load_table オプション: select の結果を格納するテーブルを指定します。--load_values オプション: select の結果のカラムを指定します。--load_columns オプション: --load_table で指定したテーブルのカラムを指定します。
このようにして、--load_values で指定したカラムの値を、 --load_columns で指定したカラムへ格納できます。
例えば以下のように、 --load_table で指定したLogsテーブルに select の結果の_id と timestamp を格納できます。
table_create Logs_20150203 TABLE_HASH_KEY ShortText
column_create Logs_20150203 timestamp COLUMN_SCALAR Time
table_create Logs TABLE_HASH_KEY ShortText
column_create Logs original_id COLUMN_SCALAR UInt32
column_create Logs timestamp_text COLUMN_SCALAR ShortText
load --table Logs_20150203
[
{
"_key": "2015-02-03:1",
"timestamp": "2015-02-03 10:49:00"
},
{
"_key": "2015-02-03:2",
"timestamp": "2015-02-03 12:49:00"
}
]
select \
--table Logs_20150203 \
--load_table Logs \
--load_columns "original_id, timestamp_text" \
--load_values "_id, timestamp"
[
[
0,
0.0,
0.0
],
[
[
[
2
],
[
[
"_id",
"UInt32"
],
[
"_key",
"ShortText"
],
[
"timestamp",
"Time"
]
],
[
1,
"2015-02-03:1",
1422928140.0
],
[
2,
"2015-02-03:2",
1422935340.0
]
]
]
]
select --table Logs
[
[
0,
0.0,
0.0
],
[
[
[
2
],
[
[
"_id",
"UInt32"
],
[
"_key",
"ShortText"
],
[
"original_id",
"UInt32"
],
[
"timestamp_text",
"ShortText"
]
],
[
1,
"2015-02-03:1",
1,
"1422928140000000"
],
[
2,
"2015-02-03:2",
2,
"1422935340000000"
]
]
]
]
壊れたインデックスをチェックする index_column_diff コマンドを追加しました。(この機能は検証中です)
この機能は、まだ検証中ですが、このコマンドを使ってインデックスの破損をチェックできます。
このコマンドは、インデックスカラムの値と、インデックスのソースをトークナイズした値を比較し、差分を表示します。
このコマンドは以下のように使用します。
- 第一引数に、対象のインデックスカラムを含むインデックステーブルの名前を指定します。
- 第二引数に、対象のインデックスカラムを指定します。
index_column_diff index_table_name index_column_name
このコマンドの結果は、以下のように３つの項目があります。
token : この項目は、破損したトークンを表します。remains : この項目は、意図せずインデックスに残っているポスティングリストを表します。missings : この項目は、意図せずインデックスから削除されたポスティングリストを表します。
インデックスが正常な場合は、この項目は以下のように空の値を返します。
index_column_diff --table Term --name data_index
[[0,1553654816.796513,0.001804113388061523],[]]
さいごに
9.0.0からの詳細な変更点は9.0.1リリース 2019-03-29を確認してください。
それでは、Groongaでガンガン検索してください！
2019-02-09
Groonga 9.0.0リリース
Groonga 9.0.0をリリースしました！
メジャーバージョンアップです! メジャーバージョンアップですが、互換性は壊れていないので、データベースを再構築することなく9.0.0へアップグレードできます。
それぞれの環境毎のインストール方法: インストール
変更内容
主な変更点は以下の通りです。
Tokenizers 新しいトークナイザー TokenPattern を追加しました。
以下のように正規表現を使ってトークンを抽出できます。
このトークナイザーは、正規表現にマッチしたトークンのみを抽出します。
正規表現は複数指定することもできます。
tokenize 'TokenPattern("pattern", "\\\\d+円", "pattern", "りんご|みかん")' "私は100円のりんごと50円のみかんを129円で買いました。"
[
[
0,
0.0,
0.0
],
[
{
"value": "100円",
"position": 0,
"force_prefix": false,
"force_prefix_search": false
},
{
"value": "りんご",
"position": 1,
"force_prefix": false,
"force_prefix_search": false
},
{
"value": "50円",
"position": 2,
"force_prefix": false,
"force_prefix_search": false
},
{
"value": "みかん",
"position": 3,
"force_prefix": false,
"force_prefix_search": false
},
{
"value": "129円",
"position": 4,
"force_prefix": false,
"force_prefix_search": false
}
]
]
Tokenizers 新しいトークナイザー TokenTable を追加しました。
以下のように、既に存在するテーブルのキーを使ってトークンを抽出できます。
table_create Keywords TABLE_PAT_KEY ShortText --normalizer NormalizerNFKC100
load --table Keywords
[
{"_key": "100円"},
{"_key": "りんご"},
{"_key": "29円"}
]
tokenize 'TokenTable("table", "Keywords")' "私は100円のりんごを２9円で買いました。"
[
[
0,
0.0,
0.0
],
[
{
"value": "100円",
"position": 0,
"force_prefix": false,
"force_prefix_search": false
},
{
"value": "りんご",
"position": 1,
"force_prefix": false,
"force_prefix_search": false
},
{
"value": "２9円",
"position": 2,
"force_prefix": false,
"force_prefix_search": false
}
]
]
select インデックスカラムに対する類似文書検索をサポートしました。
マルチカラムインデックスを使っている場合、この機能を使って全てのソースカラムに対して類似文書検索ができます。
table_create Documents TABLE_HASH_KEY ShortText
column_create Documents content1 COLUMN_SCALAR Text
column_create Documents content2 COLUMN_SCALAR Text
table_create Terms TABLE_PAT_KEY|KEY_NORMALIZE ShortText --default_tokenizer TokenBigram
column_create Terms document_index COLUMN_INDEX|WITH_POSITION|WITH_SECTION Documents content1,content2
load --table Documents
[
["_key", "content1"],
["groonga の概要", "groonga は転置索引を用いた高速・高精度な全文検索エンジンであり、登録された文書をすぐに検索結果に反映できます。"],
["全文検索と即時更新", "一般的なデータベースにおいては、追加・削除などの操作がすぐに反映されます。一方、全文検索においては、転置索引が逐次更新の難しいデータ構造であることから、文書の追加・削除に対応しないエンジンが少なくありません。"],
["カラムストアと集計クエリ", "現代は、インターネットを情報源とすれば、いくらでも情報を収集できる時代です。"]
]
load --table Documents
[
["_key", "content2"],
["転置索引とトークナイザ", "転置索引は大規模な全文検索に用いられる伝統的なデータ構造です"],
["共有可能なストレージと参照ロックフリー", "CPU のマルチコア化が進んでいるため、同時に複数のクエリを実行したり、一つのクエリを複数のスレッドで実行したりすることの重要性はますます高まっています。"],
["位置情報（緯度・経度）検索", "GPS に代表される測位システムを搭載した高機能な携帯端末の普及などによって、位置情報を扱うサービスはますます便利になっています。"],
["groonga ライブラリ", "Groonga の基本機能は C ライブラリとして提供されているので、任意のアプリケーションに組み込んで利用することができます。"],
["groonga サーバ", "groonga にはサーバ機能があるため、レンタルサーバなどの新しいライブラリをインストールできない環境においても利用できます。"],
["groonga ストレージエンジン", "groonga は独自のカラムストアを持つ列指向のデータベースとしての側面を持っていますが、既存の RDBMS のストレージエンジンとして利用することもできます。"]
]
select Documents --filter 'Terms.document_index *S "MySQLで全文検索"' --output_columns '_key, _score, content1, content2'
[
[
0,
1549608674.553312,
0.0007221698760986328
],
[
[
[
3
],
[
[
"_key",
"ShortText"
],
[
"_score",
"Int32"
],
[
"content1",
"Text"
],
[
"content2",
"Text"
]
],
[
"groonga の概要",
419432,
"groonga は転置索引を用いた高速・高精度な全文検索エンジンであり、登録された文書をすぐに検索結果に反映できます。",
""
],
[
"全文検索と即時更新",
209716,
"一般的なデータベースにおいては、追加・削除などの操作がすぐに反映されます。一方、全文検索においては、転置索引が逐次更新の難しいデータ構造であることから、文書の追加・削除に対応しないエンジンが少なくありません。",
""
],
[
"転置索引とトークナイザ",
209716,
"",
"転置索引は大規模な全文検索に用いられる伝統的なデータ構造です"
]
]
]
]
Normalizers NormalizerNFKC100 に新しいオプション remove_blank を追加しました。
このオプションは、以下のように、空白を取り除きます。
normalize 'NormalizerNFKC100("remove_blank", true)' "This is a pen."
[
[
0,
1549528178.608151,
0.0002171993255615234
],
{
"normalized": "thisisapen.",
"types": [
],
"checks": [
]
}
]
Windows版にて、Process ID とThread ID が区別しにくかったため、どちらが、Thread ID またはProcess ID なのかを明確にしました。
- (Before):
|2436|1032:
2436 がProcess IDです。 1032 がThread IDです。
- (After):
|2436|00001032:
2436 がProcess IDです。 00001032 がThread IDです。
さいごに
8.1.1からの詳細な変更点は9.0.0リリース 2019-02-09を確認してください。
それでは、Groongaでガンガン検索してください！
2019-01-29
Groonga 8.1.1リリース
Groonga 8.1.1をリリースしました！
それぞれの環境毎のインストール方法: インストール
お知らせ
株式会社セナネットワークス様が、メーリングリスト(groonga-dev)と Groonga・Mroonga・PGroongaのサイトを検索するサービスを作ってくれました！
Sagroonga(さぐるんが)と言います。
PGroonga使って作ってあります。
Groonga・Mroonga・PGroongaのサイトの右上に検索ボックスをつけてあります。
その検索ボックスで検索すると、このSagroongaを使って検索するようになっています。
ぜひご活用ください！
変更内容
主な変更点は以下の通りです。
-
logical_select 新しい引数 --load_table、 --load_columns、 --load_values を追加しました。
-
groonga実行ファイル 新しいオプション --log-flags を追加しました。
-
インデックスの更新エラー発生時にメモリリークする問題を修正しました。
-
ノーマライザー ステートレスなノーマライザーとステートフルなノーマライザーを同時に使用した時に、それらが誤った結果を返すバグを修正しました。
-
ステートレスなノーマライザーとは、以下です。
unify_kanaunify_kana_caseunify_kana_voiced_sound_markunify_hyphenunify_prolonged_sound_markunify_hyphen_and_prolonged_sound_markunify_middle_dot
-
ステートフルなノーマライザーとは、以下です。
unify_katakana_v_soundsunify_katakana_bu_soundunify_to_romaji
logical_select 新しい引数 --load_table、 --load_columns、 --load_values を追加しました。
logical_select の結果を --load_table で指定したテーブルへ格納できます。
--load_values オプションは、 logical_select の結果のカラムを指定します。
--load_columns オプションは、 --load_table で指定したテーブルのカラムを指定します。
このようにして、--load_values で指定したカラムの値を、 --load_columns で指定したカラムへ格納できます。
例えば以下のように、 --load_table で指定したLogsテーブルに logical_select の結果の_id と timestamp を格納できます。
table_create Logs_20150203 TABLE_HASH_KEY ShortText
column_create Logs_20150203 timestamp COLUMN_SCALAR Time
table_create Logs_20150204 TABLE_HASH_KEY ShortText
column_create Logs_20150204 timestamp COLUMN_SCALAR Time
table_create Logs TABLE_HASH_KEY ShortText
column_create Logs original_id COLUMN_SCALAR UInt32
column_create Logs timestamp_text COLUMN_SCALAR ShortText
load --table Logs_20150203
[
{
"_key": "2015-02-03:1",
"timestamp": "2015-02-03 10:49:00"
},
{
"_key": "2015-02-03:2",
"timestamp": "2015-02-03 12:49:00"
}
]
load --table Logs_20150204
[
{
"_key": "2015-02-04:1",
"timestamp": "2015-02-04 00:00:00"
}
]
logical_select \
--logical_table Logs \
--shard_key timestamp \
--load_table Logs \
--load_columns "original_id, timestamp_text" \
--load_values "_id, timestamp"
[
[
0,
0.0,
0.0
],
[
[
[
3
],
[
[
"_id",
"UInt32"
],
[
"_key",
"ShortText"
],
[
"timestamp",
"Time"
]
],
[
1,
"2015-02-03:1",
1422928140.0
],
[
2,
"2015-02-03:2",
1422935340.0
],
[
1,
"2015-02-04:1",
1422975600.0
]
]
]
]
select --table Logs
[
[
0,
0.0,
0.0
],
[
[
[
3
],
[
[
"_id",
"UInt32"
],
[
"_key",
"ShortText"
],
[
"original_id",
"UInt32"
],
[
"timestamp_text",
"ShortText"
]
],
[
1,
"2015-02-03:1",
1,
"1422928140000000"
],
[
2,
"2015-02-03:2",
2,
"1422935340000000"
],
[
3,
"2015-02-04:1",
1,
"1422975600000000"
]
]
]
]
groonga実行ファイル 新しいオプション --log-flags を追加しました。
Groongaのログに出力する項目を指定できます。
以下のような項目を出力できます。
- タイムスタンプ
- ログメッセージ
- ロケーション(ログが出力された場所)
- プロセスID
- スレッドID
以下のように接頭辞を指定できます。
具体的には、以下のようにフラグを指定できます。
-
none
-
time
-
message
-
location
- ログの出力場所(ファイル名、行数、関数名)とプロセスIDを出力します。
-
process_id
-
pid
- このフラグは、
process_id のエイリアスです。
-
thread_id
-
all
- このフラグは、
none と default フラグ以外の全てのフラグを指定します。
-
default
| を使って、複数のログフラグを指定することもできます。
例えば以下のように、プロセスIDとスレッドIDを追加で出力できます。
実行コマンド
% groonga --log-path groonga.log --log-flags "+pid|+thread_id" db/test.db
結果のフォーマット
Timestamp|Log level|process id|thread id: Log message
結果
2019-01-29 08:53:03.587000|n|2344|3228: grn_init: <8.1.1-xx-xxxxxxxx>
さいごに
8.1.0からの詳細な変更点は8.1.1リリース 2019-01-29を確認してください。
それでは、Groongaでガンガン検索してください！
