BloGroonga

2018-03-29

Groonga 8.0.1リリース

今日は肉の日ですね!

Groonga 8.0.1をリリースしました!

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

変更内容

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

  • [ログ] クエリーログ内でfilterの条件を表示するようにしました。
  • Windows版のGroongaにて、*.pdb*.dll*.exeと同じディレクトリにインストールされるようにしました。
  • [logical_count] filteredステージの動的カラムをサポートしました。
  • [logical_count] フィルタータイミングを新規追加しました。
  • [logical_select] フィルタータイミングを新規追加しました。
  • [logical_range_filter] 大きい結果セットに対するウィンドウ関数の動作を最適化しました。
  • [select] --match_escalationパラメーターを追加しました。
  • [httpd] バンドルしているnginxのバージョンを1.13.10に更新しました。
  • 共通接頭辞がどのトークンにもマッチしない時にメモリーリークする問題を修正しました。
  • 同一プロセスで複数のデータベースを開いている時に、異なるデータベースのキャッシュを使用してしまう問題を修正しました。
  • 比較時(>,>=,<,<=,==,!=)に、定数がオーバーフローまたはアンダーフローし得る問題を修正しました。

[ログ] クエリーログ内でfilterの条件を表示するようにしました。

この変更によって、どの条件でfilterされるかがわかるようになります。 具体的には、以下のように表示されます。

2018-02-15 19:04:02.303809|0x7ffd9eedf6f0|:000000013837058 filter(17): product equal "test_product"

上記は、product == "test_product"の条件で17件まで絞り込まれたことを表します。 この機能はデフォルトで無効になっており、以下の環境変数を設定することで有効になります。

GRN_QUERY_LOG_SHOW_CONDITION=yes

[logical_count] filteredステージの動的カラムをサポートしました。

いままで、logical_countでは、initialステージの動的カラムしかサポートしていませんでしたが、filteredステージの動的カラムも使えるようになります。

[logical_count][logical_select] フィルタータイミングを新規追加しました。

filteredステージで生成された動的カラムを使って、フィルター出来るようになります。 具体的には、以下のように使用します。

logical_select \
    --logical_table Entries \
    --shard_key created_at \
    --columns[n_likes_sum_per_tag].stage filtered \
    --columns[n_likes_sum_per_tag].type UInt32 \
    --columns[n_likes_sum_per_tag].value 'window_sum(n_likes)' \
    --columns[n_likes_sum_per_tag].window.group_keys 'tag' \
    --filter 'content @ "system" || content @ "use"' \
    --post_filter 'n_likes_sum_per_tag > 10' \
    --output_columns _key,n_likes,n_likes_sum_per_tag

  # [
  #   [
  #     0, 
  #     1519030779.410312,
  #     0.04758048057556152
  #   ], 
  #   [
  #     [
  #       [
  #         2
  #       ], 
  #       [
  #         [
  #           "_key", 
  #           "ShortText"
  #         ], 
  #         [
  #           "n_likes", 
  #           "UInt32"
  #         ], 
  #         [
  #           "n_likes_sum_per_tag", 
  #           "UInt32"
  #         ]
  #       ]
  #       [
  #         "Groonga", 
  #         10, 
  #         25
  #       ], 
  #       [
  #         "Mroonga", 
  #         15, 
  #         25
  #       ]
  #     ]
  #   ]
  # ]

--post_filter内で、filteredステージで作成した動的カラムn_likes_sum_per_tagを使用しているところがポイントです。 上記の例はlogical_selectですが、logical_countでも同様に使用できます。

[logical_range_filter] 大きい結果セットに対するウィンドウ関数の動作を最適化しました。

一致するレコードが十分見つかった場合は、残りのウィンドウに対してウィンドウ関数を適用しません。

現状では、この最適化は、最適化によるオーバーヘッドが無視出来ない場合、小さな結果セットに対しては、無効になります。

[select] --match_escalationパラメーターを追加しました。

--match_escalation yes とすることによって、マッチ演算のエスカレーションを強制的に有効にします。このパラメータは、 --match_escalation_threshold 99999....999 よりも強力です。--match_escalation yes は、 SOME_CONDITIONS && column @ 'query' もエスカレーションしますが、 --match_escalation_threshold ではしないためです。

デフォルトは、--match_escalation auto です。これは、既存の動作と同じです。

--match_escalation no とすることで、マッチ演算のエスカレーションを無効にできます。これは、 --match_escalation_threshold -1 と同様の動きになります。

共通接頭辞がどのトークンにもマッチしない時にメモリーリークする問題を修正しました。

以下の例のように、Groongaのあいまい検索において、共通の接頭辞がどのトークンにもマッチしない時にメモリーリークしていた問題を修正しました。

table_create Users TABLE_NO_KEY
[[0,0.0,0.0],true]
column_create Users name COLUMN_SCALAR ShortText
[[0,0.0,0.0],true]
table_create Names TABLE_PAT_KEY ShortText
[[0,0.0,0.0],true]
column_create Names user COLUMN_INDEX Users name
[[0,0.0,0.0],true]
load --table Users
[
{"name": "Tom"},
{"name": "Tomy"},
{"name": "Pom"},
{"name": "Tom"}
]
[[0,0.0,0.0],4]
select Users --filter 'fuzzy_search(name, "Atom", {"prefix_length": 1})'   --output_columns 'name, _score'   --match_escalation_threshold -1
[[0,0.0,0.0],[[[0],[["name","ShortText"],["_score","Int32"]]]]]

同一プロセスで複数のデータベースを開いている時に、異なるデータベースのキャッシュを使用してしまう問題を修正しました。

プロセス内でキャッシュを共有していたため、同一のプロセスで複数のデータベースを開いている場合、別のデータベースのキャッシュから結果を返してしまう事がある現象を修正しました。

比較時(>,>=,<,<=,==,!=)に、定数がオーバーフローまたはアンダーフローし得る問題を修正しました。

以下の例のように、比較対象のカラムの型を超える値を指定した場合に、オーバーフローまたは、アンダーフローを起こし、意図しない検索結果が返ってきてしまう現象を修正しました。

table_create Values TABLE_NO_KEY
[[0,0.0,0.0],true]
column_create Values number COLUMN_SCALAR Int16
[[0,0.0,0.0],true]
load --table Values
[
{"number": 3},
{"number": 4},
{"number": -1}
]
[[0,0.0,0.0],3]
select Values   --filter 'number > 32768'   --output_columns 'number'
[[0,1522305525.361629,0.0003235340118408203],[[[3],[["number","Int16"]],[3],[4],[-1]]]]

32768がInt16の範囲(-32,768 ~ 32,767)を超えているため、オーバーフローを起こし、number > 32768number > -32768と評価されていました。 今回の修正で、上記のようにオーバーフローまたは、アンダーフローが起きた場合には、何も結果を返さないように修正しています。

さいごに

8.0.0からの詳細な変更点は8.0.1リリース 2018-03-29を確認してください。

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