sql - SQL Serverで大きなテーブルをパーティション分割するための最良の方法は何ですか？

Question

最近のプロジェクトでは、「リード」開発者は、「より大きな」テーブルが2つの別々のデータベースに分割され、2つの別々のデータベーステーブルを結合するメインデータベースを表示するデータベーススキーマを設計しました。メインデータベースは、アプリケーションが駆動されたものであるため、これらのテーブルは通常のテーブルのように見え、感じられました（更新に関するいくつかの奇妙なことを除いて）。これは大きなパフォーマンスの問題のように見えました。これらのテーブルの周りのパフォーマンスに問題はありますが、彼のデザインについての考えを変えるものは何もありません。これを行うための最良の方法は何か、またはそれを行う価値があるかどうか疑問に思っていますか？

Answer 1

単一のサーバー内の複数のデータベースにまたがってテーブルを分割しても、実際に何かが得られるとは思いません。基本的に行ったことは、単一の SQL Server インスタンスの下に複数のインスタンス (つまり、2 つの異なる DB で開く) を配置することで、最初に「テーブル」を操作する際のオーバーヘッドを増やしたことです。

どのくらいのデータセットがありますか? SQL Server に 2 年分の売上データを含む 600 万行のテーブルを持つクライアントがあります。彼らは、目立った速度の問題なしに、トランザクションやレポートに使用しています。

もちろん、インデックスを調整し、正しいクラスター化インデックスを選択することは、パフォーマンスにとって非常に重要です。

データセットが非常に大きく、パーティショニングを検討している場合は、物理サーバー間でテーブルをパーティショニングすることで、より多くの利益を得ることができます。

Answer 2

多くの微妙なパフォーマンスへの影響がある可能性があるため、パーティショニングは簡単に実行できるものではありません。

私の最初の質問は、大きなテーブル オブジェクトを別々のファイル グループ (別々のスピンドル上) に配置することについて単純に言及しているのか、それともテーブル オブジェクト内のデータ パーティション分割について言及しているのかということです。

説明されている状況は、特定の大きなテーブルの物理ストレージを、残りのテーブルとは異なるスピンドルに配置しようとする試みであると思われます。この場合、別のデータベースの余分なオーバーヘッドが追加され、データベース間で参照整合性を適用する機能が失われ、データベース間の所有権チェーンを有効にすることによるセキュリティへの影響は、1 つのデータベース内で複数のファイル グループを使用する場合に比べて何のメリットもありません。可能性として、質問で言及している個別のデータベースが個別のスピンドルに保存されておらず、すべて同じスピンドルに保存されている場合、ディスク アクティビティとまったく恩恵を受けていません。

追加のデータベースを使用して大きなテーブルを保持する代わりに、SQL Server Books Online のファイル グループのトピックを調べるか、簡単なレビューとして次の記事を参照することをお勧めします。

データのパーティショニング (複数のファイル グループへのパーティショニングを含む) に関心がある場合は、Kimberly Tripp の記事を読むことをお勧めします。Kimberly Tripp は、SQL Server 2005 が発表されたときに、そこで利用可能な改善について優れたプレゼンテーションを行いました。開始するのに適した場所は、このホワイトペーパーです

Answer 3

どのバージョンの SQL Server を使用していますか? SQL Server 2005 にはパーティション分割されたテーブルがありますが、2000 (または 7.0) ではパーティション ビューを使用する必要がありました。

また、テーブル パーティションを別のデータベースに配置する理由は何でしたか?

過去 (2005 年より前) にテーブルをパーティション分割する必要があったときは、通常、さまざまなパーティションを表示して、日付列または同様のものを使用していました。Books Online には、これを行う方法とその周りのすべての規則について説明するセクションがあります。本来の動作をさせるには、ルールに従う必要があります。

覚えておくべき重要なことは、パーティショニング列は主キーの一部である必要があり、オプティマイザーがクエリの影響を受けないパーティションを無視できるように、テーブルに対するすべてのアクセスで常にその列を使用するようにすることです。

MSDN で「パーティション テーブル」を検索すると、SQL Server 2005 パーティション テーブルのより完全なチュートリアルと、パフォーマンスを最大化するための設定方法に関するアドバイスを見つけることができるはずです。

