地理空間結合述部 - Advanced SQL Engine - Teradata Database

Teradata Vantage™ - 地理空間データ型

Product
Advanced SQL Engine
Teradata Database
Release Number
17.05
17.00
Published
2020年6月
Language
日本語
Last Update
2021-03-30
dita:mapPath
ja-JP/vci1556127188517.ditamap
dita:ditavalPath
ja-JP/vci1556127188517.ditaval
dita:id
B035-1181
Product Category
Software
Teradata Vantage
地理空間結合述部で構成されている場合、最適化ルーチンは、入れ子結合を実行することにより、地理空間問合わせを満たすのに必要なデータへのアクセス速度を上げることを検討します。サポートされている結合述部(ST_DistanceとST_3DDistanceを除く)は、次のいずれかの形式を使用します(ここでGeoColExpressionにはTable2からの列が含まれています)。
SELECT a, b 
FROM Table1, Table2
WHERE Table1.GeoCol.SupportedGeoMethod(Table2.GeoCol)=1
または
SELECT a, b 
FROM Table1, Table2
WHERE Table1.GeoCol.SupportedGeoMethod(GeoColExpression)=1
または
SELECT a, b 
FROM Table1, Table2
WHERE GeoColExpression.SupportedGeoMethod(Table1.GeoCol)=1
または
SELECT a, b 
FROM Table2 JOIN Table1
      ON 
      Table1.GeoCol.SupportedGeoMethod(Table2.GeoCol)=1
結合述部とみなすには、式の結果が1(true)になるように設定する必要があります。
ST_DistanceまたはST_3DDistanceを使用する地理空間距離の述部は、次のいずれかの形式を使用します。
SELECT a, b
FROM Table1, Table2
WHERE Table1.GeoCol.SupportedGeoDistanceMethod(Table2.GeoCol) < DistanceLiteral

または
SELECT a, b
FROM Table1, Table2
WHERE Table1.GeoCol.SupportedGeoDistanceMethod(GeoColExpression) < DistanceLiteral
または
SELECT a, b
FROM Table1, Table2
WHERE GeoColExpression.SupportedGeoDistanceMethod(Table1.GeoCol) < DistanceLiteral
または
SELECT a, b
FROM Table2 JOIN Table1
ON
Table1.GeoCol.SupportedGeoDistanceMethod(Table2.GeoCol)  < DistanceLiteral
これらの述部を形成するために、<または<=演算子のいずれかを使用できます。
構文要素 説明
Table1およびTable2 地理空間データ列を含むテーブル。
GeoCol ST_Geometry列。
結合の少なくとも1つの側、所有者式または引数は、地理空間インデックスを持つST_Geometry列である必要があります。
GeoColExpression ST_Geometry値に評価され、結合される1つのテーブルの中の列への1つの参照が含まれる式。
SupportedGeoMethod 地理空間述部および最適化ルーチンに記載されている地理空間メソッドのいずれか(ST_DistanceとST_3DDistanceは除く)。
SupportedGeoDistanceMethod ST_DistanceまたはST_3DDistanceのいずれか。
DistanceLiteral 距離を表わす浮動小数点値。

例: 地理空間結合述部の使用

次の例は、2番目のテーブルで定義されたポリゴン内にある1つのテーブル内の点を決定するための地理空間結合述語の使用法を示します。このようなクエリーでは、Teradata最適化ルーチンは、データ アクセスを高速化するために入れ子結合の生成を検討します。

CREATE TABLE DB_TEST.T1
(a INTEGER, b char(20000), GeoCol ST_Geometry)
INDEX (GeoCol);

CREATE TABLE DB_TEST.T2
(pkey INTEGER, buffer char(20000), Geom ST_Geometry)
INDEX (Geom);


INSERT INTO DB_TEST.T1 (1, 'Teradata01', 'POINT(10 20)');
INSERT INTO DB_TEST.T1 (1, 'Teradata02', 'POINT(20 30)');

INSERT INTO DB_TEST.T2 (1, 'Teradata01', 'POLYGON((3 3, 3 8, 8 8, 8 3, 3 3))');
INSERT INTO DB_TEST.T2 (1, 'Teradata02', 'POLYGON((15 15, 15 35, 35 35, 35 15, 15 15))');
SELECT a,b (format 'x(12)'), geocol
FROM T2
INNER JOIN T1 ON T1.GeoCol.ST_WITHIN(T2.Geom)= 1;

          a b            GeoCol
----------- ------------ -----------------
          1 Teradata02   POINT (20 30)

