1

トップボリューム獲得者、トッププライス獲得者などのテクニカル分析に使用するデータベーススキーマを作成しています。ここでは 、設計の質問などの質問に対する回答を確認しました。そこでboe100の回答からヒントを得て、スキーマをほぼモデル化したので、次のようになります。 

Symbol -  char 6               //primary
Date -  date                   //primary 
Open -  decimal 18, 4
High -  decimal 18, 4
Low -  decimal 18, 4
Close -  decimal 18, 4
Volume -  int

現在、End Of Day（EOD）データを含むこのテーブルは、3年間で約300万行になります。後でさらにデータを取得/必要とする場合、2,000万行になる可能性があります。

フロントエンドは、「Y日間の日付Xで最高値を獲得した人を教えてください」などのリクエストを要求します。その要求はより単純なものの1つであり、そのため、時間的にはそれほどコストがかからないと思います。

しかし、「過去10日間でトップボリュームの獲得者を私に与え、過去100日間をベースラインとして機能させる」などのリクエストは、10〜100倍のコストがかかる可能性があります。このようなリクエストの結果は、ボリュームが何倍に成長したかなどを示すフロートになります。

私が持っている1つのオプションは、そのような結果ごとに列を追加することです。また、ユーザーが20日間で10日間のボリュームの増加を要求した場合、別の列が必要になります。特にMACD-10、MACD-100のような他の結果を列として追加し始めた場合、そのような列の合計は簡単に100を超える可能性があります。それぞれに独自の列が必要になります。

これは実行可能な解決策ですか？

もう1つのオプションは、結果をキャッシュされたhtmlファイルに保持し、ユーザーに提示することです。私はWeb開発の経験があまりないので、私にはそれは厄介に見えます。しかし、私は間違っている可能性があります（ofc！）。それもオプションですか？

ユーザーに応答を提示するためにmod_perlを使用している/使用する予定であることを付け加えておきます。mysqlデータベースでの作業の多くはperlを使用して行われています。応答時間は1〜2秒にしたいのですが。

4

1 に答える 1

2

データを可能な限り正規化して、RDBMSにその作業を任せる必要があります。正規化されたデータに基づいてクエリを効率的に実行します。

何が効率的かどうかを二度と推測しないでください。代わりに、RDBMSのクエリ説明者によって報告された特定の測定された非効率性に応じてのみ最適化してください。

最適化に有効なツールには、おおまかな優先順位が含まれます。

  • データをさらに正規化して、RDBMSがクエリに回答する最善の方法を自分で決定できるようにします。

  • 特定のクエリをリファクタリングして、クエリの説明者によって報告された非効率性を取り除きます。これにより、アプリケーションをより効率的にする方法、または上記のように関係をより適切に正規化する方法について、適切なフィードバックが得られます。

  • 実際には、非常に多くのトランザクションで使用されることが判明した属性にインデックスを作成します。これは非常に効果的ですが、インデックスが使用されるときに特定の読み取り操作の速度を上げるために、インデックスが維持されるため、ほとんどの書き込み操作の速度が低下するというトレードオフになります。

  • 将来のクエリで使用するために、事前に計算された中間結果を保持するための補足テーブルを作成します。これが良いアイデアになることはめったにありません。特に、DRYの原則に完全に違反しているためです。ここで、重複データ（元のデータと派生データ）の同期を維持する戦略を考え出す必要があります。重複データがない場合にRDBMSが最適に機能する場合です。

それらのどれも、一次データを格納するテーブルの内部をいじり回すことを含みません。

于 2010-03-21T01:16:47.930 に答える