Answer 4

テーブルのパーティション分割には明確な利点があります (同じまたは異なるファイル グループ/ディスク上にあるかどうかに関係なく)。パーティション列が正しく選択されている場合は、クエリが必要なパーティションのみにヒットすることがわかります。たとえば、1 億件のレコード (私はそれよりもはるかに大きなテーブルをパーティション分割しました - 約 200 億行以上) があり、ほとんどの場合、データ アクセスの 70% 以上が特定のカテゴリ、タイムライン、またはタイプのみである場合を想像してください。アクセス頻度の高いデータを別のパーティションに保持するのに役立ちます。さらに、パーティションをさまざまなタイプのディスク (SATA、ファイバー チャネル、SSD) を持つ個別のファイル グループに合わせて、最もアクセス数が多い/使用頻度の高いデータを最速のストレージに配置し、最もアクセス頻度の低い/ほとんどアクセスしないデータを仮想的に低速のディスクに配置することができます。

ただし、SQL Server では、Oracle とは異なり、パーティショニング機能が制限されています。パーティショニングに選択できる列は 1 つだけです (SQL 2008 でも)。そのため、頻繁に使用するほとんどのクエリの一部でもある列を賢く選択する必要があります。ほとんどの場合、日付列によるパーティション分割を簡単に選択できます。ただし、そのように分割することは論理的に思えますが、クエリが条件の一部としてその列を持たない場合、分割から十分な利点を得ることはできません (つまり、クエリは関係なくすべてのパーティションにヒットします)。

ほとんどの DW データベース クエリは期間によって制限されるため、OLTP よりもデータ ウェアハウス/データ マイニング タイプのデータベースのパーティション分割がはるかに簡単です。

そのため、最近ではデータベースで処理されるデータの量が多いため、クエリが時間や地理的な場所などのより広いグループによって制限されるようにアプリケーションを設計することが賢明です。分割すると、最大のメリットが得られます。

Answer 5

データベース設計に関するベスト プラクティスについて質問していますか、それともリーダーに考えを変えるよう説得していますか? :)

設計に関して... 古き良き時代に戻ると、データベースエンジンの制限を回避するために、垂直分割が必要になることがありました。テーブル内の列の数は、255 列などの厳しい制限でした。最近の主な利点は純粋にパフォーマンスのためです。めったに使用されない列または BLOB を別のディスク アレイに配置します。ただし、両方のテーブルから定期的に何かを取得している場合は、損失になる可能性があります。あなたのリードは時期尚早の最適化のケースに苦しんでいるようです.

あなたのリードが間違っていることを伝えるという点では...それには外交が必要です. 彼がパフォーマンスに関して不満のつぶやきに気づいている場合、ベンチマークはおそらく違いを示す最良の方法です.

「create table t1 as select * from view1」を使用してどこかに新しい物理テーブルを作成し、垂直分割されたテーブルと新しいテーブルで長いバッチを実行します。あなたが言うほど悪い場合、違いは明らかなはずです。

しかし、これも時期尚早の最適化かもしれません。エンドユーザーがパフォーマンスについてどう思うかを調べてください。パフォーマンスが十分に良好である場合、何らかの定義で良好である場合は、壊れていないものを修正しないでください。

Answer 6

パーティショニングによって何も得られないという仮定には同意しません。

パーティション データが物理的および論理的に配置されている場合、クエリの潜在的な IO は大幅に削減されます。

たとえば、INT を表す INT としてバッチ フィールドを持つテーブルがあります。

このフィールドでデータを分割し、特定のバッチのクエリを再実行すると、分割の前後に set statistics io ON を実行して、IO の削減を確認できるはずです。

パーティションごとに 100 万行あり、各パーティションが個別のデバイスに書き込まれるとします。クエリは、不要なパーティションを排除できる必要があります。

私は SQL Server で多くのパーティショニングを行ったことはありませんが、Sybase ASE でパーティショニングを行った経験はあります。これはパーティション エリミネーションとして知られています。時間があれば、SQL Server 2005 マシンでシナリオをテストする予定です。