Raster veritabanları için sorgular nasıl hızlandırılır?

Postgresql / postgis bu sütunlarla raster veritabanı var:

(ID, rast, veri_veri_tarihi) .

'rast' , WKT biçiminde raster dosyaları olan sütundur. WGS84 sisteminde (30.424, -1.66) ve 2002-01-09'da bir noktanın DN değerini bulmak için örnek bir sorgu şudur:

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

Bu tür sorguları hızlandırmak için bir yöntem (örn. Mekansal indeks) var mı?

— f.ashouri
kaynak

Belki daha fazla ayrıntı sağlayarak bize yardımcı olabilirsiniz: my_table içinde kaç kayıt var? Raster sütunundaki veriler ne kadar büyük? Date_of_data'da kaç farklı tarihiniz var?

— dwurf

Buna ekleyin: rast sütununun SRID'si nedir?

— dwurf

Yanıtlar:

Bu heyecan verici bir soru! Sorgulamak istediğiniz tarama ne kadar büyük? WKTRaster veritabanında BLOB olarak depolanır . Belirli bir noktadaki değeri bulmak için, bilinen bir (x_0, y_0) köşe koordinat satır / sütun indekslerinden (i, j) (dx, dy) adımlar ve döndürme kullanılarak hesaplanır. Bilinen (i, j) ile ST_Value () işlevi, gerçek verilere doğru bayt uzaklığından erişebilir.

Bu, DB'nin bir nokta için bir sorguyu cevaplarken veri blobunun ortalama en az yarısını okuması gerektiği anlamına gelir (uygulamaya bağlı olarak tüm verileri her zaman okuyabilir). Bu nedenle veri BLOB'ları çok büyük olduğunda WKTRaster performansının düştüğünü tahmin ediyorum . Veri kümesinin döşenmesi sorguları hızlandırmalıdır. Bu eğitimde SRTM verilerinin (6000x6000 piksel yığınlarında gelir) nasıl ele alındığına bir göz atın . Aslında verileri gerçekten küçük 50x50 piksellere döşiyorlar, bu da tahminlerimin gerçeklerden çok uzakta olmayabileceği konusunda net bir ipucu.

Raster verilerinin uzamsal olarak endekslenmesi, muhtemelen sınırlama kutusunu endeksleyecektir, bu da probleminiz için gerçek bir yardım değildir.

— bhell
kaynak

Döşeme işi gitmek için bir yol gibi görünüyor - bu bağlantıya bakın . Ayrıca böyle bir dizin eklemeniz gerekir: CREATE INDEX srtm_tiled_rast_gist_idx ON srtm_tiled USING GIST (ST_ConvexHull(rast));( kaynak )

— dwurf

PostGIS raster hesaplamalarımı hızlandırdığımı bulduğum iki özellik, rasterde tamsayı değerleri ve mümkün olduğunda çok bantlı rasterler kullanıyordu. Bu durumda, DN değeri henüz yapılmadıysa tamsayı olarak saklanabilir mi?

Diğer düşünce (ve burada alakalı olduğundan emin değilim) çok bantlı rasterler kullanmaktır. Örneğin, aylık veri dilimlerine bakıyorsanız, her ay bir raster katmanı olabilir. Ardından, katmanlı raster sorgulayarak bir noktanın birden çok değerini farklı zaman dilimlerinde alabilirsiniz. Bu yaklaşımı, ayrı rasterleri sorgulamaktan çok daha hızlı buldum.

Son olarak, verilerinizi yüklediğinizde TILE_SIZE için bir -tbayrak bulunur . Kullandığınız döşeme boyutunun sorgunuz için iyi çalışıp çalışmadığını keşfedebilirsiniz.

— DJQ
kaynak

Örneğin, zaman serilerini analiz etmek için aynı pikselin değerini birkaç ay boyunca aynı anda sorgulamanız gerekirse (örneğin örneğinize bağlı kalmak için) çok bantlı rasterler yardımcı olacaktır . Sorudaki sorgu yalnızca belirli bir tarihi alır. Tarih bir bantta yer alıyorsa, sorguyu yanıtlamakla ilgilenmese de DBMS'nin diğer tüm bantları da okuması gerekir. Bu muhtemelen performansı düşürebilir.

— 12'de

Kabul ediyorum - belki de sadece aynı anda birkaç değere ihtiyaç duyulduğunda faydalı olduğunu vurgulamadım; Bunu açıklığa kavuşturacağım.

— djq

Verilerinizin dağıtımına bağlı olarak, yalnızca date_of_datasütunu dizine ekleyerek çok iyi hızlanmalar elde edebilirsiniz .

Dizinlerinizin kullanılıp kullanılmadığını anlamak için EXPLAIN ANALYZE sözdizimini kullanabilirsiniz.

— dwurf
kaynak

ne tür bir endeks? daha açık olabilir misiniz?

— f.ashouri

Sadece bir standart btree endeksi: create index tbl_name_date_idx on tbl_name (date_of_data). Çok farklı tarihleriniz varsa, bu PostGIS'in işlemek zorunda olduğu veri miktarını büyük ölçüde azaltacaktır.

— dwurf

Teşekkür ederim, ama benim sorgu için işe yaramadı.

— f.ashouri

Nasıl çalışmadı? Belirgin bir performans kazancı veya başka sorun yok mu? Düzenli olarak bir WHEREyan tümcede görünen bir tablo sütununuz varsa , bunu her zaman dizine eklemeyi düşünmelisiniz. Bu durumda yalnızca çok sayıda farklı tarihiniz varsa (yani büyük bir değer alanınız) değil, aynı zamanda tabloda çok sayıda kaydınız varsa da yardımcı olacaktır.

— 7'de 57

Sorgu dizini kullanıyor mu? Çıktısını yapıştırabilir misiniz

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