かなり大きなデータベースを持つ新しいプロジェクトを開始しようとしています。
テーブルの数は多くなく(<15)、データの大半(99%)は1つの大きなテーブルに含まれ、ほとんど挿入/読み取り専用です(更新なし)。
その1つのテーブルの推定データ量は1日500.000レコードで増加し、さまざまなレポートを作成できるように少なくとも1年を維持する必要があります。 。
バックアップ/フェイルオーバーとして(読み取り専用)レプリケートデータベースが必要であり、ピーク時にレポートをオフロードする必要がある場合があります。
私はその大規模なデータベースを直接使用した経験がないので、この状況でどのDBが最良の選択であるかを尋ねています。 Oracleが安全な賭けであることは知っていますが、同様の設定でPostgresqlまたはMysqlの経験がある人はもっと興味があります。
私は1日あたり10万から2万の新しい行が見られる環境でPostgreSQLを使用しましたが、ほとんどの場合は1つのテーブルに追加されます。ただし、これらの行はサンプルに削減され、数日以内に削除される傾向があるため、1億行を超える行の長期的なパフォーマンスについて話すことはできません。
特に一括COPYを使用する場合、挿入のパフォーマンスは非常に合理的であることがわかりました。クエリのパフォーマンスは問題ありませんが、プランナーが行う選択は時々私を困惑させます。特にJOIN/EXISTSを行う場合。データベースをスムーズに実行し続けるには、かなり定期的なメンテナンス(VACUUM/ANALYZE)が必要です。 autovacuumやその他の設定をより慎重に最適化することで、この問題のいくつかを回避することができます。多くのDELETEを実行していない場合は、それほど問題にはなりません。全体的に、構成および保守が本来よりも難しいと感じる領域がいくつかあります。
私はOracleとMySQLを小さなデータセットにのみ使用したことがないため、パフォーマンスを比較することはできません。しかし、PostgreSQLは大規模なデータセットに対してworkで問題ありません。
「 The Data Warehouse Toolkit 」のコピーをお持ちですか?
提案は次のようにすることです。
ファクト(測定可能、数値)値を、それらのファクトを修飾または整理するディメンションから分離します。 1つの大きなテーブルは、実際には最良のアイデアではありません。これは、設計を支配するファクトテーブルに加えて、ファクトの「スライスとダイシング」を可能にする多数の小さなディメンションテーブルです。
SQLスタイルのレポートを作成するまで、単純なフラットファイルにファクトを保持します。データベースを作成してバックアップしないでください。ファイルを作成してバックアップします。 SQLから実行する必要があるレポートのデータベースのみをロードします。
可能な場合は、分析用の要約または追加のデータマートを作成します。場合によっては、すべてをデータベースにロードする必要があります。ファイルがテーブルの設計を反映している場合、すべてのデータベースには、ファイルからSQLテーブルを作成してインデックスを作成できるバルクローダーツールがあります。
Google BigTableに関する興味深い点がいくつかあります...
Bigtable Vs DBMS
一連のレポートを実行する必要があると述べたように、結合とSQLサポートなしを強調しました。この機能を使用できない場合、どこで使用するかによってレポートを実行できるかどうかはわかりません。
データの量(年間2億件のレコード)はそれほど大きくないため、標準のデータベースエンジンで使用できます。
ライブレポートが必要なければ、このケースはさらに簡単です。たとえば、他のサーバー上のデータをミラーリングして事前集計します。毎日のバッチ。 S.Lottが提案したように、データウェアハウジングについて読むこともできます。
Googleの BigTableデータベース と Hadoop は、大量のデータを処理できる2つのデータベースエンジンです。
Firebird を使用して、非常に大きなデータベース(現在30年以上データを保持しています)に使用し、非常にうまく拡張します。
最も良いのは、設定するプロパティがあることですが、Oracleとは異なり、インストールするので、使用する前に設定を開始しなくても非常にうまく機能します。