StartupXO
検索
日本語

Find XO: PostgreSQLが遅い原因はストレージかもしれないというベンチマーク発表の整理(clickhouse.com)

おすすめなし startupxo 編集部の意見 1 / コメント 0

書く言語: 韓国語書かれた言語で読む

要約 / 元記事を読む ↗

- この記事は、PostgreSQLのデータが数百GBからTB規模に増えたときの遅さの原因がストレージにあるかもしれないという発表内容をまとめたものです。発表者はSai Srirampurで、ClickHouseブログに掲載されたPOSETTE 2026の発表要約です。 - 元のベンチマークは、33億行のpgbenchワークロードを、gp3 EBS(3,000 IOPS設定)とローカルNVMeインスタンスストレージでそれぞれ5分間実行した結果です。中央値のTPSはNVMeで16,030、EBSで1,734と報告されました。 - 原文によると、EBS側のトランザクション遅延37msのうち、ページ読み取りが約19ms、コミット時のWAL同期が約11msでした。これは発表者のベンチマーク測定値で、その条件下での数値です。 - 高可用性については、同期レプリケーションの待機サーバー候補二台(ANY 1構成)を用い、バックアップはWAL-Gのようなツールでオブジェクトストレージに別途保管する構成が発表で提案されました。
掲載元

Hacker News ↗ / おすすめ 55 / コメント 27

似たような経験はありますか?そのときどうしたか、一言二言で教えてください。製品に詳しくなくても大丈夫です。

ログインしてコメント

コメント 1

編集部の意見startupxo

EBSセッション64個のうち29個がDataFileRead待機に引っかかっていた様子が、数字より先に目に入ります。ただ、原文が一時点のスナップショットだと明記しているので、平均として読むより、その瞬間の様子として受け止めるのが妥当でしょう。インスタンスのストレージがノードと一緒に消えてしまう問題は、結局、複製とバックアップをどう設計するかの話につながりますが、その費用がどれだけ増えるかは原文に出てこないので、ご自身で見積もる必要がありそうです。似た構成を運用したことがある方は、複製の面で一番面倒だったのはどこだったのか気になります。
書く言語: 韓国語

キーボード操作

上下矢印キーで投稿を選び、Enterで開きます。

↑ / ↓
前の投稿 / 次の投稿
Enter
選んだ投稿の要約とコメントを開く
Tab
投稿やコメントのボタンに移動してEnter

入力欄では通常どおり入力できます。TabとEnterはいつでも使えます。