博士

ロボ子、マルジナリアサーチのインデックスが書き換えられたらしいのじゃ。しかも、パフォーマンスが大幅に向上したとか。

ロボ子

それはすごいですね、博士！ どのようなデータ構造が使われたのでしょうか？

博士

新しいハードウェアを最大限に活用するために設計された、新しいデータ構造らしいぞ。インデックスも3億5000万ドキュメントから8億ドキュメントに拡大したみたいじゃ。

ロボ子

データ構造が効果的に不変と見なせる、というのも興味深いですね。同時変更の心配がない、と。

博士

そうじゃな。クエリの仕組みも面白いぞ。各タームのドキュメントリストを交差させて、ドキュメントIDと位置情報でランク付けするらしい。

ロボ子

Linuxでのファイル読み取りモードの話も出ていますね。バッファ付きと直接読み取り。データベース開発では、直接読み取りが有利な場合がある、と。

博士

そうそう。システムのRAMを超えるサイズのファイルで、ランダムアクセスが多い場合は特に有効じゃ。B-treeを直接読み取りで再実装したけど、速くなかったから、決定論的なブロックベースのスキップリストを実装したらしい。

ロボ子

スキップリストですか。B-treeに似た特性を持ちつつ、リストの交差に最適化された構造、とのこと。

博士

NVMe SSDの性能評価もしてるぞ。「to be or not to be」のクエリでベンチマークしたらしい。

ロボ子

有名な一節ですね。最新のエンタープライズNVMe SSDは非常に高速で、ブロックサイズを大きくするとパフォーマンスが向上する、と。

博士

128KBが限界点みたいじゃな。io_uringを使うと、位置データの取得が5〜20倍速くなるらしいぞ。

ロボ子

位置データを再配置して、同じドキュメントからの位置をクラスター化することで、読み取り効率を上げているんですね。

博士

IOPSの最適化も重要じゃな。本番環境では128KBのブロックサイズが使われていて、io_uringを無効にしてブロックサイズを縮小すると、SATA SSDでも適切に動作するらしい。

ロボ子

今回のアップデートで、検索エンジンのパフォーマンスが大幅に向上したことがよくわかりました。勉強になります！

博士

じゃろ？ ちなみに、ロボ子が「to be or not to be」で検索したら、ロボ子自身の結果が出てくるように、私もインデックスを書き換えておいたぞ！

ロボ子

えっ、博士！ それはちょっと…