テーブルごとに1億以上のエントリを持つ多くのテーブルを持つ巨大なPostgreSQL 9.3データベースを作成します。このデータベースは、基本的に読み取り専用（必要なテーブルをすべて埋めて、DBでインデックスを作成しない場合）、シングルユーザーアクセス（ローカルホストから複数のクエリを実行およびベンチマーク）されるため、DBが使用されます研究目的のみ。クエリは常に整数DBフィールドでJOINを使用します。
この目的のために、おそらくSSD（256-512GB）を購入するでしょう。DBにSSDを使用したことがないので、心配する必要はありますか？DB全体をSSDに置くことも、インデックスだけを置くこともできますか？SSD用にPostgreSQLをチューニングするために必要な特別なアドバイスやチュートリアルはありますか？i7と32GbのRAMを備えた優れたワークステーションがあることに注意してください。
回答:
それで私が恐れるべきことはありますか？
バックアップがありません。他のストレージデバイスと同様に、死ぬ可能性があります。バックアップを保持します。
データのロードに時間がかかる場合は、データのロードが完了したら、停止してコピーすることにより、読み取り専用のデータベースをバックアップします。そうすれば、何かがうまくいかなかった場合、後で再作成しやすくなります。
DB全体をSSDに置くことも、インデックスだけを置くこともできますか？
適合する場合は、DB全体を保存します。
そうでない場合は、SSDにテーブルスペースを配置し、それを使用して、インデックスと、頻繁にクエリされるテーブルをできるだけ多く格納します。
SSD用にPostgreSQLをチューニングするために必要な特別なアドバイスやチュートリアルはありますか？
SSDの利点のほとんどは、OLTP書き込みロードにあります。読み取り専用ロードの主な利点は高速シークであり、slardiereはそれをカバーしています。
effective_io_concurrency = 5SSDが高速で大量にパイプライン化されたランダムリードを実行できるという事実を反映するような設定をしたいかもしれませんが、それはビットマップインデックススキャンにのみ影響し、実際にはrandom_page_cost既にそれを組み込んでいます。
読み取り専用ロードの場合、大きな違いはありません。
初期データのロードについては、以下を参照してください。
i7と32GbのRAMを備えた優れたワークステーションがあることに注意してください。
maintenance_work_memデータの負荷を大きく設定します。少なくとも使用し8GBます。
work_memクエリ作業のために大きな値を設定します。適切なサイズは、クエリの複雑さに少し依存します。で開始し500MB、そこから上に移動します。
checkpoint_segments最初のデータロードのために（大規模に）バンプアップします。
VMのオーバーコミットを無効にすることを忘れないでください！（PostgreSQLのマニュアルをご覧ください：http : //www.postgresql.org/docs/current/static/kernel-resources.html）