履歴データおよび現在のデータを維持する際のパフォーマンスを得るにはどうすればよいですか？

Question

私は過去10年間の株式市場データを1つのテーブルで管理したいと考えています。特定の分析では、最後の1ヶ月データのデータのみが必要です。この短期分析を行うと、操作を完了するまでに時間がかかります。

これを解決するために、今年のデータだけを保持する別のテーブルを作成しました。私がこのテーブルから分析を実行すると、それは前のものより20倍速くなります。

今私の質問は：

1. は、この種の問題のために別のテーブルを持っているために、この正しい方法です。 （または、テーブルの代わりに別のデータベースを使用する）
2. 私は別のテーブルがある場合自動的にセカンダリテーブルを更新する方法はありますか？
3. または、マテリアライズドビューなどのものを使用して、パフォーマンスを得ることができます。

注：私はPostgreSQLデータベースを使用しています。

Answer 1

希望するtable partitioningこれにより、自動的に複数のテーブル間でデータが分割され、一般的に手作業よりもはるかにうまく機能します。

Answer 2

私はPostgreSQLについてはわかりませんが、正しいトラックにいることを確認できます。大量のデータを処理して複数のテーブルにデータを分割し、ある種のクエリジェネレータを使用してクエリを作成することは、絶対に正しい方法です。このアプローチは、データウェアハウス、特にお客様のケースの株式市場データにおいて十分に確立されています。

ただし、履歴データを更新する必要があるのはなぜですか？株式分割を扱う場合は、生の履歴データと一緒に使用される個別の乗数表を使用して正確な価格/シェアを実現することが一般的です。

Answer 3

1. 歴史的な記録のために別のテーブルを使用することは完全に賢明です。それはクロスデータベースは
2. 自動更新を照会書くことではない簡単だように、それは、別のデータベースとはるかに問題だ - それはcronジョブのためのツールだ
3. あなたは、このようなもののために部分インデックスを使用することができます - 彼らは素晴らしい仕事をし

Answer 4

私はまったく同じ問題の近くで取り組んでいます。
ここではテーブル分割が確実に行えます。私は1年以上に分けていますが、それはより大きな程度のコントロールを与えるでしょう。パーティションを設定してから、数か月（または他の日付）に制限してください。あなたのpostgresql.confでは、本当に利益を得るためにconstraint_exclusion = onにする必要があります。ここでの追加的な利点は、実際に情報を取得したいと思う正確なテーブルのみをインデックス化できることです。大量のデータをこのテーブルにバッチインポートすると、ルールとトリガーの結果が若干改善され、パーティショニングではルールを維持しやすくなります。しかし、より小さいトランザクションの場合、トリガーははるかに高速です。 postgresqlのマニュアルには、継承による分割に関する素晴らしいセクションがあります。

Answer 5

率直に言えば、実行計画を確認して、より根本的な措置を取る前にクエリやインデックスを修正してください。

インデックス作成は非常にコストがかかりません（挿入を頻繁に行わない限り）、既存のコードは修正することなく（インデックスを適切に作成すると）速くなります。

その他の対策は、それ以降に行われます。