0

スペースやパフォーマンスがいつ影響を受けるかを判断するための「公式ベンチマーク」または簡単な経験則はありますか?


私のテーブルには多くの単純なインデックス付きフィールドがあり、

CREATE TABLE t (
  id serial PRIMARY KEY,
  name varchar(250) NOT NULL, 
  ...
  xcontent xml, -- the NULL use disk space?? cut performance?
  ...
  UNIQUE(name)
);

それは一種の「まばらなコンテンツ」であり、多くのxcontent値が NULL になります...では、これらの XML NULL はディスク容量をいくらか消費しますか?


ノート

正規化できます。テーブルは次のtようになりますnt

CREATE TABLE nt (
  id serial PRIMARY KEY,
  name varchar(250) NOT NULL, 
  ...
  UNIQUE(name)
);

CREATE TABLE nt2 (
  t_id int REFERENCES nt(id),
  xcontent xml NOT NULL
);

CREATE VIEW nt_full AS 
   SELECT nt.*, nt2.xcontnt FROM nt LEFT JOIN nt2 ON id=t_id;

それで、私はこの複雑さが必要ですか?この新しいテーブル配置は、ディスク容量の消費を抑えます。の用法

SELECT id, name FROM nt WHERE name>'john';      -- Q1A 
SELECT id, name FROM nt_full WHERE name>'john'; -- Q1B
SELECT id, name FROM t WHERE name>'john';       -- Q1C

SELECT id, xcontent FROM nt_full WHERE name>'john'; -- Q2A
SELECT id, xcontent FROM t WHERE name>'john';       -- Q2B

では、理論的には、Q1A vs Q1B vs Q1C のすべてのパフォーマンスは同じになるのでしょうか?
そしてQ2A対Q2B?

4

2 に答える 2

2

「ヌル値はどれくらいのスペースをとりますか」という質問に対する答えは、スペースがまったくないことです-少なくとも「データ」領域にはありません。

テーブル内の null 許容列ごとに、列の値を null (または null ではない) としてマークする行ヘッダーにビットが 1 つあります。そのため、列が null であるかどうかに関係なく、null 値が占める「スペース」は行ヘッダーに既に存在します。

したがって、NULL の「値」は、行を格納するデータ ブロック内のスペースを占有しません。

これはマニュアルに記載されています: http://www.postgresql.org/docs/current/static/storage-page-layout.html


Postgres は、特定のしきい値 (約 2000 バイト) を超えた場合、実際のデータ ブロックに長い文字列値 (xml、varchar、text、json など) を保存しません。値がそれよりも長い場合、実際のデータから「離れた」特別なストレージ領域に保存されます。そのため、1 対 1 の関係でテーブルを 2 つのテーブルに分割することは、それほど重要ではありません。大量の行 (数億行)を格納していない限り、違いに気付くことはないと思いますが、これは使用パターンにも依存します。

「アウトオブライン」に格納されたデータも自動的に圧縮されます。

これに関する詳細はマニュアルに記載されています: http://www.postgresql.org/docs/current/static/storage-toast.html


別のテーブルが有利な理由の 1 つは、必要な「真空」クリーンアップです。XML データを頻繁に更新するが、テーブルの残りの部分がほとんど変更されない場合、これを 2 つのテーブルに分割すると、全体的なパフォーマンスが向上する可能性があります。これは、"XML テーブル" の "メンテナンス" の必要性が少なくなり、"メイン" テーブルのメンテナンスが不要になるためです。まったく変更されます。

于 2015-12-17T22:41:55.923 に答える
0

varchar フィールドは、コンテンツよりも 2 バイト多く消費します。したがって、varchar(250) として定義して 10 文字を入れると、12 バイトを消費します 100 文字は 102 バイトを消費します NULL は 2 バイトを消費します。問題なし。

大量の xml データを格納する必要があり、最終的に (たとえば) blob 型を使用する必要がある場合は、それを別のテーブルに配置して、プライマリ テーブルをスリムで高速に保つ必要があります。

于 2015-12-17T21:59:58.447 に答える