セットレベルオペレーションは大いに関係します (SAP SQL Anywhere)

 

この記事のオリジナルは、Glenn Paulley がsybase.com に2008年5月に掲載したものです。Glenn はこの中でデータ量が大量の場合には、セットオペレーションがパフォーマンスにたいへん効果的であると語っています。

Hibernate object persistance library が提案するアドホックなリレーショナルマッピングが起こす問題の1つに、サブクエリーを含むクエリーの生成 – 時に非常に大量 -があります。サブクエリーは、最適化するのが非常に難しく、なぜならばそのコストと選択性を見積もることが依然としてたいへんチャレンジングな研究課題であるからです。

SQL Anywhere には、サブクエリーに対して、たいへん洗練されたクエリーリライトオプティマイゼーションの機能が備わっています。しかしながら、SQL Anywhere を含む多くの商用製品におけるサブクエリーの最適化と実行には、依然として問題があります。

今週、私はあるお客様のアプリケーションにおける問題特定を行いました。このブログ記事において伝えたいのは、サブクエリー実行のインパクトは、アプリケーションのスケーラビリティに影響するかもしれないという点において明確だということです。

これまで様々なアプリケーションの複雑なクエリーを見てきた中で、それらに共通して見られるのは、サブセレクトまたは複雑なクエリー内の abstruct の測定にユーザー定義関数を活用する傾向があることです。今日分析した複雑なクエリー – 手で書かれたもの – は、複雑なビューの 4 方向の join で、最初のビュー自体が複雑なビューであり、サブクエリーを join にコンバートする最適化をリライトした後でさえ、サブクエリーが48含まれていました。全てではありませんが、サブクエリーのほとんどは、下の形でした。

  1. SELECT <select  list from T>,
  2.       (SELECT R.X
  3.                 FROM R
  4.         WHERE R.PK = T.X)
  5. FROM T

このサブセレクトは、単一のローを確実に返すようになっています。なぜならば、サブセレクトの WHERE 句は、テーブルR のプライマリーキーカラムをカバーするからです。そして、もしT.X がNULL の場合、このサブセレクトは NULL 値を返します。これらのプロパティは、上記の nested query が outer join クエリーに相当することを意味しています。

  1. SELECT <select list from T>, R.X
  2. FROM T LEFT OUTER JOIN R ON (T.X = R.PK)

構成間のパフォーマンスの違いを説明するために、実際のお客様のデータベースを使用して、上の例と似ている構成のクエリーを実行してみました。

私のテストでは、テーブル T は、ローが 635K 行で、テーブル R は、11000万行のローから成るシングルベースのテーブルのビューでした。上の例と少しだけ異なるのは、テーブル R は4 カラムで成るキーがあり、それゆえにサブセレクトと left outer join の ON 条件の両方の検索条件に、4つの等号条件（equality predicate）が含まれていました。

クエリーの構成が間違いなくそのままであるように、一方でクライアント・サーバー伝送コストをなくすように、上のクエリーをderived テーブルに encapsulateし、それぞれのケースで aggregate 関数を使用して最終結果セットを単一のローに制限しました。FETCHTST ユーティリティーを使用して実行時間を比較しても良かったのですが、DBISQL からの実際の統計とグラフィカルなプランを使用して、それぞれの実行に関する詳細統計をとらえました。

結果は、

 

 

続きはこちら：セットレベルオペレーションは大いに関係します (SAP SQL Anywhere)

 

 

SAPの SAP SQLAnywhere製品ページはこちら