マテリアライズドビュー（インデックス付ビュー/マテリアライズド照会表）を利用するにあたり考慮すべき要素 – SAP SQL Anywhere (過去のブログより)

このページは、以下の英語ページの抄訳です。最新の情報については、英語ページを参照してください。

https://blogs.sap.com/2014/06/18/factors-to-consider-for-utilizing-materialized-views/

この記事のオリジナルは　Glenn Paulley が sybase.com に 2009 年 9 月に掲載したものです。その中で、Glenn は 2種類のマテリアライズドビューについて説明するとともに、マテリアライズドビューを使用する際に考慮すべき点について解説しています。

（2006年にリリースされた） Version 10より、SQL Anywhere では、遅延反映型マテリアライズドビューをサポートしています。（2008年にリリースされた） version 11 では、即時反映型マテリアライズドビューをサポートしました。これら2種類の大きな違いは、以下のとおりです。

• 遅延反映型マテリアライズドビューでは、クエリオプティマイザーは、staleデータを含む1またはそれ以上のマテリアライズドビューを利用してクエリに答えます。あらゆるビューの 「stale性」や、クエリへの答えにビューを使用するか否かは、全てデータベース管理者のコントロール下にあります。また、データベース管理者は、データの正確性とマテリアライズドビューが提供するパフォーマンスの向上と、そのビューの更新反映コストをトレードオフすることが可能です。
• 逆に、即時反映型マテリアライズドビューは、マテリアライズドビューの定義のベースとなるベーステーブルの更新と同一のトランザクション内で更新されます。即時反映型ビューは、それぞれの更新オペレーションにともなったビューへの反映の必要性を犠牲に、派生的に生成される最新ビューのベースとなるベーステーブルの分単位レベルのコピーを提供します。

まとめると、遅延反映型ビューでは、マテリアライズドビューのメンテナンスコストのamotizationが可能であるのに対して、即時反映型マテリアライズドビューでは、更新されたそれぞれのトランザクションでビューの反映にオーバーヘッドが発生します。そのため、同時実行トランザクション間の競合が発生する可能性があります。

マテリアライズドビューを遅延反映型にするのか即時反映型にするのかは、マテリアライズドビューを利用するかどうかを決める場合に、データベース管理者が考慮すべき要素の1つです　—– 文字通り、これは、「view selection problem」として知られています。

また、遅延反映か即時反映かのトレードオフの他にも考慮すべき点があります。

以下に、マテリアライズドビューの利用を検討する場合に考慮すべき項目のチェックリストを挙げます。

• マテリアライズドビューを作成することによってメリットのあるクエリのセットは何か?

この質問に回答するには、個々のクエリの定義と頻度の両方の詳細について考慮することに加え、システムのクエリの負荷分析も必要になります。

まずは、頻繁に実行され、expensiveなクエリ、特に、レスポンス時間への要求が重要なexpensiveなクエリから始めるのが良いでしょう。

Sybase Central (現SQL Central) SQL Anywhere プラグインに含まれる SAP SQL Anywhere のアプリケーション プロファイリング機能を使用すると、アプリケーションのワークロードをキャプチャし、それに含まれる「heavy hitters」を特定することができます。

複数の共通クエリにおいてメリットのあるマテリアライズドビューは、最も大きなメリットを享受できることを表しています。

なぜならば、ビューのためのストレージやメンテナンスコストはコンスタントに必要なものの、マテリアライズドビューのメリットは利用に伴って増加するからです。

また、単一のクエリでも、複数のマテリアライズドビューを使用できることを覚えておいてください。

複雑なマテリアライズドビューを複数のビューに分割すると、より大規模なクエリのセットをアシストするためにオプティマイザーがマテリアライズドビューを利用する可能性があります。

集合 (GROUP BY) を含むマテリアライズドビューを検討している場合には、複数のクエリに対してより広く適用できる基本関数をマテリアライズする方が良いことが多いものです。

例えば、AVG() は、SUM() と COUNT(*)のコンビネーションより得ることができます。

SQL Anywhereのクエリオプティマイザーは、非常にインテリジェントであるため、オリジナルのクエリにAVG()が含まれる場合には、マテリアライズドビューからSUM() と COUNT() を利用します。

• クエリパフォーマンスの潜在的な改善が、マテリアライズドビューのストレージやメンテナンスコストを上回るのか?

データベース管理者は、マテリアライズドビュー — とそのインデックス — のためのスペースの要件とそれによる潜在的なクエリパフォーマンスの改善と、そのビューのメンテナンスコストをトレードオフする必要があります。

この時、データベース管理者はアプリケーションのリクエストによる更新パターンを認識している必要があります。

ヘビーに更新されるベーステーブルのマテリアライズドビューには、次の2つの理由で、許容できないメンテナンスコストが存在する可能性があります。

マテリアライズドビュー自身への更新のコスト、そして、マテリアライズドビューを含むテーブル（またはインデックス）に対する同時更新による更新トランザクションのロックの競合の増加です。2つめの問題は、適切な容量計画がないと、アセスメントは困難です。

データベース管理者は、他のベーステーブル同様、マテリアライズドビューにインデックスをつけることができることを認識していないことがよくあります。

インデックスは、特にアプリケーションのクエリの中、ビューには含まれていないテーブルへの追加のjoinが含まれる場合に役に立ちます。

インデックスが存在する場合には、オプティマイザーには、より物理的なオペレーターの選択肢 — 特に indexed nested-loop join —　があり、これによりスピードを大幅に向上することができます。

• もしオプティマイザーがある1つのケースにおいてマテリアライズドビューからのstale データを利用することを選択し、他ではベースとなる（そして最新の）ベーステーブルを処理することを選択した場合、同一のクエリにおいて、異なる結果を返すことは許容されるのか？
• マテリアライズドビューの格納データは、staleになってもよいのか？
• 認められなくなる前には、データはどのようにstaleになることが可能か?

後半の質問は、即時vs遅延反映型マテリアライズドビューのトレードオフに関係します。

上で説明したとおり、遅延反映は、データのstale性のexpense時に、データベース管理者が複数の更新トランザクションにわたりビューのメンテナンスをアモタイズすることができます。

アプリケーションにとって、遅延メンテナンスビューによるメリットがあるかどうかは、主にビジネス要素による判断であり、システム要素によるものではありません。

この記事の詳細情報を提供してくれた同僚のAnil Goel に感謝します。

===

SAP SQL Anywhere に関する詳細情報は、SAP SQL Anywhere Communityページ<英語> を参照してください。

上記のコミュニティーに掲載されている技術情報は、順次SQL Anywhere　日本語コミュニティ

に掲載しています。

SQL Anywhere に関してはまずはこちらをご参照ください。無期限でご利用いただける無償の Developers Edition もこちらからダウンロードが可能です。

SQL Anywhere に関して技術的な質問のある方はコミュニティに登録し、
「Ask a Question」機能をご利用ください。

Language には「Japanese」、
Primary Tag には「SAP SQL Anywhere」を選択
User Tagに「sql anywhere」「sql anywhere Japanese question」

を入力してください。

不具合につきましては、サポート契約者様専用の問い合わせ方法にてお問い合わせください。

======================
ご購入に関するお問い合わせ

こちらよりお問い合わせください。