web-dev-qa-db-ja.com

パーティションまたは個別のデータベースを使用したテーブルのスケーリング？

1日あたり5,000,000 INSERT（おそらく同じ数のSELECTを使用）を経験する可能性のあるテーブル（BigTableと呼びましょう）があるとしましょう。挿入される各行は約50kbです。

これらの毎日のINSERTは、5つのクライアントに均等に分割されます（テーブルにはClientIDというFKがあります）。複数のクライアント間でデータを選択または結合する必要はありません。

このテーブルが大きくなるにつれてデータベースのパフォーマンスが心配になるので、3つの解決策を考え出しました。

解決策1：

  • BigTableをClientIDで分割します
  • 各パーティションをサーバー上の個別のハードディスクに保存します（Azureブログストレージを使用）。
  • 1か月前のすべてのデータ（アーカイブデータですが、クエリ可能である必要があります）を別のREADONLYパーティションのセットに分割します。

基本的に、これは、独自のストレージデバイス上の次のパーティションを意味します。

  • プライマリ（BigTableを除くすべてのデータ）
  • ClientAのBigTable（1日あたり5,000,000行/ 5クライアントx30日= 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の日数）,000,000）になります。これはまだ巨大なテーブルですが、奇妙なレポートを作成するためにのみ使用されます。

SQL Serverは、14 GB、8コアのAzureVMでホストされます。

---（解決策2：

もう1つのオプションは、クライアントごとに個別のデータベースをホストすることです。これは、それぞれに専用のSQLServerマシンがあることを意味します。アーカイブデータのパーティショニングは引き続き発生します。

このオプションは、データが物理的に分離されているため、最適ではありません。複数のデータベースへの更新を管理しなければならないことは、非常に問題になる可能性があります。クライアントごとに個別のデータベース接続を用意することも、開発者にとって考慮事項になります。

誰かがおそらくこれらのオプションについてアドバイスできますか？

解決策3：

より高速なデータベースプラットフォームにデータをアーカイブします。これについてはよくわかりませんが、NoSQLデータベースはSQLServerよりもはるかに優れた数十億のレコードを処理できるのではないでしょうか。

databaseperformancedatabase-designsql-serverazure
3
Dave New

オプション2を使用します。。

クライアントごとに専用のSQLServerマシンは必要ありません。また、専用のインスタンスも必要ありません。あなたがそう思っているかどうかはわかりません。

これの私の主な理由は、水平方向に（より多くのサーバーを）スケーリングしたいときが来たときに、これがそれを行うのに最適な位置に行くということです。

「複数のデータベースへの更新を管理することは非常に問題になる可能性がある」とあなたが考える理由がわかりません。さまざまなDb接続を処理するのは簡単ですが、私もこの懸念を理解していません。 "複数のクライアント間でデータをSELECTまたはJOINする必要がないため、これはすべて特に当てはまります。"

追記：必要に応じて、個々のクライアントDBを（日付などで）パーティション分割することもできます。

5
Morons