Skip to Content

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

 

 

この記事のオリジナルは、Glenn Paulley が sybase.com に掲載したものです。

 

 

 

 

私たちは、リレーショナルデータベースであるSQL Anywhere を、より完全なセルフマネージング、セルフチューニング、そしてセルフヒーリングのデータベースにするための努力を重ねていますが、その一方で、パフォーマンスの問題を診断し、解決する必要性は依然として存在しています。

 

この必要性は、一部にはクエリー最適化における全体的な複雑性にあります。

クエリー最適化とは、- 未だ – NP – つまり難しい問題であり、最適化プロセスへのインプットには、様々な heuristics (経験則)、特に述部の選択的推測が含まれます。

しかしながら、パフォーマンス問題の原因は、今日のコンピューターの特徴でもある増加するハードウェア環境の複雑性にもあります。この記事では、この種の問題の診断に関して最近発表された論文2つについてハイライトをあてたいと思います。

 

最初の2つの論文 [1,2] は、Duke University と IBM Almaden の調査員によるジョイント論文で、DIADS というパフォーマンス診断ツールのプロトタイプについて説明しています。

このツールは、データベースサーバー(著者はテストシステムとして Postgres を使用しています)が、SAN (Storage Area Network) をディスクリソースに利用した場合のパフォーマンス問題の診断支援のために設計されたものです。

SAN の問題は、これが複雑で、かつ、ディスクストレージ(pools または volumes)の論理ユニットにより構成された独立したシステムで、通常複数のアプリケーション/データベースに同時にサービスを提供するという点にあります。

非常に多くの場合、 SAN の管理は独立して行われるため、データベース管理者は SAN を「ブラックボックス」として扱うことを余儀なくされます。

 

注釈つきプラングラフ を使った、特定のクエリープランオペレーターによるSANのリソースの使用状況を表示するDIADS という診断システムのプロトタイプは、Borisov et al. 氏が、開発しました。

DIADS は、コンフィギュレーション依存分析と兆候シグネチャーを使用して、特定の注釈つきプランを詳細にドリルダウンします。 また、同じクエリーのアクセスプランを比較し、各オペレーターの平均時間からの偏差をベースにメトリクスを計算することができます。

物理的、論理的コンフィギュレーションの詳細を含めたSAN モニタリングデータ、コンポーネント接続性、時間経過によるコンフィグレーション変更、データベース管理者が定義したイベントなどは、注釈つきクエリープランに含まれており、データベース管理者が、ひとつのディスプレイ内で、SAN 統計の詳細と一緒に実際の特定のプランオペレーターのパフォーマンスの特徴分析ができるようになっています。

DIADS には、ナレッジベースも含まれており、相互に関連し依存するプランオペレーター、相互に関連するオペレーターカーディナリティー、そして原因 vs 効果の分析を支援する兆候データベースなど、トラッキングを通じたプランオペレーターパフォーマンス診断のエキスパートシステム分析が可能になっています。

 

2つめの論文は、HP ラボの Goetz Graefe氏、Harumi Kuno氏、そして Janet Wiener 氏によるもので、彼らは、クエリー実行エンジンの堅牢さレベルの決定の問題、つまり、様々な予期しないランタイムの条件下において一貫性のあるパフォーマンスを提供するサーバーの能力に関する研究について述べています。

例えば、リソースコンテンションやカーディナリティー見積もりのエラーなどです。

著者は、クエリー実行の堅牢性は、そのクエリーオペレーターの基礎自体と同様に重要であると論じています。- それについては私ももちろん同感です。

 

著者のアプローチは、プランロバストネスマップをビジュアルに使用することでプランオペレーターの堅牢性について説明するもので、全体作業量が増加するにつれ、またはシステムのリソースが制約されるにつれ、いかに特定の実行戦略がデグレードするかの理由にこれらの2D、または3Dのグラフを使用することができます。

 

ここで採用されているビジュアル化の技術を反映することで、これらのダイアグラムにより予測されるパフォーマンスの迅速な証明、仮説のテスト、代替のクエリー実行プランの相対的、絶対的パフォーマンスの洞察が可能になります。

また、とてもシンプルなクエリーであっても、過多なクエリー実行プランがあります。パラメータースペースにわたって複数のディメンションで多くのプランを調査するのは、効率的なビジュアル化によってのみ可能です。

 

この作業は、他の作業を賞賛するオプティマイゼーションの品質、あるいはon-the-flyでのSQL リクエストの動的な再オプティマイゼーションに対応するクエリー実行パフォーマンス、つまり、システムパラメーターの特定のセットの最適なプランを見つけるそのシステムのオプティマイザーの能力、に対する興味深い見方を提供してくれます。

 

[1] Nedyalko Borisov, Shivnath Babu, Sandeep Uttamchandani, Ramani Routray, and Aameek Singh (January 2009). Why did my query slow down?In Proceedings, 4th Biennial Conference on Innovative Data Systems Research (CIDR), Asilomar, California.

 

[2] Nedyalko Borisov, Shivnath Babu, Sandeep Uttamchandani, Ramani Routray, and Aameek Singh (February 2009). DIADS: Addressing the “My-Problem-or-Yours†Syndrome with Integrated SAN and Database Diagnosis. In Proceedings of the 7th USENIX Conference on File and Storage Technologies (FAST’09), San Francisco, California.

 

[3] Goetz Graefe, Harumi Kuno, and Janet L. Wiener (January 2009). Visualizing the robustness of query execution. In Proceedings, 4th Biennial Conference on Innovative Data Systems Research (CIDR), Asilomar, California.

 

 

 

 

 

===

 

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

 

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

に掲載しています。

 

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

 

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

Language には「Japanese」、
Primary Tag には「SQL Anywhere」、
Additional tag には「SAP SQL Anywhere」、
User Tagに「sql anywhere japanese question」

を選択してください。

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

 

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

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

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply