2

過去の株価データをSQLAzureデータベースのテーブルに保存したいと思います。私は15分ごとに約100000の株価を取得し、それらのいくつかは値を変更する場合と変更しない場合があります。したがって、毎日約（5000 * 32（8時間* 4回）= 160000）160000レコードを保存する必要があります。

現在、エクイティテーブルは約20列の次の構造になっています。

Equity table
---------------
ID INT PK,
Name Varchar(20),
Value Money,
Currency Varchar(10),
.......

過去の価格を保存したい新しいテーブル（HistoricalPrices）には、次の構造が含まれています。

HistoricalPrices
-------------------
ID INT PK,
EquityID INT FK,
[Date] DateTime,
Value Money

これらの160000レコードを毎日保存すると、1か月でテーブルに約500万レコードが記録されます。

私の質問は、このテーブルがデータをどのように処理するのか、これでパフォーマンスの問題が発生するのか、このデータを維持する他の方法があるのか​​、テーブル構造などに変更を加える必要があるのか​​ということです。

4

2 に答える 2

2

適切なインデックス作成とクラスタリングがあれば、適切で選択的なクエリでパフォーマンスが問題になることはありません。バックアップ、ジョブのインデックスの再作成、返されるデータの量の制限などの従来の運用上の問題は、Azureの問題ではありませんが、考慮する必要があります。

Azure DBのサイズ制限により、ある時点で水平方向にパーティション化（シャード）する必要があることに注意してください（http://blogs.msdn.com/b/sqlazure/archive/2010/06/24/10029719.aspx）（Azureはt TABLEパーティショニングをサポートします。）

http://msdn.microsoft.com/en-us/library/ms345146(v=sql.90).aspx

また、32ビットint PKのオーバーフローも考慮する必要があります。現在のレートでは50年以上の価値がありますが、より高い頻度（たとえば、より多くの取引所またはより多くの株式）で追跡する場合は、64ビットINTを考慮する必要があります。

于 2012-06-17T18:26:08.237 に答える
0

ボリューム要件があるため、フェデレーション（http://msdn.microsoft.com/en-us/library/windowsazure/hh597452.aspx）の使用を検討する必要があります。レコードが単一のバッチで挿入/更新される場合は、それらを特定の値の範囲に分割する必要がある場合があります。ただし、一般的に言えば、フェデレーションはSQLAzureの推奨されるシャーディングメカニズムです。ストレージ設計を完成させる前に、その機能を確認してください。

興味がある場合は、フェデレーションの設計に関連する特定の情報についてブログを確認してください：http: //geekswithblogs.net/hroggero/archive/2011/07/23/preparing-for-data-federation-in-sql-azure.aspx

于 2012-06-18T14:59:35.417 に答える