5

pgsql がファイルシステムにテーブルごとに 1 つのファイルを格納し、すべてのクエリに対して pg_catalog を検索してクエリ プランニングを行う場合、良好なパフォーマンスを維持しながら単一の pgsql データベース内に配置できるテーブルの最大数はいくつですか?

EG: pgsql は単一のデータベース内で 100 万のテーブルを処理できますか? 使用されるファイル システムが ext4 であり、各テーブルに含まれるデータが非常に少ないと仮定すると、超過したディスク ストレージ サイズは問題になりません。この問題は、(1) ファイルシステムに 100 万個のファイルがあることの影響と、(2) pg_catalog に 100 万個のエントリがあることの影響から発生します。

このスレッド (2005) から、http://postgresql.1045698.n5.nabble.com/GENERAL-Maximum-number-of-tables-per-database-and-slowness-td1853836.html - 以下に述べられています (しかし、私はこれのどれだけが最近まだ適用されているかはわかりません）：

ベンジャミン・アライは次のように書いています。

データベースあたりのテーブルの現在の最大数はいくつですか? また、テーブルを増やすと何らかの形でパフォーマンスが低下しますか?

ほとんどの場合、答えはノーです。ただし、Figure テーブル数が 6 に近づくと、pg_catalog は非常に巨大になります。問題は、最適なプランを構築するために、クエリ プランナーがクエリごとに pg_catalog をチェックして、利用可能なインデックス、統計情報と値の分布などを確認する必要があることです。ある時点で、非常に大きな pg_catalog によってシステムが停止する可能性があります。

...

William Yu <[隠しメール]> は次のように書いています。

ベンジャミン・アライは次のように書いています。

データベースあたりのテーブルの現在の最大数はいくつですか? また、テーブルを増やすと何らかの形でパフォーマンスが低下しますか?

ほとんどの場合、答えはノーです。ただし、Figure テーブル数が 6 に近づくと、pg_catalog は非常に巨大になります。

また、データベース ディレクトリに何万ものファイルがある場合のパフォーマンスへの影響についても考慮する必要があります。一部の新しいファイルシステムは特にこれに悩まされていませんが、ディレクトリに数千を超えるエントリがある場合、多くのファイルシステムはルックアップで行き詰まります.

4

3 に答える 3

3

1 つのディレクトリに何百万ものファイルを保持する必要はありません。を使用CREATE TABLESPACEして、別のディレクトリまたは別のディスクにスペースを配置できます。pg_catalog の内部構造については何も知りませんが、最初にテーブルスペースで検索を絞り込む方法は想像できます。これにより、検索時間が大幅に短縮されます。

しかし、それは、一般的にファイルシステムに 100 万個のファイルが存在する可能性がある問題や、pg_catalog の実際の (想像されていない) 問題とは異なります。

単純な (そして誤解を招く可能性がある) テストを簡単に実行できるはずです。お気に入りのスクリプト言語を使用して、それぞれが 5 ～ 6 列のテーブルを 100 万個作成します。

于 2011-10-23T13:50:42.640 に答える
3

一般に、非常に多数のテーブル (数千単位) を使用したことのある私が知っている人によると、db 内のテーブルの数が増えると、計画のオーバーヘッドが増加します。これを問題として抱えていた私が知っている人は、この問題の解決策を見つけなければなりませんでしたが、それらの解決策が何であるかを私に特定していません. データベースプランナーは、クエリを実行する最善の方法を決定するために、テーブルと列に基づいて情報を検索する必要があるため、時間の経過とともにますます肥大化するシステムカタログ内のデータを検索する必要があります. これは、計画時にすべてのクエリに影響します。

基本的な問題は、計画を立てる際に、テーブルのデータを考慮に入れる必要があることです (テーブルの内容を検索する必要があります)、列、および列。興味深いことに、pg_class には oid と relnamespace にインデックスがありますが、relname にはインデックスがなく、簡単に作成することはできません。システム テーブルの唯一のインデックスは UNIQUE 制約であるため、システム カタログを (ソース レベルで、またはこれを行う許可を与えることで) 変更する以外に、この問題を解決する方法がわかりません。

また、パフォーマンスがゆっくりと低下すると予想されるため、これに厳しい制限を課すことはできません。したがって、特定のワークロードで許容できるパフォーマンスに依存します。

それほど多くのテーブルがある場合は、最初にそのうちのいくつを他のデータベースに分割できるかを調べます。

tl; dr: 非常に多数のテーブルでパフォーマンスの問題が発生する可能性があります。それらを解決するには創造的でなければならないことを期待してください。

于 2012-09-29T02:11:30.413 に答える
1

このブログとコメントを含むこの質問は、この問題をさらに明らかにします。

あなたの質問に答えるには：「優れたパフォーマンスを維持しながら」の部分に依存します。「まだ良いパフォーマンス」とは正確には何だと思いますか？そして、正確にどのワークロードで？

あなたの質問を言い換えさせてください: 人間はどれくらいの歯痛に耐えることができますか? 同じ答え！

しかし、どちらの場合も本当の問題は次のとおりです。なぜ本当に気にするのでしょうか? どちらの場合も、より良い解決策は、原因を取り除き、できるだけ早く痛みのない状態にするための行動を取ることです.

于 2011-10-23T13:52:24.543 に答える