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