title

text

Алексей Фадеев
Алексей Фадеев Sibedge Старший разработчик .NET, евангелист Postgres.
: декабря
90 мин

Plv8 Framework: разработка на plv8 в IDE, с ES6, отладкой, автотестами и деплоем

Многие разработчики прикладного ПО не любят выносить логику на сторону БД (в функции) из-за отсутствия удобных средств разработки, особенно командной. С plv8 ситуация осложняется тем, что функция содержит симбиоз кода SQL и JavaScript, популярные IDE такое не поддерживают. На этом мастер классе я представлю свою разработку "Plv8 Framework", позволяющую существенно облегчить создание кода на plv8.

Суть в следующем: тот же JS-код, который будет выполняться на стороне БД, можно запустить локально, прямо на машине разработчика, с помощью node.js, который работает на основе того же интерпретатора v8. Спецфункция plv8.execute подменяется на функцию из npm-библиотеки pg-native, т.е. происходит обращение к внешней СУБД. Я продемонстрирую авторский набор средств, позволяющий:
- писать js-код в вашей любимой IDE с подсветкой синтаксиса;
- отлаживать код в реальном времени (с breakpoint, watch и т.д.);
- писать автотесты (unit-тесты), с вариантами: постгрес, SQLite, моки;
- выполнять deploy кода в СУБД;
- использовать дополнительные npm-пакеты (проблема в том, что весь код функции на plv8 должен находиться в теле этой функции, т.е. в одном файле).

Инструмент можно использовать независимо от того, на чём вы разрабатываете бэкенд. Но особенную гибкость он придаёт, если вы используете языки со статической типизацией (java, C# и т.д.). Например для задач, где бэкенд является промежуточным слоем между фронтендом и СУБД, логика (или её часть) может быть вынесена в plv8/js с динамической типизацией, что может весьма облегчить процесс разработки.

Помимо возможности разрабатывать новые функции на plv8, фреймворк предоставляет набор готовых функций для выполнения CRUD-операций. Функции универсальные, не привязаны к структуре конкретной БД и могут работать на любых проектах. Их использование поможет сократить объём бэкенд разработки, на некоторых проектах - значительно.

Пожалуй, самое сложное с plv8 - установить это расширение. Но у меня хорошая новость: мои коллеги помогли подготовить докер-файлы и докер-образы для PostgreSQL версии 13 с уже установленным plv8! Теперь начать разработку на plv8 просто: нужно лишь развернуть контейнер одной командой.
Докер-файл: PostgreSQL 13 + plv8 v2.13.15
Демо-проект для участия в мастер-классе
Так же для мастер-класса пригодятся:
Node.js (желательно LTS)
IDE для js (например, бесплатная Visual Studio Code)
GraphQL Playground

Слайды

Fadeev-plv8framework.pptx

Видео

Видео доступно участникам мероприятия, выполнившим вход в личный кабинет

Другие доклады

  • Пётр Девянин
    Пётр Девянин ГК Astra Linux Научный руководитель
    45 мин

    Обеспечение доверия к системному ПО на примере ОС Astra Linux

    Разработка безопасного системного ПО (например, ОС или СУБД), достижение доверия к нему – сложная научно-техническая задача. В докладе будет показано, как ее удается решать для сертифицированной по высшим классам защиты ОС Astra Linux. При этом будут раскрыты основные направления этой деятельности, начиная с участия в формировании профильных национальных стандартов, далее разрабатывая и верифицируя формальную модель управления доступом, как основу составляющего поверхность атаки собственного механизма защиты ОС, затем применяя методы и технологии статического и динамического анализа программного кода, и завершая сбором и аналитической обработкой данных, получаемых в ходе анализа программного кода ОС, с исправлением найденных в нем ошибок в рамках практики непрерывной интеграции.

  • Олег Бартунов
    Олег Бартунов Postgres Professional генеральный директор
    Никита Глухов
    Никита Глухов Postgres Professional Старший разработчик
    45 мин

    Элегантный поиск ближайших соседей в PostgreSQL

    С необходимостью эффективного поиска ближайших соседей можно встретиться в разных задачах, например, поиск ближайших к заданной точке объектов на карте. Задача, на непрограммистский взгляд кажущаяся тривиальной (действительно, человек довольно легко справляется с ней глядя на карту) , на самом деле не имеет общего и доступного решения, что приводит к головной боли разработчиков, которые придумывают ad hoc решения (вставляют костыли). Эти решения, обычно некрасивые, портят настроение творческой натуры программиста, которому требуется посещение пивной, чтобы пережить когнитивный диссонанс :)

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

    В действительности, класс задач, в которых требуется эффективный поиск ближайших соседей, гораздо шире задач пространственного поиска, например, задачи классификации, задачи поиска очепяток, кластеризации, дедупликации данных. Все они могут сильно выиграть от поддержки эффективного поиска ближайших соседей в СУБД, которые являются в настоящее время де-факто стандартом хранения данных. Эффективный поиск означает быстрый, конкурентный, масштабируемый поиск и поддержку различных типов данных (возможно, нестандартных), что и было реализовано 11 лет назад в PostgreSQL. Я расскажу про его реализацию, современное состояние и примеры использования.

  • Сергей Новиков
    Сергей Новиков ЕДИНЫЙ ЦУПИС Lead DBA
    90 мин

    Внедрение партицирования без простоя

    Встроенный механизм партицирования в PostgreSQL активно развивается уже несколько лет, но пока ещё нет волшебной кнопки для превращения обычной таблицы в партицированную. Я расскажу, как внедрить партицирование в production-системе без дополнительного простоя, как правильно подготовить таблицу и приложения, какие ошибки подстерегают DBA. Также будут подробно рассмотрены различные техники переноса данных между партициями, их плюсы, минусы и ограничения.

  • Федор Сигаев
    Федор Сигаев Postgres Professional технический директор, ведущий разработчик PostgreSQL
    22 мин

    Зачем еще 64-битные значения?

    Когда PostgreSQL только появлялся, значения идентификатора транзакции были выбраны 32х-битными. В то время это казалось запредельным числом - кто в здравом уме будет проводить 4 миллиарда транзакций? Но развитие техники привело к тому, что появились инстансы, где транзакции подбирались к этому пределу. Сообщество разработчиков ответило на это возможностью "оборота" счетчика транзакций (известный как wraparound). Но технический прогресс и рост количества данных поставили PostgreSQL перед новыми вызовами. В докладе я попытаюсь рассказать об этих вызовах, о том, как их можно преодолеть с помощью повышения разрядности счетчика, к каким следствиям это приведет и почему это надо делать сейчас, и почему это не было сделано раньше.