多くのノード間でデータをシャーディングすることなく、PostgreSQLに100 TBのデータベース（実際には約90 TB）を設定することは現実的ですか？同様のセットアップに関する成功事例/例はありますか？
回答:
吸収する必要がある毎秒5万回の書き込みは、通常の課題以上のものです。非常に単純な挿入を使用した合成ベンチマークでも、PostgreSQLの制限は約10 K / sで最大になる傾向があり、データベースサイズの点でそれほど大きな獣はありません。
また、その単一のPostgreSQLノードのI / Oシステムは、RAID 10の場合と同じように興味深いものになり、50Kの挿入は50K IOPSに等しいと想定しています（これはおそらく間違っていますが、データベーススキームとインデックスに依存します） ）、これらの書き込みをタイムリーに処理するために数百のディスクを購入する必要がない、非常に優れたアレイとペアになったおよそ100のディスクが必要になります。
シャーディングが簡単で、書き込み負荷が非常に大きいと予想される場合は、シャーディングに進んでください。書き込みのスケーリングは非常に困難です。
それは現実的であり、機能します。パフォーマンスは、RAMの量に大きく依存します。RAMが大きいほど、キャッシュも大きくなり、ディスクにオフロードする前にPostgreSQLがデータをキャッシュできる時間が長くなります。
PostgreSQLはデータをキャッシュに書き込み、キャッシュを時々オフロードします。したがって、1秒あたり5万回のINSERTは5万IOPSに変換されません。レコードをクラスター化し、それらをすべて同時に書き込むので、はるかに少なくなります。
作業の大部分がINSERTである場合、データベースがそれほど大きくても問題はありません。PostgreSQLはあちこちでインデックスを変更する必要がありますが、それは本当に簡単な仕事です。このサイズのデータベースに多数のSELECTがある場合、本当にシャーディングする必要があります。
私はかつて、16GBサーバー上で400TBのOracle DB（Oracle 10g）を扱っていました。データベースのワークロードもプライマリINSERTだったため、1日あたり数回のSELECTと毎日数百万回のINSERTが行われました。パフォーマンスは問題には程遠いものでした。
100TBでは、いくつかの重要な課題があります。それがあなたのために働くかどうかは、あなたがこれらに対処したい方法に依存します。
書き込み負荷を吸収するための十分な方法が必要です。これは書き込み負荷に依存します。しかし、十分に優れたストレージがあれば解決できます。ここで速度は大きな問題です。同様に、読み取りアクセスも注意深く検討する必要があります。
ほとんどのデータベースは小さめのテーブルの束で構成されていませんが、多くの場合、1つまたは2つの非常に大きなテーブルがあり、dbサイズの最大半分になることがあります。PostgreSQLのテーブルごとに32TBのハード制限があります。その後、tidタイプはページカウンターを使い果たします。これは、PostgreSQLのカスタムビルドまたはテーブルのパーティション分割によって処理できますが、最初に対処する必要がある深刻な課題です。
PostgreSQLは、さまざまなタスクに使用できるRAMの量に実際の制限があります。したがって、RAMを増設しても、特定のポイントを超えて役立つ場合とそうでない場合があります。
バックアップ....バックアップはこの規模で興味深いものです。私が知っている60TBのdbは、fsスナップショットバックアップを使用し、その後、バルマンのwalアーカイブのバックアップを偽造する必要がありました。これらの偽のバックアップは、fsスナップショットバックアップのプロキシでした。「これらは偽のバックアップではありません。代替バックアップです！」
データベースがこの範囲に近づいている人がいます。60TBのPostgreSQLデータベースを持つオランダの銀行で働いていた少なくとも1人の個人に会いました。しかし、それは実際にはワークロードに依存し、サイズ自体は問題ではありません。