web-dev-qa-db-ja.com

MS SQL Server 2016-単一パーティションテーブルと複数分離テーブル

MS SQL Server 2016データベースに1〜1.5年間多くのログを保存する必要があります。収益：1か月あたり50 Gbのログ（1か月あたり約5,000万行）。すべてのデータを6か月で保存し、このデータの50％を古いレコードに縮小します。前提条件：

  • 過去1か月目、2か月目などには異なるインデックスが必要です。
  • 2か月以上経過した大きなXML /テキストデータに必要なデータ圧縮。
  • 現時点では、6か月以上経過したデータに必要なデータは縮小されます（ビッグデータ（XML /テキスト）を含むレコードを50〜60％削除するだけです）。ただし、行を強く圧縮し、削除しない方がよいでしょう。

主な使用例：SQL INの方法で（場合によってはLIKEで）、IDや文字列フィルターによって100〜200（時には1000）行を検索します。

パーティションには2つの方法があります。

  • 「古いスタイル」-例として月ごとに分割されたテーブル（この場合、共通のビューがないと思います）、月（Log_0117、Log_0217、...）。
    • 長所：完全に独立した管理とスキーマ（進化）、独立したインデックス、およびクエリ/プランのキャッシュ（予想どおり）-パフォーマンスと効率が向上し、実装が簡単で、魔法が少なく、制御しやすい。
    • 短所：多くのテーブル（期間ごとに8つ）、複雑なクエリ（特に期間間のクエリ）。
  • "モダンスタイル"- パーティション分割されたテーブルとインデックス 。
    • 長所：簡単な管理、全期間で1つのテーブル、理論的にはより単純なクエリ。
    • 短所（一部の記事で確認）：パーティションインデックスの強力な要件（通常、すべてのインデックスにはパーティション列が含まれている必要があるため（より多くのメモリが必要））、このようなインデックスはパーティションの切り替え後に再構築が必要で、期間ごとにスキーマ/インデックスを変更することは難しい、より魔法がかかり、制御しにくくなります。

コミュニティに対する私の質問：

  • それは本当に組み込みのパーティション化されたテーブル/インデックスが開発をより簡単にしますか？
  • 現在、MS SQL Server 2016には本当に不便な制限がありますか（エンタープライズとして、またはそれほど悪くないものですか）。

UPD1： Columnstore Indexes -@DavidBrowneからの別の興味深いオプションですが、MSDNで説明されています。

列ストアインデックスは、フルテーブルスキャンを使用するクエリのパフォーマンスを向上させます。データをシークして特定の値を検索するクエリには適していません。

残念ながら、ほとんどの場合、複雑な統計を計算するのではなく、ログで100〜200レコードを検索しますが、将来のために覚えておきます。

UPD2：@DanGuzman、私はいくつかの要件について言われたときにAlignedインデックスを意味しました https://technet.Microsoft.com/en-us/library/ms187526（v = sql.105）.aspx ：

非クラスター化インデックスのパーティション化

一意の非クラスター化インデックスをパーティション化する場合、インデックスキーにはパーティション化列が含まれている必要があります。 SQL Serverは、一意でなく、クラスター化されていないインデックスをパーティション化する場合、デフォルトでパーティション化列をインデックスの非キー（含まれている）列として追加して、インデックスがベーステーブルと揃うようにします。 SQL Serverは、パーティション化列が既にインデックスに存在する場合、それをインデックスに追加しません。

また、非アライメントインデックスを使用しないことを強くお勧めします1） 大きなテーブルのパーティション分割-インデックス 、2） パーティションアライメントされたインデックスのパフォーマンスへの影響 。

つまり、先月だけクエリを高速化したい場合は、1）このインデックスですべてのテーブルをカバーする必要があります（ただし、実際にはより多くのディスク/メモリが必要です）、または2）パーティションの切り替えとインデックスの再構築のために長いメンテナンスウィンドウを編成します。 。

sql-serverperformancepartitioningsql-server-2016compression
2
Nikita Danilov

それは本当に組み込みのパーティション化されたテーブル/インデックスが開発をより簡単にしますか？

ビューの抽象化を持たない独立したテーブルに対する開発と比較して、パーティション化はアプリケーションクエリに対して透過的であるため、パーティション化されたテーブルのクエリははるかに簡単です。

パーティション分割テーブルのスライディングウィンドウのメンテナンスには、パーティションTRUNCATE（または2016より前のSQLの世界ではSWITCH）とパーティション関数SPLIT/MERGEが含まれます。古いデータ/インデックスパーティションは、メンテナンス中に圧縮できます。 TRUNCATEまたはSWITCHの後にパーティション統計を更新する必要もあります。これらの操作用のDDLスクリプトは簡単に自動化され、個別のテーブルとインデックスを動的に作成/ドロップ/圧縮するスクリプトよりも複雑ではありません。

現在、MS SQL Server 2016には本当に不便な制限がありますか（エンタープライズとして、またはそれほど悪くはありませんか？）

テーブルのパーティション分割の最大の制限は、パーティション分割列がすべての一意のインデックスと制約の一部でなければならないことです。テーブルをパーティション分割することを計画しているテーブルがこれらの考慮事項の範囲内である限り、パーティション分割により、アプリのコードを変更することなく、多くの管理上の利点が得られます。可能な場合は、パーティションビューよりもパーティションテーブルをお勧めします。 SQL Server 2016 SP1以降、パーティション分割テーブルはStandard Editionで利用できます。

列ストア圧縮は、多くの場合、行ストアでのページまたは行の圧縮よりもはるかに高い圧縮を提供します。また、パーティション化列ストアにパーティション化非クラスター化インデックス（圧縮または非圧縮）を作成して、比較的少ない行を返すクエリのパフォーマンスを向上させることもできます。テーブルのパーティション分割と列ストアの両方を検討することをお勧めします。

先月だけクエリを高速化したいと思う理由がよくわかりません。あまり使用されないデータのインデックスのスペースオーバーヘッドが不要なだけだと思います。最近のストレージのコストが低いことを考えると、インデックススペースを節約するために複雑さを追加する必要はありません。圧縮、特に列ストアでは、そのようなフープを飛び越える必要がなくなると思います。

それでも先の道がわからない場合は、候補となる設計のプロトタイプを開発し、最小限の複雑さでニーズに最もよく対応するものを選択することをお勧めします。

2
Dan Guzman