web-dev-qa-db-ja.com

テーブルのパーティション分割によりパフォーマンスは向上しますか？その価値はありますか？

私は、既存のSQL Server DBを使用するデータ移行プロセスとWebインターフェイスを開発する必要があるプロジェクトに参加しました。このDBは数年前に別の人が開発したもので、約100 GBのデータがあり、10分ごとに増加しています（デバイスごとに1日あたり144件のレコードから>> 144件のレコードを保存しています）。いくつかのテーブルには約10ミリオンの行があります。重要なのは、メインテーブルは、通常実行される種類のクエリに対して、最も効率的または適切ではない方法で設計されていることです。ここで、私が言うことがすでに実装されているものよりも優れているかどうかを証明する必要があります。 DBには多数のテーブルがありますが、構造は次の図で簡略化できます。 enter image description here

Date_Idフィールドは、DateTimeフィールドを使用する関数によって自動的に生成されます。両方のテーブルに2つのインデックスがあります。各テーブルのクラスターインデックスには、同じ順序でPKフィールドが含まれています。 Unitテーブルの2番目のインデックスにはUnit_Idフィールドのみが含まれ、UnitDataの2番目のインデックスにはUnit_IdフィールドとDateTimeフィールドがこの順序で含まれています。

ただし、デザインは次のようにする必要があります。 enter image description here

この場合、PKフィールドのクラスター化インデックスのみが必要になります。このDB設計では、通常のクエリは次のようになります。

SELECT ud.*
FROM Unit u, UnitData ud
WHERE u.Unit_Id = ud.Unit_Id and ud.DateTime >= 'dd-MM-yyyy'
ORDER BY ud.Unit_Id, ud.DateTime

さて、私が本当に理解していないことがあります。Date_Id列がある唯一の理由は、このテーブルのパーティション列としてそれを使用することだと言われました。このテーブルをパーティション分割することの真の必要性について尋ねましたが、「毎日または毎月のデータが必要なときにクエリをより効率的に実行する」ことが課題でした。これまでは、パーティショニングについてあまり知らなかったので、次のリンクを確認しました。

http://msdn.Microsoft.com/en-us/library/ms190787.aspx

テーブルパーティション分割はどのように役立ちますか？

パーティショニングによりパフォーマンスを向上

理想的なクエリがデバイスと日時でフィルタリングされることを考えると、質問は次のとおりです。

  1. 最初のDB設計（パーティション化あり）の最も効率的で理想的なクエリは何だと思いますか？
  2. 最初のDB設計に対する最も効率的なクエリは、2番目のクエリ（上で書いたもの）よりも優れていると本当に思いますか？
  3. 前の項目が肯定的だった場合、2つの追加フィールド（IdおよびDate-Id）と追加のインデックスがあれば、改善は十分価値があると本当に思いますか？

どうもありがとうございました！！

sql-serverperformancepartitioningquery-performance
5
Hauri

パーティション分割を使用しても、特定のクエリを処理するようにパーティション分割スキームが構築されている場合にのみ、クエリのパフォーマンスが向上します。

最善のアプローチを特定するには、クエリパターンを確認し、テーブルへのアクセス方法を確認する必要があります。これは、単一の列（パーティション化キー）でのみパーティションを作成できるためで、これが パーティションの削除 に使用されます。

パーティションの除去が発生するかどうか、およびパーティションの除去がどの程度うまく機能するかに影響を与える2つの要因があります。

  1. パーティションキー-パーティション化は単一の列とクエリでのみ発生できますmustその列を含めます。たとえば、テーブルが日付に分割されていて、クエリがその日付列を使用している場合、パーティションの削除が発生します。ただし、クエリ述語にパーティションキーを含めないと、エンジンは消去を実行できません。
  2. 粒度-パーティションが大きすぎる場合でも、必要以上のデータをプルバックするため、削除によるメリットはありません。ただし、小さくすると管理が難しくなります。

多くの点で、パーティション化は他のインデックスを使用する場合と同じですが、いくつかの利点があります。ただし、信じられないほど大きなテーブルを扱っていない限り、これらの利点を理解することはできません。個人的には、テーブルのサイズが250 GBを超えるまで、パーティションの作成も考慮しません。ほとんどの場合、適切に定義されたインデックスは、それよりも小さいテーブルの多くのユースケースをカバーします。説明に基づいて、データの大幅な増加は見られないため、適切にインデックス付けされたテーブルがテーブルに対して適切に機能する可能性があります。

問題を解決するためにパーティション分割が実際に必要かどうかを確認することを強くお勧めします。通常、次の目的で非常に大きなテーブルを分割します。

  • さまざまな種類のディスク間でデータを分散することで、より「アクティブな」データをより高速でより高価なストレージに配置し、より少ないアクティブなデータをより安価で低速のストレージに配置できます。これは主にコスト削減策です。
  • 非常に大きなテーブルのインデックスメンテナンスを支援します。パーティションを個別に再構築できるため、これは最小限の影響でインデックスを適切に維持するのに役立ちます。
  • パーティション化を活用してアーカイブプロセスを改善します。 スライディングウィンドウ を参照してください。
10
Mike Fal

テーブルのパーティション分割mayは、パーティションの動作の制限内で作業できる場合にパフォーマンスを向上させます。次の説明を参照してください。

http://technet.Microsoft.com/en-us/library/ms177411（v = sql.105）.aspx

ただし、パーティションが正しく設定されておらず、クエリが単一のパーティション内にとどまることができない場合、パーティションを設定するとサーバーの動作が遅くなる可能性もあります。ゲイル・ショーはこれについての記事を書いています：

https://www.simple-talk.com/sql/database-administration/gail-shaws-sql-server-howlers/

「パーティショニングはクエリのパフォーマンスを向上させることができますが、保証はありません。」また、「要約すると、パーティション分割は主に、メンテナンスの改善、高速ロード、高速削除、およびテーブルを複数のファイルグループに分散する機能のためのものです。主にクエリのパフォーマンスのためではありません。」

2
RLF

これをパーティション分割でお読みください- SSD上のSQL Server-テーブルパーティション 。 ＃2に関しては、この方法で設計するとテーブルが断片化されます。列の場所を入れ替える必要があります。 DateTimeを最初の列にすると、毎日、Unit_Idごとにスペースを見つける代わりに、新しい行が下部に追加されます。次に、クエリ用のノンインデックスインデックスを作成できます。

0
DenisT