大量の気象モデルデータをPostgreSQLデータベースに入れています。マシンには8つのコアと16 GBのRAMが搭載されています。PostGIS 2.1でPostgreSQL 9.3を実行しています。各テーブルには、さまざまな気象データ（気温、露点、風など）があります。各テーブルには6〜7列があります。緯度、経度、ポイントジオメトリ、標高、モデルが関連する日時、および対象となる1〜2のデータ値です。データは主に、時間と高度によって境界ボックスを照会されます。テーブルあたり約145,757,360行になります（現在より古いデータはもはや関係がなくなり、削除されます）。テーブルのサイズは、おおよそ、インデックスなしで約10 GBと推定されます。（これは、52バイトのデータと1行あたり23バイトのオーバーヘッドです）。新しいモデルデータが利用可能になると、データは定期的に更新/挿入されます。注意：
だから私はこれらの2つの計画を見ています：
- ポイントジオメトリの追加のインデックスを使用して、（日時、標高）でインデックスを付けてクラスタ化するだけです。古い行を削除し、vacuum / analyzeを実行し、再クラスター化する通常のcronジョブを実行します。
- 日時でパーティション化し、ジオメトリのインデックスを持つテーブルごとに標高でクラスタ化してインデックス化します。通常のcronジョブを実行して、新しいテーブルを追加し、古いテーブルを削除します。
さらに、
- したがって、テーブルを削除する方がはるかに効率的で、削除およびバキューム処理を行うことを知っています。しかし、それ以外の場合はパフォーマンスが向上しますか？
- パーティションは、すべてのテーブルが均等に更新されて削除されるまで適切ではない場合に適切ですか（ドキュメントでは、一部のテーブルのみを選択した場合にパーティションが最適に機能することが示されています）？
データを配信する場合、選択はクラスター化インデックスよりも高速になりますか？複数のリクエストが一度に行われる場合、答えは変わりますか？
ありがとうございました。必要なデータをすべて入れてほしい。知らない場合はお知らせください。追加します。
「緯度、経度、ポイントジオメトリ、標高」という繰り返しの組み合わせです。はいの場合、それを別のテーブルに正規化すると、スペースの一部を節約できる場合があります。
—
AK
ほんのわずか。PostGISジオメトリはバイナリ配列であり、人間が読める形式ではありません。これらの値を出力で導き出すことはできましたが、それらをクラスター化できませんでした。クラスター化にGeoHashを使用することもできますが、これは緯度経度よりも読みやすくありません。しかし、どちらの方法でもスペースは問題ではありません。彼らは私が埋めることができる限り多くのテラバイトを提供しました。問題は、テラバイトを高速でクエリできないことです。データベース自体は主に非トランザクションになります。2つのスクリプトのみが書き込みアクセスを持ちます。それ以外はすべて厳密に読み取り専用です。
—
bshender 2014年
クレイグ：彼らは興味をそそられるように見えます。9.3でのセットアップについて何か考えはありますか？
—
bshender 2014年
次の2つの情報を提供していただけませんか。1）挿入速度またはクエリ速度で最も重要なことは何ですか。2）最も一般的なクエリは何ですか？
—
Thomas Kejser 2014年
xminたりxmax、負けたりできるわけではありません。これを9.4にする可能性のある機能は、おそらくあなたを興奮させるでしょう。これは、minmaxインデックスと呼ばれ、このようなことを非常に便利にします。