PostGIS 3.2 зарелизили в самый последний момент прошлого месяца, чтобы он успел увидеть свет в 2021 году. Эта новая версия PostGIS также поддерживает GEOS последней версии 3.10, благодаря чему мы получили несколько новых фич.

Растровые алгоритмы

Расширение postgis_raster использует растровую библиотеку GDAL для таких задач, как векторизация растров и растеризация векторов (о да!). В этом релизе также были представлены еще несколько крутых алгоритмов GDAL.

  • Новая функция ST_InterpolateRaster позволяет интерполировать наборы измерений в опорных точках в непрерывную растровую поверхность.

  • Эти непрерывные растровые поверхности можно передать в новую функцию ST_Contour для расчета изолиний поверхности.

  • Те же растровые поверхности можно использовать в качестве входных данных для добавления пространственных атрибутов к 3D- и 4D-векторным объектам с помощью ST_SetZ и ST_SetM.

Доступ к растрам в облаке

Один из наиболее интересных трендов в области геопространственных данных за последние пять лет — это увеличение консенсуса относительно хранения в облаке больших геопространственных данных, а именно в хранилищах объектов (таких как AWS S3, Google Cloud Storage или Azure Blob Storage). Привычное расположение основных архивов необработанных данных становится общедоступным, а не как раньше «хранится на USB-накопителе, который лежит в рабочем столе Джо» и, таким образом, будет доступно для интеграции в цепочки анализа.

С помощью расширения postgis_raster с растровыми данными в облаке можно выполнять растровый анализ без необходимости импорта исходных растровых данных. Вы даже можете делать это в (правильно настроенном) сервисе облачной базы данных, таком как Crunchy Bridge.

Первые статьи нашего блога, посвященные теме анализа облачных растров, были конечно по-своему интересны, но они показали важное ограничение в «облачном растре из базы данных»: не было эффективного способа доступа к приватным объектам.

С PostGIS 3.2 теперь можно предоставлять учетные данные для облачных хранилищ объектов, поэтому появилась возможность выполнять удаленный анализ своих приватных растровых коллекций.

Более быстрая/улучшенная валидность

Последние пару лет мы работали в нескольких направлениях разработки — это создание механизма вычислительной геометрии, который использует PostGIS, и более быстрой и современной библиотеки GEOS.

В этом релизном цикле были модернизированы две популярные пользовательские функции, ST_IsValid и ST_MakeValid.

  • ST_IsValid была переписана в целях повышения ее эффективности и стала примерно на 30% быстрее в зависимости от входных данных.

  • Добавлена ​​новая реализация ST_MakeValid, которая в два раза быстрее и лучше учитывает структурный состав входных данных. Результатом является (в зависимости от вашей интерпретации) более “обоснованная” коррекция ошибок валидности.

(Опциональное) Более быстрое построение индекса GIST

В этом году студент Google Summer of Code взял амбициозный проект PostGIS: использование новых хуков с “поддержкой сортировки” GIST для PostgreSQL 14 для сокращения времени построения индекса.

В результате этой работы время построения индекса GIST существенно сократилось — в 2-5 раз.

Однако есть один подвох: построенные таким образом индексы, в отличие от дефолтных инкрементальных индексов, не так хорошо структурированы. Это может привести к снижению производительности запросов от нуля до 30% и более.

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

Если вы хотите включить более быстрое построение индекса (за счет производительности запросов), вы можете добавить функцию поддержки сортировки в дефолтный класс оператора перед построением индексов.

ALTER OPERATOR FAMILY gist_geometry_ops_2d USING gist
  ADD FUNCTION 11 (geometry)
  geometry_gist_sortsupport_2d (internal);

Вы можете в любой момент убрать поддержку сортировки из класса оператора.

ALTER OPERATOR FAMILY gist_geometry_ops_2d using gist
  DROP FUNCTION 11 (geometry);

Но помните, что любые индексы, которые вы создали с поддержкой сортировки, даже после отключения поддержки сортировки будут иметь неоптимальную структуру.

Формат FlatGeoBuf

В категории «а вдруг это станет популярным» у нас поддержка формата FlatGeoBuf. Как и в случае с другими форматами MVT и GeoBuf, поддерживаемыми PostGIS, функция ST_AsFlatGeoBuf принимает строку или набор строк и выводит один бинарный bytea, который шифрует все данные в этих строках.

Формат FlatGeoBuf — это векторный формат, основанный на том же принципе, что и оптимизированный GeoTiff: формат, в котором объекты, находящиеся рядом друг с другом в пространстве, находятся рядом друг с другом и в отформатированном потоке байтов. Это позволяет извлекать пространственные окна данных за относительно небольшое количество чтений. Суть «облачной оптимизации» заключается в сокращении количества доступов, необходимых для обслуживания типичных юзкейсов.

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

И многое другое

В любом сводном отчете об изменениях в релизе будет отсутствовать огромное количество нишевых улучшений и исправлений, поэтому истинным ценителям следует просмотреть бэклог закрытых тикетов и файл NEWS этого релиза.


Материал подготовлен для будущих студентов нового потока курса «PostgreSQL для администраторов баз данных и разработчиков».

Всех желающих приглашаем на бесплатное demo-занятие «DDL: Создание, изменение и удаление объектов в PostgreSQL». На этом занятии мы обсудим:

- объекты в PostgreSQL, объекты базы данных и общие объекты кластера;
- использование команд CREATE, ALTER, DROP;
- права, необходимые для выполнения DML-команд, пользователей и роли.

Если интересно — записывайтесь.

Комментарии (0)