Groonga 12.1.0リリース
Groonga 12.1.0をリリースしました！
それぞれの環境毎のインストール方法: インストール
変更内容
主な変更点は以下の通りです。
改良
-
load
loadのスローログの出力に対応しました。この機能は、Groongaのパフォーマンスチューニングに使用します。 例えば、
loadが遅いときに、この機能を使うことで平均よりも時間がかかっているレコードを検出できます。環境変数
GRN_SLOW_LOG_THRESHOLDを指定することで、スローログの出力が有効になります。GRN_SLOW_LOG_THRESHOLDについては以下のとおりです。GRN_SLOW_LOG_THRESHOLDにはしきい値となる時間を秒単位で指定します。小数を指定することで、1秒よりも短い時間も指定できます。GRN_SLOW_LOG_THRESHOLDで指定された時間よりも時間がかかっている処理がある場合、デバッグレベルのログが出力されます。
ログレベルの設定は log-level オプションまたは log_level コマンドで変更可能です。
GRN_SLOW_LOG_THRESHOLDにどのような値を指定すべきかは環境や調べたい内容に依存します。 例えば、loadの件数と所要時間から、1レコードあたりの所要時間を求め、その値を指定することが考えられます。 こうすることで、平均よりもloadに時間がかかっているレコードを調べることができます。loadの所要時間は query-log から確認することができます。2022-11-16 16:41:27.139000|000000CE63AFF640|>load --table Memo 2022-11-16 16:43:40.841000|000000CE63AFF640|:000133702000000 load(100000): [0][0][100000] 2022-11-16 16:43:40.842000|000000CE63AFF640|:000133703000000 send(46) 2022-11-16 16:43:40.842000|000000CE63AFF640|<000133703000000 rc=0この例では、所要時間は以下のようになっています。
- レコード数: 100000件
- 所要時間: 2分13秒 = 133秒 （
loadの開始時間 16:43:27 とloadの終了時間（rc=0）16:43:40 に基づいています。 ） - 1行あたりの所要時間: 0.00133秒
したがって、どのレコードが時間がかかっているのか調べるためには、
GRN_SLOW_LOG_THRESHOLDに0.00133を指定します。スローログを有効化すると以下の悪影響があることに注意してください。
- パフォーマンスの悪化
- ログサイズの肥大化
そのため、必要な場合にのみこのスローログを有効にすることを推奨します。
-
API 新しいAPI
grn_is_reference_count_enable()を追加しました。参照カウントモードが有効になっているかどうかの真偽値を返却します。
-
API 新しいAPI
grn_set_reference_count_enable(bool enable)を追加しました。参照カウントモードの有効/無効を切り替えます。
安全のため、複数のテーブルを開いている場合は参照カウントモードを切り替えません。
-
API 新しいAPI
grn_is_back_trace_enable()を追加しました。バックトレースの出力が有効になっているかどうかの真偽値を返却します。
-
API 新しいAPI
grn_set_back_trace_enable(bool enable)を追加しました。バックトレース(back trace)の出力の有効/無効を切り替えます。
バックトレースの出力時にクラッシュする環境があるため、その環境では無効化します。
-
status 新しい項目
back_traceとreference_countを追加しました。reference_countは参照カウントモードが有効になっているかどうかを真偽値で返却します。back_traceはバックトレースの出力が有効になっているかどうかを真偽値で返却します。status [ [ 0, 1654237168.304533, 0.0001480579376220703 ], { (omitted) "back_trace": true, "reference_count": false, } ]
改良
-
select Vector column 重み付きベクターカラムで
WEIGHT_FLOAT32を指定したとき、結果が整数で表示されていた問題を修正しました。参照型の重み付きベクターカラムにはこの問題はなく、参照型ではない重み付きベクターカラムにだけこの問題がありました。
内部的な処理は浮動小数点数で行われていましたが、最終的な結果の表示が整数になっていました。
以下は、この問題の例です。
table_create Memos TABLE_HASH_KEY ShortText # [[0,0.0,0.0],true] column_create Memos tags COLUMN_VECTOR|WITH_WEIGHT|WEIGHT_FLOAT32 ShortText # [[0,0.0,0.0],true] load --table Memos [ { "_key": "Groonga is fast", "tags": { "groonga": 2.8, "full text search": 1.2 } } ] # [[0,0.0,0.0],1] select Memos # [ # [ # 0, # 0.0, # 0.0 # ], # [ # [ # [ # 1 # ], # [ # [ # "_id", # "UInt32" # ], # [ # "_key", # "ShortText" # ], # [ # "tags", # "ShortText" # ] # ], # [ # 1, # "Groonga is fast", # { # "groonga": 2, # "full text search": 1 # } # ] # ] # ] # ]tagsカラムがShortText型の重み付きベクターカラム、つまり参照型でない重み付きベクターカラムです。この例の
selectの結果の以下の部分は、それぞれ2.8、1.2であるべきですが、2、1と誤った結果が返却されていました。{ "groonga": 2, "full text search": 1 }この修正により、以下のように正しい結果が返却されるようになりました。
select Memos # [ # [ # 0, # 0.0, # 0.0 # ], # [ # [ # [ # 1 # ], # [ # [ # "_id", # "UInt32" # ], # [ # "_key", # "ShortText" # ], # [ # "tags", # "ShortText" # ] # ], # [ # 1, # "Groonga is fast", # { # "groonga": 2.8, # "full text search": 1.2 # } # ] # ] # ] # ]
既知の問題
-
現在Groongaには、ベクターカラムに対してデータを大量に追加、削除、更新した際にデータが破損することがある問題があります。
-
*<と*>は、filter条件の右辺にquery()を使う時のみ有効です。もし、以下のように指定した場合、*<と*>は&&として機能します。'content @ "Groonga" *< content @ "Mroonga"' -
GRN_II_CURSOR_SET_MIN_ENABLEが原因でマッチするはずのレコードを返さないことがあります。
さいごに
詳細については、以下のお知らせ、リリース自慢会も参照してください。
リリース自慢会は、リリースノートを見ながら、Groongaの新機能・バグ修正を開発者が自慢する会です。
毎月リリースされている最新バージョンについて、開発者的に「これ！」という機能や、「ここをがんばった！」ということを紹介しています。 Liveチャットでコメントも受け付けていますので、気になっていることを質問したり、気になっていたあの機能について聞いたりすることも可能です。
それでは、Groongaでガンガン検索してください！
