1 日あたり 5,000,000 回の INSERTSBigTable
が発生する可能性のあるテーブル ( と呼びましょう) があるとします (おそらく同じ数の SELECT を使用)。挿入される各行は約 50kb です。
これらの毎日の INSERT は、5 つのクライアントに均等に分割されます (テーブルには と呼ばれる FK がありますClientID
)。複数のクライアント間でデータを選択または結合する必要はありません。
このテーブルが大きくなるにつれてデータベースのパフォーマンスが心配になるので、2 つの解決策を考え出しました。
解決策 1:
- パーティション
BigTable
分割ClientID
- サーバー上の個別のハード ディスクに各パーティションを格納します (Azure ブログ ストレージを使用)。
- 1 か月前のすべてのデータ (アーカイブ データですが、クエリ可能である必要があります) を別の READONLY パーティションのセットに分割します。
基本的に、これは独自のストレージ デバイス上の次のパーティションを意味します。
- プライマリ ( を除くすべてのデータ
BigTable
) - ClientA
BigTable
(1 日あたり 5,000,000 行 / 5 クライアント x 30 日 = 30,000,000 行) - ClientB
BigTable
(30,000,000 行) - ClientC
BigTable
(30,000,000 行) - ClientD
BigTable
(30,000,000 行) - ClientE
BigTable
(30,000,000 行) - ClientA の
BigTable
アーカイブ - ClientB の
BigTable
アーカイブ - ClientC の
BigTable
アーカイブ - ClientD の
BigTable
アーカイブ - ClientE の
BigTable
アーカイブ
アーカイブ テーブルの行数は、(5,000,000) x (DB の経過日数) - (30,000,000) になります。これはまだ巨大なテーブルですが、奇妙なレポートを作成するためにのみ使用されます。
SQL Server は、14 GB、8 コアの Azure VM でホストされます。
解決策 2:
もう 1 つのオプションは、クライアントごとに個別のデータベースをホストすることです。これは、それぞれが専用の SQL Server マシンを持つことを意味します。アーカイブ データのパーティショニングは引き続き行われます。
データが物理的に分離されているため、このオプションは最適ではありません。複数のデータベースの更新を管理しなければならないことは、非常に問題になる可能性があります。クライアントごとに個別のデータベース接続を使用することも、開発者にとって考慮事項になります。
誰かがこれらのオプションについてアドバイスできますか?