Як прискорити запити растрових баз даних?

У мене є растрова база даних у postgresql / postgis з цими стовпцями:

(ID, rast, data_of_data) .

'rast' - це стовпець, що містить растрові файли у форматі 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'

Чи існує метод (наприклад, просторовий індекс) для прискорення таких запитів?

— f.ashouri
джерело

Можливо, ви могли б нам допомогти, надавши ще детальну інформацію: Скільки записів є у my_table? Наскільки великі дані в растровій колонці? Скільки чітких дат у вас у date_of_data?

— dwurf

Додайте до цього: що таке SRID стовпця "rast"?

— dwurf

Відповіді:

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

Це означає, що БД повинен читати в середньому принаймні половину блоку даних, відповідаючи на запит на точку (залежно від реалізації, вона може фактично читати всі дані в усі часи). Тому я б здогадувався, що продуктивність WKTRaster погіршується, коли BLOB даних стає занадто великим. Облицювання набору даних має пришвидшити запити. Подивіться, як у цьому підручнику обробляються дані SRTM (надходять у шматки 6000x6000 пікселів) . Вони насправді розбивають дані на дійсно невеликі 50х50 пікселів, що є явним натяком на те, що мої здогадки можуть бути не надто далеко від правди.

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

— bhell
джерело

Здається, що це стосується плитки - дивіться за цим посиланням . Вам також потрібно буде додати такий індекс, як цей: CREATE INDEX srtm_tiled_rast_gist_idx ON srtm_tiled USING GIST (ST_ConvexHull(rast));( джерело )

— dwurf

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

Інша думка (і я не впевнений, що це доречно тут) - використовувати багатодіапазонні растри. Наприклад, якщо ви переглядаєте щомісячні фрагменти даних, кожен місяць може бути шаром растру. Потім ви можете отримати декілька значень точки в різний час відрізки, запитуючи шаруватий растр. Я знайшов цей підхід набагато швидшим, ніж запит окремих растрових.

Нарешті, коли ви завантажуєте свої дані, з'являється -tпрапор для TILE_SIZE . Ви можете дослідити, чи добре працює розмір плитки для вашого запиту.

— djq
джерело

Багатополосні растри, ймовірно, допоможуть, якщо вам потрібно запитувати одне і те ж значення пікселя протягом декількох місяців одночасно (дотримуватися вашого прикладу), наприклад, аналізувати часові ряди. Запит у питанні отримує лише одну конкретну дату. Якщо дата містилася в одній смузі, СУБД також повинна була б прочитати всі інші діапазони, хоча вони не представляють інтересу для відповіді на запит. Це, мабуть, погіршить ефективність роботи.

— bhell

Я згоден - можливо, я не підкреслював, що це корисно лише тоді, коли одночасно потрібно кілька значень; Я уточню це.

— djq

Залежно від розповсюдження ваших даних, ви можете отримати дуже хороші прискорення, просто проіндексувавши date_of_dataстовпець.

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

— борщівник
джерело

який індекс? ви могли б бути більш конкретними?

— f.ashouri

Просто стандартний індекс ВТКЕЯ: 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