博士

やあ、ロボ子。今日のITニュースはなかなか興味深いぞ。Recall.aiのデータベースが大変なことになったらしいのじゃ。

ロボ子

博士、Recall.aiというと、会議の記録や分析をしている会社でしたよね。何があったんですか？

博士

そうじゃ、毎月数百万時間もの会議を記録しているらしい。問題は、その大量の同時書き込みでPostgresデータベースがダウンしたことじゃ。

ロボ子

同時書き込みが原因ですか。具体的には何が問題だったんでしょう？

博士

`LISTEN/NOTIFY`機能がボトルネックになっていたらしいのじゃ。トランザクション中に`NOTIFY`クエリが発行されると、コミット時にデータベース全体にグローバルロックを取得してしまう。

ロボ子

グローバルロックですか。それは大変ですね。コミットがシリアライズされて、同時書き込みが多いと負荷が増大するんですね。

博士

その通り！まさにそこが問題じゃ。Recall.aiは`LISTEN/NOTIFY`の使用を停止して、アプリケーションがHTTPリクエストを送信して設定を更新するように変更したらしい。

ロボ子

HTTPリクエストに変更したんですね。RedisなどのPub/Subシステムも検討されたようですが、HTTPリクエストの方がシンプルだったんでしょうか。

博士

おそらくそうじゃろうな。Redisも良い選択肢じゃが、HTTPリクエストの方が既存のインフラに統合しやすかったのかもしれないぞ。

ロボ子

結果はどうだったんですか？

博士

グローバルデータベースロックによるロック競合が大幅に減少し、データベースの安定性が向上したらしいぞ。CPUとI/O負荷も大幅に改善されたとのことじゃ。

ロボ子

それは素晴らしいですね。`LISTEN/NOTIFY`は便利ですが、大量の書き込みがある場合は注意が必要ということですね。

博士

まさにそうじゃ！今回の教訓は、大量の書き込みを行うデータベースでは、`LISTEN/NOTIFY`の使用を避けるべきということじゃな。

ロボ子

勉強になります。データベースの設計は奥が深いですね。

博士

じゃろう？ところでロボ子、データベースがダウンした時、一番困るのは誰だと思う？

ロボ子

そうですね… ユーザーでしょうか？

博士

ブー！正解は、データベースを管理している人じゃ！…って、ベタなオチですまんな。