ラスターデータベースのクエリを高速化する方法は?


16

私はこれらの列を持つpostgresql / postgisにラスターデータベースを持っています:

(ID、rast、data_of_data)

「ラスト」は、WKT形式のラスターファイルがある列です。WGS84システム(30.424、-1.66)および2002-01-09のポイントのDN値を検索するクエリの例は次のとおりです。

SELECT 
     st_value(rast,(st_GeomFromText('POINT(30.424 -1.66)', 4326))) as val
FROM 
     my_table
WHERE
     date_of_data='2002-01-09'

これらの種類のクエリを高速化する方法(空間インデックスなど)はありますか?


おそらく、さらに詳細を提供することで私たちを助けることができます:my_tableにはいくつのレコードがありますか?ラスター列のデータはどのくらいですか?date_of_dataにはいくつの異なる日付がありますか?
dwurf

これに追加:ラスト列のSRIDは何ですか?
dwurf

回答:


12

これは刺激的な質問です!クエリするラスターの大きさは?WKTRasterはBLOBとしてデータベースに保存されます。特定のポイントで値を見つけるために、既知の(x_0、y_0)コーナー座標から行/列インデックス(i、j)が(dx、dy)ステップと回転を使用して計算されます。(i、j)が既知の場合、ST_Value()関数は正しいバイトオフセットで実際のデータにアクセスできます。

これは、ポイントのクエリに応答するときに、DBが平均でデータブロブの少なくとも半分を読み取る必要があることを意味します(実装に応じて、常にすべてのデータを実際に読み取ることができます)。したがって、データBLOBが大きくなりすぎる、WKTRasterのパフォーマンスが低下すると思います。データセットをタイリングすると、クエリが高速化されます。このチュートリアルで SRTMデータ(6000x6000ピクセルチャンクで受信)の処理方法をご覧ください。彼らは実際にデータを本当に小さな50x50ピクセルに並べます。これは、私の推測が真実からそれほど遠くないかもしれないという明確なヒントです。

ラスターデータを空間的にインデックス付けすると、おそらくバウンディングボックスのみがインデックス付けされますが、これは問題の本当の助けにはなりません。


1
タイル張りのものはこのリンクを見る方法のようです。:あなたはまた、次のようにインデックスを追加する必要がありますCREATE INDEX srtm_tiled_rast_gist_idx ON srtm_tiled USING GIST (ST_ConvexHull(rast));ソース
dwurf

4

私が見つけた2つの側面は、PostGISラスター計算を高速化し、ラスターで整数値を使用することと、可能な場合はマルチバンドラスターを使用することでした。この場合、DN値を整数として保存できますか(まだ行われていない場合)。

もう1つの考えは(ここでは関連性があるとは思いませんが)、マルチバンドラスタを使用することです。たとえば、データの月ごとのスライスを表示している場合、各月はラスターレイヤーである可能性があります。その後、レイヤー化されたラスターをクエリすることにより、異なるタイムスライスでポイントの複数の値を取得できます。このアプローチは、個別のラスタをクエリするよりもはるかに高速であることがわかりました。

最後に、データをロードすると、TILE_SIZE-tフラグがあります。使用しているタイルサイズがクエリに適しているかどうかを調べることができます。


マルチバンドラスタは、たとえば時系列を分析するために、同じピクセルの値を同時に数か月間(例に合わせて)クエリする必要がある場合に役立ちます。質問のクエリは、特定の1つの日付のみを取得します。日付が1つのバンドに含まれていた場合、DBMSは他のすべてのバンドも読み取る必要がありますが、それらはクエリへの応答には関係ありません。これはおそらくパフォーマンスを低下させます。
bhell

同意します-おそらく、複数の値が同時に必要な場合にのみ有用であることを強調しませんでした。これを明確にします。
djq

3

データの分布に応じて、date_of_data列のインデックスを作成するだけで非常に優れた高速化を実現できます。

EXPLAIN ANALYZE構文を使用して、インデックスが使用されているかどうかを判断できます。


どんなインデックス?もっと具体的に教えていただけますか?
f.ashouri

単なる標準btreeインデックス:create index tbl_name_date_idx on tbl_name (date_of_data)。多くの異なる日付がある場合、PostGISが処理する必要があるデータの量を大幅に削減します。
dwurf

ありがとうございますが、私のクエリではうまくいきませんでした。
f.ashouri

どうしてうまくいかなかったの?顕著なパフォーマンスの向上、またはその他の問題はありませんか?WHERE句に定期的に表示されるテーブル列がある場合は、常にインデックスを作成することを検討する必要があります。この場合に役立つのは、多数の個別の日付(つまり、大きな値ドメイン)がある場合だけでなく、テーブルに多数のレコードがある場合でもあります。
bhell

クエリはインデックスを使用していますか?の出力を貼り付けることはできますexplain analyze SELECT st_value(rast,(st_GeomFromText('POINT(30.424 -1.66)', 4326))) as val from my_table where date_of_data='2002-01-09'か?
dwurf
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.