В Москве прошла ежегодная техническая конференция PGConf.Russia для ИТ-сообщества по открытой СУБД PostgreSQL. В девятый раз мероприятие организовал российский разработчик систем управления базами данных компания Postgres Professional. Эксперты обсудили направления развития PostgreSQL и его экосистемы, архитектуру, миграцию и эксплуатацию продукта в реальных системах, в частности, на платформе «1С», в геоинформационных системах (GIS). Конференция проводилась в гибридном формате: 450 участников посетили залы бизнес-центра «Рэдиссон Славянская» и более 300 зрителей смотрели онлайн-трансляцию. Наибольший интерес аудитория проявила к докладам и презентациям, в которых рассматривались актуальные задачи разработчиков и примеры решений с использованием PostgreSQL.
О ресурсах и потенциале Postgres для решения бизнес-задач рассказали представители компаний «Авито», VK Cloud Solutions, Ozon, «АльфаСтрахование», «Яндекс.Облако» и др. С обзором новинок PostgreSQL 15 (первая бета-версия доступна сообществу) выступил руководитель образовательных программ Postgres Professional Павел Лузанов. Генеральный директор Postgres Professional Олег Бартунов представил новые фичи SQL/JSON, принятые в очередную версию PostgreSQL, работа над ними продолжалась несколько лет.
«Интерес к PostgreSQL в нашей стране, как и во всем мире, продолжает расти. Поэтому на конференции было много интересных, очень сильных докладов и дискуссий в кулуарах, – отметил заместитель генерального директора Postgres Professional Иван Панченко, – однако повышаются и уровень требований пользователей к СУБД, сложность и масштабы информационных систем, соответственно, становятся более строгими требования к безопасности, надежности и отказоустойчивости. Поэтому очень важно, и мы в Postgres Professional занимаемся этим, вести дальнейшую разработку и улучшение этой СУБД на хорошем современном технологическом уровне, чтобы задачи, которые ставит перед нами время, были решены».
Стоит напомнить, что российская компания Postgres Professional разрабатывает системы управления базами данных. Коллектив из 135 специалистов с опытом создания прикладных решений не только разрабатывает отечественную СУБД Postgres Pro, но и развивает PostgreSQL, заслужив статус признанного эксперта и одной из крупнейших команд проекта в мире.
Расписание «живет» в Postgres
Теме импортозамещения на примере отказа от Oracle в пользу Postgres посвятил свое выступление заместитель директора научного центра – начальник отдела разработки программного обеспечения АО «ВНИИЖТ» Анатолий Афиногенов.
Одна из разработок этого крупнейшего института в сфере железнодорожного транспорта – система построения энергооптимального расписания грузовых поездов «Эльбрус». В текущем году к ней добавилось аналитическое приложение, работающее на всех железных дорогах России – от Калининграда до Хабаровска. На каждой из 16 железных дорог нашей страны ежедневно используется несколько расписаний разных типов и назначений. В одном расписании насчитывается до 2 млн объектов. Объем данных расписания по большому полигону может составлять до 500 Мбайт.
Работу с расписаниями на каждой железной дороге обслуживает группа серверов, при них – база данных Postgres, где расписание «живет» (раньше был Oracle). Среди особенностей можно отметить 50 тыс. строк хранимых процедур pl/pgSQL, крупные, но редкие транзакции. Работа с базой данных осуществляется только через API на основе хранимых процедур (ХП). В нескольких докладах на конференции о ХП упоминалось в неодобрительном контексте. А в выступлении представителя ВНИИЖТ, напротив, отмечались преимущества хранимых процедур для решения отраслевых задач, в частности, возможность взаимодействовать в предметных категориях приложения, на уровне базы данных управлять как способом хранения, так и его нюансами (переименовывать, реорганизовывать таблицы, оперировать двумя версиями процедур при переходе с одной версии на другую).
Логика хранения с помощью API ХП отделена от бизнес-логики приложения. Самое важное, что позволяют делать хранимые процедуры, – реализовать непрерывный механизм диагностики, логирования производительности, а также происходящего внутри сервера, особенно при наличии сложной бизнес-логики. В базе данных примерно 250 таблиц, около 200 хранимых процедур, еженедельно обновляется 40–60% БД.
«Болезни» детские и хронические
Процедура импортозамещения в компании продолжается. При этом опыт ВНИИЖТ в данном направлении может быть полезен другим компаниям и предприятиям. Анатолий Афиногенов представил пошаговую схему перехода с импортного решения. Как показала практика, начинать такую работу следует с разработки общей технологии миграции (зачем, что, когда и как нужно сделать), обучения особенностям работы с PostgreSQL. Далее наступает время разработки инфраструктурных workaround (понять, как действовать в той или иной ситуации), без которых приложение не перенести; переноса таблиц View, Secuences, а также хранимых процедур (не исключено, с их переделкой). Следующие шаги – тестирование, отладка и первоначальная оптимизация производительности приложения БД. Затем на очереди разработка технологии переключения, эксплуатационной документации и инструкций для администраторов; переключение и переходный период параллельной эксплуатации; организация сопровождения приложения и БД, включая мониторинг; разработка и внедрение технологии выполнения обновлений.
Данный перечень можно продолжать. После преодоления «детских болезней» предстоит научиться управлять производительностью PostgreSQL («рано или поздно пользователи пожалуются, что у них что-то начинает медленно работать»), расширить метрики мониторинга, осуществлять диагностику и лечение «хронических болезней». «Мы доросли до тех проблем, когда база работает, но что-то пошло не так, поправили. Когда таких итераций случается три-четыре, это указывает на наличие хронических проблем», – пояснил эксперт.
Сегодня в планах ВНИИЖТ – «переход с PostgreSQL на с PostgrePro». По словам эксперта, для этого созрели все условия.
Аналитическая система «Эльбрус-М» создавалась для прогноза продвижения поездопотоков, оценки инфраструктурных и управляющих решений. Отдельная база спроектирована и построена во времена уже не Oracle с прицелом на зарубежное решение, а PostgreSQL с пониманием того, что хорошего это решение может предоставить. Учтен опыт перехода «Эльбрус» с Oracle на PostgreSQL и двух лет эксплуатации.
Рассказывая об инфраструктурных решениях, эксперт отметил, что для выполнения задач архивирования устаревших данных, техобслуживания БД, диагностики и проактивного мониторинга использовались пакетные задания (JOB) Oracle, которые вызывали процедуры с оператором Commit внутри. Для запуска процедур, реализующих эти функции, было создано Java-приложение jobrunner для Apache Tomcat. К числу его преимуществ (несмотря на более сложную конструкцию) относятся гибкость, унификация с сервером приложений, возможность выполнения не только заданий БД.
Импортозамещение в целом состоялось и приносит пользу. Однако с новыми приложением и типом БД приходят новые вызовы, так что «скучать не приходится». Что касается пожеланий, то в PostgreSQL, по словам эксперта, хотелось бы блокировки строк с заданным таймаутом, ослабления чрезмерной строгости в указании типов для параметров хранимых функций при их вызове, а также усеченной функциональности автономных транзакций хотя бы для записи логов.
Про людей и технологии
Деталями и тонкостями, понятными, на первый взгляд, исключительно узким специалистам, отличалось выступление руководителя подразделения разработки РСУБД с открытым исходным «Яндекс.Облако» Андрея Бородина, посвященное обобщенным деревьям поиска. Тем не менее, в самом начале он обмолвился: «Мой доклад про людей, а не технологии – о том, как взаимодействуют люди, чтобы делать технологии». Из сказанного в ходе выступления можно сделать вывод о роли инициативы и возможностях ее воплощения при должном уровне профессиональных контактов.
Идея GiST – искать частное по общему. Запрос в целом описывает множество объектов, индекс находит объекты, которые пересекаются с областью поиска. В докладе на прошлогодней конференции (про поиск ближайшего соседа в GiST) говорилось, что алгоритм построения обобщенного дерева поиска медленный, и зря он является методом по умолчанию. Обещание исправить ситуацию к следующему собранию представителей сообщества Postgres выполнено силами инициативной группы.
Вначале одному из них захотелось оптимизировать построение картографического индекса для всего мира (занимало около 10 часов на «железе»). Сообща придумали «битовую магию», которая изменяла функцию penalty. Предложили идею сообществу Postgres, которое отнеслось к ней настороженно. Инициатор настоял на своем, и технология используется.
На этапе создания технологии разработчиков волновал вопрос быстрого построения индекса. Добились своего, при этом возникла ситуация, когда индекс в десять раз быстрее строится, но хуже работает. Пользователи пожелали вернуть оперативный поиск. Была создана научная группа по доработке алгоритма построения GiST.
Стали разбираться, почему индекс стал работать медленнее. Выяснилось, что диапазоны поддеревьев пересекающиеся, и для чтения данных в одной и той же точке приходится обходить несколько веток дерева поиска. Занялись решением проблемы и обнаружили неалгоритмическую проблему, которая заключалась в настройке индекса fillfactor.
Новый способ построения индекса будет доступен в Postgres 15, по умолчанию включен в PostGIS 3.3. Отвечая на вопрос о развитии ядра для Postgres, эксперт сообщил, что в сообществе витает идея создания специализированного индекса. В настоящее время обсуждаются детали возможного проекта. Будет ли он реализован, покажет время.
