web-dev-qa-db-ja.com

VLDBのパーティション戦略を設計する方法OLTPソリューション(SQL Server 2016、> 100TB初期サイズ)

現在、PetaByteレベルを超えるデータセット(OLTPベース)を処理するMSSQL 2016ベースのプラットフォームの設計に取り組んでいます。さまざまな方法とツール(Rを含む)を使用して傾向を発見する必要がある特定のタイプの分析に使用されます。 「ライブ」ベースでデータベースにデータを供給するさまざまなソースと、バッチベースで取り込まれるデータのバッチがあります。大量のトランザクション、予測される同時ユーザー数(> 250)、およびユーザーによるデータの消費方法(後ほど)により、このソリューションは高性能でスケーラブルである必要があります。データコンシューマーをサポートするために、データをいくつかのレベルに分割する必要があることは明らかです。

ユーザーは、傾向分析タイプのワークロードを毎日、毎週、毎月、および複数年の範囲で実行します。ほとんどのデータには日付フィールドが提供されますが、顧客名、口座番号、トランザクションタイプもトレンド分析の対象となります。

皆さんへの私の質問は次のとおりです。適切なパーティショニングソリューションを設計するための戦略は何ですか?どのような質問をし、その答えで何を探しますか?インデックスなどのメンテナンスをどのように処理しますか?...どのような要素を設計に取り入れますか?

Oowwwを使用して、すべてをデータレイク(読み取り:沼)にドロップするか、別のプラットフォームに移行することはできません。また、プロジェクトの詳細や関連するデータについて自由に話し合うことはできませんので、質問しないでください。機密性の高い財務データと個人データであることを知ってください。私たちに課せられた合法的な要件に従って、法医学分析(R、PowerBI、および/または他のBIツールを使用)を行います。これ以外の詳細は共有しません。申し訳ありません。

3
MvdMunnik

OLTPデータベースのいくつかの重要な前提条件と提案を説明する記事を読むことをお勧めします。

http://nerdtechies.com/2016/12/05/improve-write-performance-sql-server-database/

ロードプロセスには_BULK INSERT_を使用し、通常の挿入ユーザーにはWITH(ROWLOCK)を使用します。

https://technet.Microsoft.com/en-us/library/dd425070.aspx

パーティショニング

知っておくべきこと。

  1. オンラインデータの保持とは何ですか?
  2. 成長/日とは何ですか?
  3. ユーザーはどの基準に基づいて最大値を引き出しますか(毎日/毎週/毎月または毎年)?
  4. アーカイブポリシー。

--2 TBテーブルが50GB /日、1か月のデータがWHに残り1か月のデータを含む)の経験があります。

70-80%の場合、毎日の分析レポートの使用。大量のデータがあるので、私は毎日のパーティションに行くことをお勧めします。パフォーマンスは速くなりますが、週次、月次、年次のレポートを生成するには、長いクエリが必要になります。

毎日、毎週、毎月の分析の比率が50から50の場合は、毎月のパーティション分割に進みます。この場合、月ごとにフィルタリングするレコードが多いため、日次および週次ベースのレポートの実行は、日ベースのパーティション化よりも遅くなります。しかし、非常に単純なクエリになります。

オンラインデータの保持を考慮したパーティション化により、アーカイブポリシーが容易になります。

インデックス

テーブルがパーティション分割されるため、テーブルにパーティションインデックスを作成する必要があります。パーティションインデックスを作成するには、インデックスにパーティションベース列を含める必要があります。パーティションテーブルにパーティションインデックスを作成しない限り、パフォーマンス上の利点は得られません。

個別のファイルグループにインデックスを作成すると、レポートのパフォーマンスが向上します。したがって、テーブル用に作成したものと同じインデックス用に、個別のファイルグループに個別のパーティション構成、関数を作成します。

Index_Partition_Schemeの(Base_Partition_Column、顧客名、口座番号、トランザクションタイプ、財務列)の列に格納されたインデックスに移動することをお勧めします。

_FILLFACTOR=80_でインデックスを作成する

パーティションインデックスを作成すると、インデックスのメンテナンスが容易になります。完全なインデックスを再構築または再編成する代わりに、インデックスの特定のパーティションに対してメンテナンスタスクを実行して、大きなテーブルのメンテナンス期間を最小限に抑えることができます。

これを行うには、インデックスの断片化とパーティションの行数を追跡できます。パーティションを再構築する必要があるインデックスを見つけるのに役立ちます。

メンテナンススケジュールは、データサイズ、メンテナンスアクティビティを実行するために必要なオフ期間、SQL Serverがタスクを完了するまでにかかる時間によって異なります。最初に同じ量のデータを使用して、テスト環境で保守計画をテストしてから、時間外に終了する場合は、運用環境に移行することをお勧めします。

ありがとう

0
Rajesh Ranjan