1

私が作成しなければならない Web アプリケーション (以下に概説) に適したデータベースとレイアウトを選択するための助けが得られることを願っています。任意の方法で照会されます。

Web アプリでは、基本的に、レコードを構成する条件の任意の組み合わせを使用して多数のレコードのクエリを実行できます。日付は唯一の必須項目です。レコードは 8 つの項目 (以下) だけで構成されますが、1 日に約 300 万の新しいレコードが作成され、重複するレコードはほとんどありません。当日のデータはリアルタイムで常にデータベースに挿入されます。

最大の関心は、過去 6 か月から 1 年分のデータにあることはわかっていますが、残りは同じタイプのクエリで利用できる必要があります。

どのデータベースがこれに最も適しているか、またどのように構造化するかはわかりません。データベースは、かなり強力なサーバー上にあります。私は基本的に、優れたデータベース設計から始めて、クエリがどのように実行されるかを確認したいと考えています。次に、最適化を行うか、より強力なハードウェアを投入するかを判断できます。基本データベースの設計をやり直す必要はありません。時間があるが$$$ではない多くの最適化を行っている場合、最初は問題ありません。

オラクルなどではなく、オープンソースを使用する必要があります。現在、私はpostgresに傾いています。

レコードは次のもので構成されます。

1 日付
2 符号なし整数
3 符号なし整数
4 符号なし整数
5 符号なし整数
6 符号なし整数
7 テキスト 16 文字
8 テキスト 255 文字

年次スキーマ、月次テーブルを作成し、日付のレコード テーブルにインデックスを作成する予定です。

使用パターンを分析して最も人気のあるクエリが何であるかを確認した後、おそらくもう 1 つまたは 2 つのインデックスを追加できるでしょう。人気のあるクエリをキャッシュする限り、アプリサイトで多くのトリックを実行できますが、実際にはデータベース側で支援が必要です。フィールド 8 には重複する値がいくつかあるため、その列を結合するルックアップ テーブルの ID にする予定です。それを超えて、残りのフィールドはすべて1つの月次テーブルになると思います...

私はそれを毎週のテーブルに分割し、クエリにビューを使用することもできるので、アプリは複雑なクエリを組み立てようとすることに対処する必要がありません....

とにかく、フィードバックや支援に感謝します!

4

2 に答える 2

1

簡単なアドバイス...

  1. 1日300万件はすごい!(少なくとも私はそう思います。他の人はそれに目をつぶることさえしないかもしれません。) ダミー レコードを挿入するツールを作成して、Postgres のようなものが 1 か月分のデータでどのように機能するかを確認します。

  2. オープンソース + スケーラビリティを提供する NoSQL ソリューションを検討するのが最善かもしれません。まず、Couchbase と Mongo を見てください。リアルタイムのクエリ用に 1 か月分のデータをオンラインで保持している場合、Postgres が 9,000 万件のレコードをどのように処理するかはわかりません。素晴らしいかもしれませんが、そうではないかもしれません。

  3. 決定したシステムに「オフライン」データベースを配置することを検討してください。リアルタイムのものは最高のマシンに保存して準備ができていますが、古いデータをより安価な別のサーバーに移動します (読み取り: 低速)。このようにして、いつでもクエリに答えることができますが、一部のクエリは他のクエリよりも高速です。

于 2013-01-31T22:29:48.280 に答える
0

私の経験では、同様のレコード挿入頻度 (数十億行のテーブル) で主に Oracle を使用すると、データを慎重に分割し (この場合はおそらく日付で)、テーブルのインデックスを作成することで、優れた Web アプリ クエリ パフォーマンスを実現できます。データベース アーキテクチャにどの程度正確にアプローチするかは、多くの要因によって異なりますが、Web 上には、このようなことを支援するための優れたリソースがたくさんあります。

あなたのデータベースは比較的フラットなので、別のデータベース ソリューションの方がよいかもしれませんが、Oracle は常に私にとってうまく機能しています。

于 2013-01-31T22:50:21.907 に答える