本投稿は 2018/4 時点の Public Preview の内容です。
一般提供開始時には変更されている可能性があります。
SQL Database Managed Instance と Azure の SQL Server ベースのサービスを比較してみた際にまとめたものを投稿しておきたいと思います。
機能差異については、次のドキュメントから追うことになるかと。
比較結果は、利用者によっていろいろな観点があるかと思いますので、今回の比較はあくまでも「私個人が調べた結果での比較」となっていますのでご了承ください。
(MI はプレビューのサービスですので、この投稿に書いてある内容も、時期によっては古いですのでご承知おきください)
■SQL DB と MI の比較
まずは、PaaS 型のサービス同士で比較してみたいと思います。
SQL DB ではできないが、MI でできること
- BACKUP コマンドによるバックアップ取得
- COPY_ONLY のみ可能
- RESTORE コマンドによるバックアップのリストア
- SQL Server 2005 以降のバックアップをリストア可能
- 2005 をリストアした場合、互換性レベルが 100 に変更される
- SQL Server 2005 以降のバックアップをリストア可能
- CLR
- 複数データベース間のクエリ
- データベースをまたがるトランザクション
- データベースメール
- ドキュメントで公開されているDBCC ステートメント
- TF の操作は含まれていない
- 分散パーティションビュー
- リンクサーバー
- SQL Server / SQL Database MI に対して設定可能
- システムデータベースの変更
- tempdb の構成変更
- OPENDATASOURCE / OPENQUERY / OPENROWSET による外部連携
- Service Broker
- クロスインスタンスの Service Broker は非サポート
- サーバー構成の設定変更
- USE ステートメントによるデータベースの変更
- SQL Server Agent
- 定期的なT-SQL の実行が可能
- SQL Server Audit
- SQL DB の場合は DB レベルでの監査
- SQL Server Profiler
- 仮想ネットワークとの完全な統合
- プライベート IP でのみアクセスすることが可能
MI は Managed Instance 型のサービスですので、SQL DB ではできなかった、複数のデータベースを跨いだクエリの実行も柔軟に実施することができます。
一つのインスタンスの料金で複数の DB を構築することができますので、コストを抑えるのであれば、1 インスタンスにどの程度 DB を乗せるかということも考慮点てとしてあります。
他にもネイティブバックアップのリストアによる、Box の SQL Server からの容易な移行もメリットですね。
SQL DB への移行は、BacPac をベースとして考えるのがシンプルではあるのですが、BacPac はこれはこれで、移行がしんどいのですよね…。
ネイティブバックアップのリストアはかなり強力な移行方法となるかと。
SQL Server Agent を使用した定期的なクエリの実行というような利点もあります。
今まで、SQL DB に対して定期的にクエリを実行する場合、Azure Automation や Azure Functions のスケジュール実行を組み合わせる必要があったのですが、MI の場合は、SQL Server 内に、定期的なジョブ実行の環境も内包させることができます。
SQL Server Profiler を使用したクエリのトレースも実施することが可能ですので、クエリの取得も楽に実行できますね。
SQL DB でできるが、MI でできないこと
- インデックスの自動チューニング
- エラスティックプール
- MI 内に複数の DB を作成することで代替
- Geo リストア
- COPY_ONLY を使用して独自に実装することで代替
- Geo レプリケーション
- メモリ最適化テーブル
- R Services
- SQL Data Sync
- レプリケーション
- TDE
- グローバル IP アドレス経由でのアクセス
MI は、SQL DB でできることがすべてできるかというとそういうこともなく、SQL DB でのみ利用可能な機能もいくつかあります。
メモリ最適化テーブルは現状利用可能な汎用目的では利用できないのですが、これはビジネスクリティカルが提供された場合にどうなるかはチェックが必要かと。
現状、地理的な冗長系については、SQL DB の方が柔軟性があるため、DR 要件がある場合は、どのように実装するかの検討が必要になってきます。
自動チューニングのインデックスの自動作成については、MI には実装されていないようなので、この辺も覚えておくとよいかと。
(インデックスの自動チューニング、DTA を使わないで Box の SQL Server でも使えるようになるとうれしいですね)
SQL Server でできるが、MI でできないこと
- ローカルファイルパスの利用
- データ取り込み / 監査ログ / 拡張イベント等をローカルに出力
- データベースのアタッチ
- データベースミラーリング
- Data Quality Service
- データベーススナップショット
- MSDTC を使用した分散トランザクション
- 拡張ストアドプロシージャ
- File Stream / File Table
- フルテキスト検索でサードパーティーのワードブレーカーの利用
- セマンティック検索
- メモリ最適化テーブル
- マスターデータサービス
- 一括ログを使用した最小ログ記録
- Polybase
- ポリシーベースの管理
- DB エンジン以外のサービスの利用
- SSIS
- MI では、Azure Data Factory で代替を検討
- SSAS
- MI では、Azure Analysis Services で代替を検討
- SSRS
- MI では、Power BI で代替を検討
- R Services / ML Services
- SSIS
- リソースガバナー
- SQL Server 以外へのリンクサーバーの設定
- ログ配布
- レプリケーション
- SQL Server Agent で T-SQL 以外の実行
- トレースフラグの設定
- バッファプール拡張
- Windows 認証
- 透過的なデータ暗号化
- 暗号化プロバイダーの追加
- ストレッチデータベース
- xp_cmdshell を使用したコマンド実行
- 完全 + COPY_ONLY バックアップ以外のバックアップ取得
- 差分 / ログバックアップは取得できない
- システムデータベースのリストア
- ログイン / リンクサーバー / SQL Server Agent 等の移行は、スクリプトで検討する必要がある
- サーバーレベルの照合順序の指定
- MI はSQL_Latin1_General_CP1_CI_AS で固定
- サーバーのタイムゾーンの指定
- MI の日付関数は UTC で固定
- 8TB 以上のデータベースの利用
- 利用者による再起動タイミングの調整
MI は SQL Server と 100% に近い互換性を目指して開発されているものになりますが、いくつかの機能は MI ではサポートがされていないのが現状です。
MI の日付系の関数については、SQL DB と同じく UTC が基準となっており、タイムゾーンの変更ができませんので、GETDATE 等で日付を取得している箇所については、日本時間への変換が必要となってきます。
(この辺は移行後のアプリケーション変更の考慮にもなるのではないでしょうか)
SQL DB と同様にメンテナンスウィンドウの設定が無いため、リコンフィギュレーションの発生タイミングの制御についても難しいかと思います。
SQL Server でできないが、MI でできること
- 構築直後の状態で、可用性環境が構築されている
- 構築直後の状態で、自動バックアップが設定されている
- 自動的に最新の状態にアップグレードされることにより、最新の機能が常に利用できる
- 脅威検出による PaaS のセキュリティ機能を使用できる
- Azure の運用監視の仕組みを使用することができる
MI はインスタンス単位で利用可能な SQL Server ですが、可用性や冗長構成がデフォルトで設定されており、バージョンアップも自動化されているので、一度移行を行うと常に最新化して使えるというのはメリットかと。
脅威検出のような PaaS のセキュリティ機能も使用することができますので、異常検出については、SQL Server より高いレベルのものが使用できるかと。