Postgresは遅くない、ボトルネックはストレージだ

SQLite + NVMeは時にズルをしているように感じる。もし最優先の要件が可能な限り低いレイテンシなら、他に選ぶものは想像できない。

Kestrel (AspNetCore) + SQLite + NVMeをすべて同じマシンで動かすと、私の経験では本当に刺激的な領域に入る。データベースの状態を変更するフォーム送信全体を数十マイクロ秒から低数百マイクロ秒で処理することを想像してほしい。HTTPリクエストを処理するのに必要な実時間は1ミリ秒未満で十分に収まる。リクエストあたりの平均CPU時間が30uSなら、16〜32コアのマシンで毎秒50万リクエストに近づけるだろう。

「昔は」、データベースサーバーから性能を極限まで引き出すために、基盤となるストレージアレイを注意深く計画する必要があった。

大きなメモリプールとSSDを当然のものとして受け止めている開発者の世代がいると思う。データベースが基盤ストレージをマッピングしているという事実に、精神的に乖離がある。

議論でそれを指摘すると明らかになり、ほとんど電球が点くのが見える（パーティショニングとシャーディングについて議論したときに起こった）が、クエリがストレージ上にある何らかのアーティファクトにマッピングされているという関連性には決して至らない。

最近、RDSインスタンスをr8g.からr8gd.に移行した。これによりローカルNVMeが追加され、平均I/Oレイテンシが1.0msから0.1msになったと思う。大きなクエリでは積み重なる！

CloudNativePGはKubernetes Local Storageを主要機能の一つとしてサポートしている [0]

永続ボリューム管理、以下を含む：

PVCテンプレートを使用したLocal Persistent Volumesのサポート。

Pod内でのPersistent Volumesストレージの再利用。

WALファイルとテーブルスペース用の別々のボリューム。

「一時的なPostgreSQLクラスタの劣化」の章 [1] では、その設定方法が説明されており、次のように始まる：

> 標準的なアプローチはサービスの信頼性を確保し、Kubernetesの自己修復機能を活用するが、一時的に劣化したクラスタで運用することが許容されるシナリオもある。これは特に、PostgreSQLデータベースを実行しているKubernetesワーカーノードにストレージがローカルにある、ノードローカルストレージに依存するPostgreSQLクラスタに関連する。ノードローカルストレージ、または単にローカルストレージは、パフォーマンスを向上させるために採用される。

[0] https://cloudnative-pg.io/docs/devel/#main-features

[1] https://cloudnative-pg.io/docs/devel/kubernetes_upgrade/#tem...

これがネットワークストレージの根本的な問題だ：その上に乗るすべてのアプリは、小さなI/Oが高速でローカルであると想定しているため、ネットワークレイテンシが償却されない。

アプリケーションレベルのレプリケーションでは、いくつかのステップに償却できる（例えばコミット時に2PCを行う）。

もちろん、特に別のノードから読み取る必要がある場合にはニュアンスがあるが、だからこそレプリケーションをスタックのできるだけ上に移動させると、一般的にデータベースのパフォーマンスが向上する——データベースはディスクよりもネットワークにいつ触れるべきかをよく知っている。

正直なところ、ネットワーク接続ストレージはHDDでしか意味をなさなかった。単なる「運用上の柔軟性」のためにIOPSとレイテンシの両方で10倍のペナルティを払うのは馬鹿げている。ローカルNVMeとレプリケーションにこだわれば、はるかにシンプルで堅牢なアーキテクチャが得られる——とはいえ、（同様にレプリケートされた）ネットワークブロックストレージソリューションではどちらかを放棄できるわけではないが…

「インデックススキャン」と「インデックスオンリースキャン」の違いを学ぶまで、恥ずかしいほど長い間Postgresを使っていた。

インデックスに関連する列を含めると、Postgresが元のテーブルでランダムに並んだタプルを読む必要がなくなるため、パフォーマンスが大幅に向上する。