テーブルに挿入される行の数と地理空間データ自体の性質により、最適化ルーチンが地理空間インデックスを使用するかどうかが決まります。この簡単な例では、各テーブルに行が2つしかなく、地理空間インデックスを使用することはおそらくないでしょう。非常に大規模なテーブルや、より複雑な図形、データベースの特性および構成によって、最適化ルーチンがクエリー処理を高速化するためにインデックスを使用する可能性があります。インデックスを使用した場合、EXPLAINは次のようになります。ステップ5で、地理空間インデックスを使用したことを示しています。

Explanation
---------------------------------------------------------------------------
  1) First, we lock DB_TEST.T1 for read on a reserved RowHash to
     prevent global deadlock.
  2) Next, we lock DB_TEST.T2 for read on a reserved RowHash to
     prevent global deadlock.
  3) We lock DB_TEST.T1 for read, and we lock DB_TEST.T2 for read.
  4) We do an all-AMPs RETRIEVE step from DB_TEST.T2 by way of an
     all-rows scan with a condition of ("DB_TEST.T2.b > 1") into
     Spool 2 (all_amps), which is duplicated on all AMPs. The size of
     Spool 2 is estimated with no confidence to be 116 rows (1,168,468
     bytes). The estimated time for this step is 0.67 seconds.
  5) We do an all-AMPs JOIN step from Spool 2 (Last Use) by way of an
     all-rows scan, which is joined to DB_TEST.T1 by way of Spatial
     index # 4 "Retrieving from CDT indexed column DB_TEST.T1.sp via
     CDT key expression {LeftTable}.sp .ST_MBR ()"extracting row ids
     only. Spool 2 and DB_TEST.T1 are joined using a nested join,
     with a join condition of ("(1=1)"). The result goes into Spool 3
     (all_amps), which is built locally on the AMPs. Then we do a SORT
     to order Spool 3 by field Id 1. The size of Spool 3 is estimated
     with no confidence to be 1 row (10,083 bytes). The estimated time
     for this step is 0.01 seconds.
  6) We do an all-AMPs JOIN step from Spool 3 (Last Use) by way of an
     all-rows scan, which is joined to DB_TEST.T1 by way of an
     all-rows scan with a condition of ("DB_TEST.T1.b > 1"). Spool
     3 and DB_TEST.T1 are joined using a row id join, with a join
     condition of ("(sp .ST_WITHIN ({RightTable}.sp ))= 1"). The
     result goes into Spool 1 (group_amps), which is built locally on
     the AMPs. Then we do a SORT to order Spool 1 by the sort key in
     spool field1. The size of Spool 1 is estimated with no confidence
     to be 1 row (95 bytes). The estimated time for this step is 0.05 
     seconds.
  7) Finally, we send out an END TRANSACTION step to all AMPs involved
     in processing the request.
     -> The contents of Spool 1 are sent back to the user as the result of
     statement 1. The total estimated time is 0.73 seconds.

地理空間結合のST_Geometry列と列式の両方の使用

次の例では、所有者式または引数のいずれかである地理空間結合の片側が、列を含む列式である場合があり、ST_Geometry値として評価されることを示しています。結合のもう一方の側は、地理空間インデックスを持つ地理空間列である必要があります。この例では、ST_DISTANCE述部を使用します。g2.geo.ST_Buffer(1)は、ST_Geometryオブジェクトを生成するg2からの空間列を含む式です。g1.geoは、地理空間インデックスを持つg1のST_Geometry列です。
SELECT * FROM geotable g1, geotable2 g2
WHERE g1.geo.ST_Distance (g2.geo.ST_Buffer(1)) < 5
ORDER BY g1.a;

最適化ルーチンによる入れ子結合利用の決定方法

Teradata Optimizerは、問合わせを満たすために入れ子結合戦略を使用した際のコストと利益とを比較検討します。最適化ルーチンは次のような要素を使って、入れ子結合を構成するかどうか判断します。
  • 複製されたテーブルのカーディナリティとサイズ。

    結合操作に含まれるテーブルのうち1つのみで定義された地理空間インデックスがある場合、最適化ルーチンは、インデックス付けされていない方のテーブルを複製します。

    地理空間インデックスが、両方のテーブルに定義されている場合、最適化ルーチンは各テーブルの複製と、他のテーブルのインデックス使用にかかるコストとを計算し、最もコスト効率の良い組み合わせを選択します。

  • 行IDスプールのカーディナリティとサイズ。

    行IDスプールに投入される行数は、その結合の選択性に依存します。

    行IDスプール中の行のサイズは、複製されたテーブルに属する列数に依存します。この列は問合わせで参照されたものです。

Teradata Optimizerが問合わせに対して実行パスを選択する方法についての詳細は、<Teradata Vantage™ - SQLリクエストおよびトランザクション処理、B035-1142>を参照してください。