SQL Server でデータを分割するさまざまな方法を検討しています。私が検討しているアプローチの 1 つは、特定の巨大なテーブルを 8 つのパーティションに分割し、これらの各パーティション内で別のパーティション列に分割することです。これは SQL Server でも可能ですか、またはテーブルごとに 1 つのパーティション列 + 関数 + スキームを定義することに制限されていますか?
私はより一般的な答えに興味がありますが、この戦略は、DPV を使用して 8 台のマシンに膨大な量のデータを分散する最初のスキームでデータを分割し、次に分散パーティション ビューについて検討している戦略です。必要に応じて（たとえば）サブパーティションを削除できるように、各マシンパーティションで完全なテーブルのその部分を別のパーティションキーに配置します。
分割キーを計算できないというのは誤りです。キーに計算された永続化された列を使用します。
ALTER TABLE MYTABLE ADD PartitionID AS ISNULL(Column1 * Column2,0) persisted
私はいつもそれをしています、とてもシンプルです。
パーティション テーブルのセット全体の DPV は、これを達成するための唯一のクリーンなオプションです。tblSales2007、tblSales2008、tblSales2009 の間の DPV のようなものです。その後、それぞれの販売テーブルのそれぞれが再びパーティション分割されますが、別のキーによってパーティション分割される可能性があります。 . これを行うと、運用上の回復力の点で非常に優れた利点がいくつかあります (1 つのパーティション分割されたテーブルがオフラインになっても、DPV はダウンしません。他のタイムラインのクエリを満たすことができます)。
ハック オプションは、2 列の任意のハッシュを作成し、これをレコードごとに格納し、それによってパーティション化することです。パーティションキーは計算できないため、クエリ/挿入などごとにこのハッシュを生成する必要があります。これは格納された値でなければなりません。これはハックであり、得られるよりも多くのパフォーマンスが失われると思います。
特定の管理問題/データ量に対する DR について考える必要がありますが、データ ボリュームが非常に大きく、主に読み取りメカニズムでアクセスしている場合は、両方の数で非常にスケーリングする SQL 'Madison' を検討する必要があります。行数とデータ全体のサイズ。しかし、実際には 99.9% の読み取りタイプのデータ ウェアハウスにしか適しておらず、OLTP には適していません。
私は「数十億」のブラケットにある本番データセットを持っており、それらはパーティション化されたテーブルシステムに存在し、非常に優れたパフォーマンスを提供します-ただし、これの多くはデータベース自体ではなく、システムの基礎となるハードウェアに基づいています. このレベルまでスケールアップすることは問題ではありません。私は、これらの量をはるかに超えた他の人も知っています。
テーブルあたりの最大パーティション数は 1000 のままです。これについての会話を覚えているところによると、これは実行されたテストによって設定された数値であり、技術的な制限のために設定された数値ではありません。