Как ускорить запросы к растровым базам данных?

У меня есть растровая база данных в postgresql / postgis с этими столбцами:

(ID, раст, data_of_data) .

«Раст» - это столбец с растровыми файлами в формате WKT. Пример запроса для поиска значения DN точки в системе WGS84 (30.424, -1.66) и для 2002-01-09 выглядит следующим образом:

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

Есть ли способ (например, пространственный индекс) для ускорения таких запросов?

Это захватывающий вопрос! Насколько большой растр вы хотите запросить? WKTRaster хранится в базе данных как BLOB . Чтобы найти значение в конкретной точке, из известных (x_0, y_0) угловых координат строки / столбцов индексы (i, j) вычисляются с использованием (dx, dy) шагов и поворота. С известным (i, j), функция ST_Value () может получить доступ к фактическим данным с правильным байтовым смещением.

Это означает, что при ответе на запрос к точке БД должна в среднем прочитать хотя бы половину большого двоичного объекта данных (в зависимости от реализации она может фактически всегда считывать все данные). Поэтому я бы предположил, что производительность WKTRaster страдает, когда большие двоичные объекты данных становятся слишком большими. Черепица набора данных должна ускорить запросы. Посмотрите, как обрабатываются данные SRTM (поступающие в виде фрагментов размером 6000x6000 пикселей) в этом руководстве . Они на самом деле разбивают данные на очень маленькие 50x50 пикселей, что является явным намеком на то, что мои догадки могут быть не слишком далеки от истины.

Пространственная индексация растровых данных, вероятно, будет просто индексировать ограничивающий прямоугольник, что не поможет в вашей проблеме.

Два аспекта, которые я обнаружил, ускорили мои расчеты растра PostGIS: использование целочисленных значений в растре и использование многоканальных растров, где это возможно. В этом случае, может ли значение DN быть сохранено как целые числа, если это еще не сделано?

Другая мысль (и я не уверен, что это уместно здесь) заключается в использовании многоканальных растров. Например, если вы просматриваете ежемесячные фрагменты данных, каждый месяц может быть растровым слоем. Затем вы можете получить несколько значений точки на разных временных срезах, запросив многоуровневый растр. Я обнаружил, что такой подход намного быстрее, чем запросы к отдельным растрам.

Наконец, когда вы загружаете свои данные, появляется -tфлаг для TILE_SIZE . Вы можете выяснить, подходит ли используемый вами размер плитки для вашего запроса.

В зависимости от распределения ваших данных, вы можете получить очень хорошие ускорения, просто проиндексировав date_of_dataстолбец.

Вы можете использовать синтаксис EXPLAIN ANALYZE, чтобы выяснить, используются ли ваши индексы или нет.