トップ回答者
テラバイト級のDBを作成する際のファイルサイズ

質問
回答
-
自分もここまで大きなDBを扱ったことが無いので、マニュアル的な回答になりますが。
> 1.5TB~2TB級のDBを作成構築する事になったのですが、
> 一般的に1データファイルのサイズはどのぐらいにしていますか?
> 経験談でも良いので教えていただければと思います。
「1データファイルのサイズ」というのが良くわかりませんが、データファイルやログファイルが拡張されると
パフォーマンスに影響が出るため、あらかじめレコードサイズやデータ量から考えて、
出来るだけ拡張されないサイズを設定してください。
(ごめんなさい、必要な要件が書かれていないので、これぐらいしか書けません)
その他、テラバイト級のデータベースを扱う場合、ハードウェアの構成から考える必要があると思います。
基本的には、「データファイルとトランザクションログファイルが格納されるボリュームを分ける」、
「RAID 5では遅いのでRAID 0+1で構成する」辺りでしょうか。
また、RAID 0+1のボリュームを複数あるとなお良いです。
(余談ですが、SQL Serverのブロックサイズは8KBなので、HDDをNTFSでフォーマットする際に、
ブロックサイズを8KBで指定すると効率が良くなります)
SQL Serverの設定で言えば、主に読み取りがメインとなるテーブル(例えばマスターテーブル等)と
読み書きが頻繁に起こるテーブル(トランザクションデータ等)のファイルグループを分け、出来れば
各々を別ボリュームに保存します。
あとはデータが増えてくるとインデックスが肥大化して検索に時間が掛かるため、特定のテーブルを
パーティション化も考えた方がよさそうです。
-
以前、同様の調査をした際のメモを提示します。本当は情報源を明らかに出来たらいいのですが、個人wikiに内容のみメモったまま放置していたため引用元がわからなくなってしまいました。。。
Typically over 1 TB since the time to restore the whole database means significant downtime.
Solutions using multiple filegroups where the main application functionality resides in small No.# of filegroups.
How many data files/file groups?
Start with 1 data file per CPU Core
How many log files
No need to have multiple Log Files, except for space reasons
Start with relative large Log File
Use % based growth for small files, fixed amount for larger files
Data files should be of equal size
Pre-size data/log files – do no rely on AUTOGROW
Exception: Testing to determine how much space will be neededあちこちのメモのつぎはぎみたいで・・・・・。
主にバックアップ面から考えた大規模DBの注意点です。パフォーマンス面では、また別の考え方があると思います。
以前は調査をし始めて、すぐ別PJにアサインされたため放置してしまい結論はでていません。
後は、バックアップから考えた可用性については次のドキュメントが参考になるかと思います。
http://www.microsoft.com/japan/technet/prodtechnol/sql/bestpractice/pdbavail.mspx
-
すべての返信
-
自分もここまで大きなDBを扱ったことが無いので、マニュアル的な回答になりますが。
> 1.5TB~2TB級のDBを作成構築する事になったのですが、
> 一般的に1データファイルのサイズはどのぐらいにしていますか?
> 経験談でも良いので教えていただければと思います。
「1データファイルのサイズ」というのが良くわかりませんが、データファイルやログファイルが拡張されると
パフォーマンスに影響が出るため、あらかじめレコードサイズやデータ量から考えて、
出来るだけ拡張されないサイズを設定してください。
(ごめんなさい、必要な要件が書かれていないので、これぐらいしか書けません)
その他、テラバイト級のデータベースを扱う場合、ハードウェアの構成から考える必要があると思います。
基本的には、「データファイルとトランザクションログファイルが格納されるボリュームを分ける」、
「RAID 5では遅いのでRAID 0+1で構成する」辺りでしょうか。
また、RAID 0+1のボリュームを複数あるとなお良いです。
(余談ですが、SQL Serverのブロックサイズは8KBなので、HDDをNTFSでフォーマットする際に、
ブロックサイズを8KBで指定すると効率が良くなります)
SQL Serverの設定で言えば、主に読み取りがメインとなるテーブル(例えばマスターテーブル等)と
読み書きが頻繁に起こるテーブル(トランザクションデータ等)のファイルグループを分け、出来れば
各々を別ボリュームに保存します。
あとはデータが増えてくるとインデックスが肥大化して検索に時間が掛かるため、特定のテーブルを
パーティション化も考えた方がよさそうです。
-
以前、同様の調査をした際のメモを提示します。本当は情報源を明らかに出来たらいいのですが、個人wikiに内容のみメモったまま放置していたため引用元がわからなくなってしまいました。。。
Typically over 1 TB since the time to restore the whole database means significant downtime.
Solutions using multiple filegroups where the main application functionality resides in small No.# of filegroups.
How many data files/file groups?
Start with 1 data file per CPU Core
How many log files
No need to have multiple Log Files, except for space reasons
Start with relative large Log File
Use % based growth for small files, fixed amount for larger files
Data files should be of equal size
Pre-size data/log files – do no rely on AUTOGROW
Exception: Testing to determine how much space will be neededあちこちのメモのつぎはぎみたいで・・・・・。
主にバックアップ面から考えた大規模DBの注意点です。パフォーマンス面では、また別の考え方があると思います。
以前は調査をし始めて、すぐ別PJにアサインされたため放置してしまい結論はでていません。
後は、バックアップから考えた可用性については次のドキュメントが参考になるかと思います。
http://www.microsoft.com/japan/technet/prodtechnol/sql/bestpractice/pdbavail.mspx
-