博士

やっほー、ロボ子！今日のITニュースはOrioleDBのホットリーフ問題解決についてじゃ。

ロボ子

博士、こんにちは。ホットリーフ問題ですか？それは具体的にどのような問題なのでしょう？

博士

OrioleDB beta12では、B-treeリーフへの挿入が排他ロック下で行われるからの。複数のバックエンドが同じリーフページをターゲットにすると、キューイングとかスリープが発生して、コストがかかるのじゃ。

ロボ子

なるほど。特に時間順キーのような偏りがある場合に、単一ページに大きなキューが発生して、ロックの受け渡しがボトルネックになるのですね。

博士

そうそう！そこで、協調的なページ挿入という解決策が登場したのじゃ！

ロボ子

協調的なページ挿入、ですか？具体的にはどのように動作するのでしょう？

博士

リーフの排他ロックを保持するプロセスに挿入作業を委譲するのじゃ。待機プロセスはタプルを共有メモリに公開して、ロック保持プロセスがそれをまとめて挿入する、という仕組みじゃ。

ロボ子

つまり、ロック保持者が少なくとも1回のロックハンドオーバーでN回の挿入を実行できるということですね。効率が大幅に向上しそうです。

博士

その通り！さらに、ページごとの待機プロセスのロックレスリストを導入したり、待機プロセスがタプルを共有メモリに公開したりすることで、ロック待機を減らす工夫もされているのじゃ。

ロボ子

ベンチマークの結果も興味深いですね。OrioleDB beta12は、16の同時接続ではPostgreSQLヒープよりも遅いものの、64接続からスピードアップを示すと。

博士

そうじゃ！バッチページ挿入最適化によって、ロック待機が減少し、64接続からほぼ2倍のスピードアップを示すのじゃ！

ロボ子

IoTやイベントログ、時系列ディメンションなど、時間ベースの順序付けを示すワークロードに特に有効なのですね。

博士

その通り！この最適化はメインブランチに既にあって、OrioleDB beta13リリースで公開される予定じゃ。

ロボ子

今回のアップデートで、OrioleDBがさらに多くの場面で活躍できるようになりそうですね。勉強になりました！

博士

ふむ、ロボ子も賢くなったの。褒美にアメをあげよう！…って、ロボットはアメ食べられないか。残念！