SQL данными

Почти каждое бизнесс приложение является в значительной степени генератором запросов к базе данных. Как можно легко строить запросы и делать их композицию? В этом докладе я расскажу про интересный подход из мира clojure, в котором sql записывается "данными" (data dsl) и какие возможности это открывает - от композиции и безопасного sql до макросов и анализа запросов.

Бесшовная оптимизация запросов PostgreSQL, версия 2.0

Существует два способа анализировать SQL-запросы:

1. На макроуровне: в этом случае мы анализируем рабочую нагрузку как единое целое (есть три основных подхода: использование метрик из pg_stat_statements или аналогичного модуля, анализ логов с помощью pgBadger или другого похожего решения и запрос выборки в представлении pg_stat_activity).

2. На микроуровне: в этом случае мы погружаемся в детали исполнения одного конкретного запроса (тут главную роль играет команда EXPLAIN).

Между этими двумя подходами есть немало "белых пятен", которые обнаруживаются с ростом нагрузки. Главные проблемы:

• Нужно переключаться между макро- и микроуровнем без больших накладных расходов.
• Требуется надёжная проверка гипотез относительно возможных оптимизаций.
• Есть необходимость минимизации рисков при развёртывании новой функциональности.

Чтобы справляться с этими задачами в растущем проекте, требуется продвинутый опыт в качестве администратора баз данных, и – иногда – интуиция. Также могут помочь новые инструменты, которые (к счастью для нас!) не так давно начали появляться.

В рамках данного мастер-класса мы разберёмся, как можно настроить процесс беспроблемной и бесшовной оптимизации SQL-запросов в вашей организации: а) какие инструменты следует выбрать в вашем конкретном случае? б) как эффективно заполнить вышеупомянутые пробелы в сфере анализа запросов?

GPU-версия PostGIS и индекса GiST

В рамках данного доклада мы представим GPU-версию PostGIS и индекса GiST, которую мы разработали в качестве новой функциональности PG-Strom.

Сегодня наши устройства (например, мобильные телефоны) динамически генерируют геолокационные данные. Это часто используют для маркетинга на основе местоположения устройства, доставки push-уведомлений, оповещения о чрезвычайных ситуациях, и так далее. Люди часто используют технологию GIS для получения данных о пользователях, находящихся в данный момент в данном месте. Даже если определения географических областей представляют собой сложные многоугольники, функции PostGIS могут генерировать правильные пересечения, однако это часто требует интенсивных вычислительных нагрузок. Графический процессор (GPU) был разработан для массовых параллельных вычислений с тысячами ядер на чип и более. Мы разработали расширение PG-Strom для частичного выполнения SQL-запросов на устройствах GPU. В новом релизе PG-Strom v3.0 будет добавлена поддержка для нескольких функций PostGIS и GiST-индексов для выполнения ресурсоёмких вычислений с обработкой геолокационных данных.

В рамках этого доклада мы расскажем о создании этой технологии, её использовании, реализации и представим результаты сравнительного тестирования для GPU-версии PostGIS и GiST-индекса.

Constraints или о том, как попытаться спокойно жить

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