【海外の反応】Postgresは遅くない、遅いのはストレージ
姉妹サイトの新着
ClickHouseのブログに載った「Postgresは遅くない、遅いのはストレージだ」という記事がHacker Newsで議論を呼んだ。ローカルNVMeとAWSのEBSのようなクラウドのネットワークストレージでは、I/Oレイテンシに10倍以上の差が出ることがあり、「クラウドは非効率」と断じる声が上がった一方、ホスト障害時の可用性やバックアップの容易さを理由にネットワークストレージを擁護する声も多く、意見が割れた。さらに話は脱線し、この記事タイトル自体がLLMが書いたような文体だという余談的な論争にも発展した。
Postgresは遅くない、遅いのはストレージだ
出典: clickhouse.com / 元記事はこちら
「ベアメタルに比べてVMがどれだけ劣るか分かっていないエンジニアが多すぎる」って、嘘を売りつけておいて被害者を責めてるだけじゃないか？
ほぼ同意だけど、その場合レプリケーションやフェイルオーバー、バックアップを自分で面倒見ないといけなくなる。レプリケーション済みのブロックストレージを使えば、その問題をほぼ外部に切り出せる。
RDSの自動バックアップとは別にバックアップシステムを組まないといけないの、自分だけじゃないはず。あれ変なフォーマットだし遅いんだよね。
ローカルストレージだとホストが死んだらVMも死ぬ。EBSならそうならない、別のホストで起動し直せるから。EBSは複数ホストにまたがってレプリケーションされてもいる。
信頼性だよ。汎用DBMSはおそらく数十年の実戦テストを積んでる。君が「雰囲気で書かせた（vibecoded）」DBMSにはそれが無い。
機会コストの問題。Postgresをやめることで儲かるならどうぞやればいい。でも大抵は、本業に直結する他の問題に対処すべきなんじゃないか。
自分の車にFSD（自動運転）が付いていてほしいのと同じ理由だよ。自分のFSDが車を組み立てる方法を知っていて、それが勝手に走るようにしてほしいわけじゃない。
この手のタイトルの形式は、LLMが出てくるずっと前からトークやブログ記事でよくあるものだよ。
最近は「AI生成っぽい」という苦情の方が、苦情対象のコンテンツより鬱陶しく感じるようになってきた。
その発言、いろいろ前提を背負いすぎてるな。
試してみればいい（笑）。あの「Goose」という言語を見てみるといい。君のエージェントはバカで、まともなアイデアを出すには膨大なPDFが必要で、しかも君自身それをどう絞り込めばいいか分かってない。そしてストレージ・クエリプランナー・コンパイラ層の間の整合性を取ることにずっと失敗し続けて、永遠に迷走することになる。
誰も止めてないけど？
そう、多くの人はDBの構造やどんなインデックスを付けるべきか分かっていない。でも、それが君が向き合っている問題だからといって、それが唯一の問題というわけじゃない。
Postgres特有のどんなスキーマやクエリの工夫を使って、パフォーマンスを大きく改善してるの？
例えば「カラムテトリス」（列の並び順の最適化）。これだけで、本来なら専用の仕組みを立ち上げなければならなかったOLAPワークロードを、何度かPostgresのままで済ませられた。
他サイトの新着
ストレージが物理的に遠すぎたら、いいスキーマやいいクエリを書いても救われないよ（笑）
その通り。自分の体験はこんな感じ：「おっ、面白そうなタイトル」→「うわ…スロップ（AI生成の質の低いコンテンツ）まみれ。がっかり、悲しみ、落胆、軽く見られて真剣に扱われていない感じ、世界から疎外される感覚」→「よし、リンクを閉じよう」。まだここで人間の仲間たちと一緒にいられて嬉しい。Hacker Newsは最後の砦という感じがする。フロントページからスロップを何とかフィルタできないものかな。それができたら最高だ。
理由もなく車輪の再発明をしないなんて、想像できるか？でも心配ない、きっと「ミスをしないこと」みたいな最新のプロンプト技術が使われるから、すべて問題ないはずだ（皮肉）
その主張に同意する。それに、このタイトルは「Postgresを20倍速くした」系のタイトルに比べれば、すでに重要な情報を全部含んでいる。とはいえ、開発者やインフラ担当者がローカルストレージの方がネットワーク/クラスタファイルシステムより速いと知らないのであれば…（それはそれで問題だ）
どちらとも断言しづらいけど、記事の本文自体がLLM生成っぽい文章で溢れてる。例えば結論の一文「結論は意図的にタイトルより範囲を狭めている」とか、まさにそれっぽい。
それに、そのバックアップのライフサイクルは普通インスタンス自体に紐づいている。誰かがインスタンスを削除したら、バックアップも一緒に消える。
それが現実だというのがそもそもおかしいし、しかもそのバックアップを他の場所にコピーするのがやたら面倒な作りになっている。いかにもクラウドらしいね。
「SAN」（ストレージエリアネットワーク）で調べてみて。EBSは見た目は普通のローカルブロックデバイス、/dev内の別のディスクに見えるけど、実際はネットワーク越しに提供されている。その実装は（利用者から見て）透過的になっている。
この話題の背景と論点
この記事はAndy Pavlo系の講演を元にしたClickHouseのブログ解説がベースで、AWSのEBSのようなネットワーク接続ストレージは物理的に分散配置されるため、I/OレイテンシがローカルNVMeより一桁以上大きくなりやすいという技術的背景がある。スレで意見が割れたのは、この遅延を「クラウドの欠陥」と見るか、「可用性やバックアップの容易さと引き換えに許容すべきコスト」と見るかの立場の違いだ。EBSは複数ホストにレプリケートされており、ホスト障害時にVMを別ホストで即座に起動し直せる点は、ローカルNVMe構成には無い利点として繰り返し指摘された。一方でローカルNVMeを使う場合でもレプリケーションや障害対応は結局自前で実装する必要があり、「どちらが本当に楽か」はワークロードやチーム規模によって変わるという点は、スレの中でも結論が出ていない。また本題から脱線し、記事タイトル自体がAI生成っぽいという指摘が盛り上がったのも、技術論とは別の最近のHN特有の空気を表している。
※本記事は海外掲示板 Hacker News のスレッド「Postgres isn’t slow, your storage is」から抜粋し、編集部で日本語に意訳したものです。訳文の責任は当サイトにあります。
まだコメントはありません。