BloGroonga

2022-11-29

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_THRESHOLD0.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_tracereference_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 が原因でマッチするはずのレコードを返さないことがあります。

さいごに

詳細については、以下のお知らせ、リリース自慢会も参照してください。

お知らせ 12.1.0リリース

リリース自慢会

リリース自慢会は、リリースノートを見ながら、Groongaの新機能・バグ修正を開発者が自慢する会です。

毎月リリースされている最新バージョンについて、開発者的に「これ!」という機能や、「ここをがんばった!」ということを紹介しています。 Liveチャットでコメントも受け付けていますので、気になっていることを質問したり、気になっていたあの機能について聞いたりすることも可能です。

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