次の方法で共有

Synapse 実装成功の技法: 専用 SQL プールの設計を評価する

  • [アーティクル]

注意

この記事は、「設計による Azure Synapse 実装の成功」シリーズの記事の一部です。 このシリーズの概要については、設計による Azure Synapse 実装の成功に関するページを参照してください。

専用 SQL プールの問題を特定し、ガイドラインと要件を満たしていることを検証するためには、その設計を評価する必要があります。 ''ソリューション開発を開始する前に'' 設計を評価することで、ブロッカーや予期しない設計変更を回避できます。 このようにして、プロジェクトのタイムラインと予算を保護します。

Synapse SQL には、計算データ処理を複数のノードに分散するスケールアウト アーキテクチャがあります。 コンピューティングをストレージから切り離すことで、システム内のデータとは無関係に、コンピューティングをスケーリングできるようになります。 詳細については、Azure Synapse Analytics の専用 SQL プール (旧称 SQL DW) アーキテクチャに関するページを参照してください。

評価分析

評価段階で、元のシステムのデプロイ方法と、実装された構造の詳細に関する情報を収集しました。 その情報は、実装内容と開発する必要がある内容とのギャップを特定するのに役立つ場合があります。 たとえば、ここでハッシュ分散テーブルではなくラウンドロビン テーブルを設計する場合の影響や、レプリケート テーブルを正しく使用するパフォーマンス上の利点を検討します。

ターゲット アーキテクチャを確認する

専用 SQL プールを正常にデプロイするには、ビジネス要件に合ったアーキテクチャを採用することが重要です。 詳細については、「Microsoft Azure のデータ ウェアハウス」を参照してください。

移行パス

Azure Synapse の移行プロジェクトは、他のデータベースの移行と似ています。 元のシステムと Azure Synapse には違いがある可能性があることを考慮する必要があります。

以下に対して明確な移行パスが確立されていることを確めます。

  • データベース オブジェクト、スクリプト、クエリ
  • データ転送 (ソースからのエクスポートして、クラウドに転送する)
  • Azure Synapse への初期データ読み込み
  • ログインとユーザー
  • データ アクセス制御 (行レベルのセキュリティ)

詳細については、「Azure Synapse Analytics の専用 SQL プールへデータ ウェアハウスを移行する」を参照してください。

機能のギャップ

元のシステムが Azure Synapse でサポートされていない機能に依存しているかどうかを判断します。 専用 SQL プールでサポートされていない機能には、XML や空間データ型、カーソルなどの特定のデータ型が含まれます。

詳細については、次を参照してください。

専用 SQL プールのテスト

他のプロジェクトと同様に、専用 SQL プールが必要なビジネス ニーズを満たしていることを確めるテストを実施する必要があります。 データの品質、データ統合、セキュリティ、パフォーマンスをテストすることが重要です。

次の手順

''Azure Synapse の設計上の成功'' シリーズの次の記事では、Spark プールの設計を評価して、問題の特定や、ガイドラインと要件を満たしていることの検証を行う方法について学習します。