3

13GBサイズのデータ​​ベースがあります。このコマンドでバックアップすると：

pg_dump -f out.sql --format=p -b -o -O -x -U postgres mydb

ファイルout.sqlのサイズは53GBです。元のデータベースサイズの約4倍です。なぜこれが発生し、どうすればこれを解決できますか？

4

4 に答える 4

2

これは、保存したデータの種類と使用したデータの種類によって異なります。特に、単にSQLファイルにダンプする場合はなおさらです。圧縮はさておき、データベースが適切に設計されていれば、ダンプよりも少ないスペースで済みます。

たとえば、intデータ型は常に4バイトを使用します。この段落の各文字、スペース、ピリオド、またはコンマのサイズは1バイトですが、各数値は32ビットとして保存されます。intサイズは常に4バイトです。ただし、これにより、プラス20億からマイナス20億の数値範囲、つまり10桁の長さになる可能性のある数値が可能になります。言い換えると、ここに表示されているようにその情報を書面でダンプしている場合、9999を超える、または-999未満の数値は、保存されている形式よりも実質的に「大きい」サイズになるため、データベースがほとんど数値である場合その後、それは不一致を説明することができます。（つまり、100以下または-10以上の数字は、書面では事実上「小さい」サイズになりますが、それを除けば、常にsmallint（int2）があります-本当にうるさい場合は、tinyintがあると思いますそのバイトがあなたにとって非常に意味がある場合は拡張）。

別の考えはおそらくdnaデータベースです。ACGとTの文字が4つの可能性しか意味しない場合は、各「文字」を2ビットの情報に保存できます。1バイトに8ビットがあるので、すべてを効果的に保存できます。サイズの4分の1。

いずれにせよ、データベースが使用する形式が何であれ、数値、バイナリ、日付、浮動小数点数、列挙型などです。データベースがプレーンテキストでない場合は、ダンプが元のテキストよりも大きくなる可能性があります。

于 2013-02-18T00:26:48.253 に答える
1

13GBサイズのデータ​​ベースがあります

それは何サイズですか？/ data /ディレクトリが占めるサイズは？それはダンプとは大きく異なります。ダンプはデータのテキスト表現であり、バイナリ表現よりも多くのスペースを占めることが予想されます（たとえば、タイムスタンプフィールドは内部で8バイトを占めます。ダンプでは、確実に8を超える文字列として表されます。文字）。一方、バイナリデータには追加情報（さらに重要なことに、ダンプに入らないインデックスデータ）が含まれています。したがって、バイナリサイズとダンプサイズを比較することはまったく関係ありません

于 2013-02-17T13:14:03.323 に答える
1

サイズが重要な場合は、カスタム形式を使用してみませんか？--format = c

デフォルトでは圧縮を使用します。

于 2013-02-17T13:06:56.093 に答える
0 
pg_dump mydb -oOxU postgres | bzip2 > out.sql.bz2
于 2013-02-17T13:06:08.657 に答える