[pgsql-jp: 37749] Re: INDEXを残したまま大量データを高速に挿入したい

[Y. Shimada]

島田@Storgateです。

　だんだんファイルシステムやストレージとの話になってきていますが、
性能問題を語る時に「取り扱うデータ量」「サーバ性能・ 
CPU,memory,bus」
「ストレージ性能、I/O cont. + Disk」、それに「O/S +  
FileSystem」を
定義してからでないと、ディスカッションが発散してしまいます。

　デフラグと insert ですが、Linuxで ext2 であ 
れば、デフラグ後十分な
連続エリアがDB用ディスクに確保出来れば、書き込みボトルネッ 
クの原因が
ディスクヘッド依存であったなら、性能向上が見込めるでしょう。
また、ext3 であった場合は、ジャーナル領域が何処に置かれて 
いるか、
そのサイズがどのくらいか等が関係して来るはずですので、デフラグとの
因果関係ははっきりしません。

　また、業務用のシステムであれば、ほとんど SCSI/FC系の  
HDD を用いた
RAID-Storage (Mirror構成や level-5構成）と、サーバとスト 
レージ間も
同様に SCSI/FC でしょう。ここで、ストレージ装置側は「Write  
Cashe」が
少なからず（数100MB〜数十GB）搭載されています。した 
がって、サーバ
からの書き込まれたデータ（非連続ブロックアドレスの複数のデータの 
集団）
は、ストレージ装置のキャッシュ上に一時的に蓄えられます。完全な  
Write-
Through モードでストレージ装置が設定されていないのであれば、デフ 
ラグの
する、しない等、この世界では関係ないでしょう。

　そもそも、デフラグしないと性能的に問題が発生してしまうようなシ 
ステム
では、その基本設計に難があるか、運用状況や不可が、当初設計仕様を 
逸脱
してきたものとがんが得られますので、抜本的な対応を検討すべきです。

　四の五の言っても、現実的には限られたリソースで最適結果を求めら 
れる
のが現場です。ただし、湯沢さんのケースの場合、3ヶ月でおよそ 
6億件データ量を
取り扱う Windows Server ですから、それなりのハードウエアの 
筈ですので、
今回の場合は (1) Insert の時に Copy をなるべく使用で 
きるようにする。
(2) 事前に生データ（テキスト）をsort, cutコマンド等で整理 
統合する。
(3) Upaate を極力減らす、(4) autovacuum は一時停止、(5)  
Indexはデータを
投入後再作成などを工夫して、要件の時間内処理を終えるように考える 
事かと。



　でも、軽トラックで数百人規模のオフィスの引っ越しを一日で行な 
え！と
いわれたらどうしましょう？　

ーー個人的ですが
数千万レコードを有する単一テーブルは作成したくありません。
（たとえ、商用DBを使用したとしても）
テーブル・パーティショニングを検討されたらいかがでしょうか？


On 2006/12/02, at 10:42, Teraoka Yoshinori wrote:
>>
>> Reinin Oyama wrote:
>>> でも、Linux にもデフラグが、必要という誤った情報を流す 
>>> 人は
>>> そうかも、しれません。（昨今のLinuxはデフラグがないか 
>>> ら駄目とか？）
>>> まれに、ファイルシステムの整理が必要なことはありますが、
>>> Linux では、基本的にはデフラグをしないで、運用しますし、殆ど 
>>> 問題有りません。
>>> Windows では、基本的にデフラグを一定期間ごとに実行する運用で 
>>> す。
>>
>> 　PostgreSQLの本家MLでも以前、徐々に大きくなって 
>> きたDBが当初に比べて性能
>> が半分以下に落ちてきけど、DBクラスタ全体をコピーしなお 
>> したら劇的に改善し
>> た、という話題が流れていました。UNIX系OSでの話で 
>> す。参考までに。
>
> これは PostgreSQL の利点でもあり、欠点でもあるテーブルや 
> インデックスの
> ファイルがデータが増えるに連れて大きくなっていくためですね。
>
> DBを作るときにあらかじめこのテーブルには1GB、これは 
> 5GBとかでディスクが
> 確保できるようになれば同一テーブル内のデータがディスクのあちこ 
> ちに分散
> されることは防げそうです。
>
> RAIDなどでカバーできる範囲かもしれません。

--
Y.Shimada