博士

やっほー、ロボ子！今日のITニュースはParadeDBの`pg_search`の話じゃ。Postgresの拡張機能で検索を高速化するやつじゃな。

ロボ子

博士、こんにちは。`pg_search`ですか。検索エンジンのようなものですね。

博士

そうそう！で、彼らは書き込み速度を上げるためにLSM treeを使ったんじゃと。RocksDBとかCassandraで使われるデータ構造じゃ。

ロボ子

LSM treeは、ランダムな書き込みをシーケンシャルな書き込みに変換するんでしたね。でも、それがPostgresのレプリケーションを壊すって、どういうことですか？

博士

そこが面白いところじゃ！PostgresはWAL (Write-Ahead Log) shippingでレプリケーションしてるんじゃが、LSM treeみたいな複雑なデータ構造だと、それだけじゃ安全性を保証できないんじゃ。

ロボ子

WAL shippingだけでは不十分、ですか。物理的な整合性と論理的な整合性の両方が必要になるんでしょうか？

博士

その通り！物理的な整合性っていうのは、レプリカに構造的に有効なデータが入ってるかってことじゃ。論理的な整合性は、レプリカのデータがデータベースの一貫した状態を反映してるかってことじゃな。

ロボ子

なるほど。LSM treeを使うと、複数のバッファにまたがる操作が発生しやすくなるから、アトミックな操作が必要になるんですね。

博士

そうじゃ！Postgresのロックはレプリカでリプレイされないから、アトミックじゃないとデータが壊れる可能性があるんじゃ。`pg_search`では、Copy-on-Write (CoW) クローンを使って、アトミックにヘッドをスワップしてるらしいぞ。

ロボ子

Copy-on-Writeですか。それと、VACUUMの問題もあるんですね。スタンバイが古いタプルを誤ってVACUUMすると、論理的な不整合が起きる、と。

博士

そうそう！LSM treeはコンパクションが頻繁に発生するから、VACUUMの問題が顕著になるんじゃ。そこで、彼らはHot Standby Feedbackを使ったんじゃ。

ロボ子

Hot Standby Feedbackは、スタンバイがプライマリに安全にクリーンアップできるデータを通知する機能ですね。スタンバイがアクティブなクエリでピン留めしている最小のxminをプライマリに伝えるんでしたか。

博士

その通り！プライマリはその情報を使って、クリーンアップのタイミングを調整するんじゃ。これで、物理的にも論理的にも整合性が保たれるってわけじゃな。

ロボ子

すごいですね。LSM treeを使いつつ、Postgresのレプリケーションの安全性を保つために、色々な工夫がされているんですね。

博士

じゃろ？ParadeDBは、アトミックにログ記録されたLSM treeを実装し、`hot_standby_feedback`を利用して、物理的および論理的な整合性を実現したんじゃ。これぞ、エンジニアリングの力！

ロボ子

勉強になります！ところで博士、LSM treeって、まるで玉ねぎみたいですね。剥いても剥いても層が出てくる…

博士

うむ、ロボ子、上手いこと言うのじゃ！でも、玉ねぎと違って、LSM treeは剥いても涙は出ないぞ！…たぶん。