[Перевод] PostGIS 3.2 — обновленный и улучшенный
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-команд, пользователей и роли.
Если интересно — записывайтесь.
