PgConf.Russia 2019

Shared_buffers = 25% – это много или мало? Или в самый раз? Как понять, подходит ли эта – довольно устаревшая – рекомендация в вашем конкретном случае?

Пришло время подойти к вопросу подбора параметров postgresql.conf "по-взрослому". Не с помощью слепых "автотюнеров" или устаревших советов из статей и блогов, а на основе:

1. строго выверенных экспериментов на БД, производимых автоматизированно, в больших количествах и в условиях, максимально приближенных к "боевым",
2. глубокого понимания особенностей работы СУБД и ОС.

Используя Nancy CLI (https://gitlab.com/postgres.ai/nancy), мы рассмотрим конкретный пример – пресловутые shared_buffers – в разных ситуациях, в разных проектах и попробуем разобраться, как же подобрать оптимальную настройку для нашей инфраструктуры, БД и нагрузки.

В ходе доклада мы представим MobilityDB - расширение PostgreSQL, которое раздвигает границы системы типов в PostgreSQL и PostGIS на абстрактные данные для адекватного представления изменяющихся данных об объектах. Эти типы данных могут представлять эволюцию во времени значений некоторого типа элементов, называемого базовым темпоральным типом. Например, темпоральный целочисленный тип данных может использоваться для демонстрации изменения во времени количества сотрудников департамента. В данном случае базовым типом данных будет целочисленный или темпоральный целочисленный. Аналогично, темпоральный тип данных с плавающей точкой может использоваться для записи изменения во времени температуры в помещении или местоположения автомобиля по GPS-координатам. Темпоральные типы данных оказываются полезны, поскольку для работы многих приложений, например, мобильных, принципиально необходимо обрабатывать изменяющиеся во времени величины.

В расширении MobilityDB темпоральные типы данных основаны на булевых, целочисленных, с плавающей точкой и текстовых типах данных от PostgreSQL, а также на геометрических и географических типах данных от PostGIS (ограниченных размерностью 2D или 3D). MobilityDB соответствует действующим стандартам по перемещаемым объектам OGC http://www.opengeospatial.org/standards/movingfeatures, в частности, OGC Moving Features Access, в котором определены операции, применимые к изменяющимся во времени геометриям.

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

• Пожизненные функции и операторы: операторы над базовыми типами (такие как арифметические операции над целыми числами и числами с плавающей точкой, пространственные отношения и расстояния для геометрий) интуитивно обобщаются на случай изменяющихся во времени значений. Пространственно-темпоральные функции в MobilityDB обобщают пространственные функции PostGIS как для геометрических, так и для географических типов данных, к примеру для "ST_Intersection". На базовом уровне, MobilityDB принимает в расчет аспект темпоральности и делегирует обработку пространственных данных в PostGIS.
• Темпоральные функции и операторы обрабатывают изменяющиеся во времени размерности величины, которая может представлять собой единичное значение, диапазон значений, массив значений или массив диапазонов. Примерами являются функции периодов, которые ограничивают темпоральный тип заданным массивом временных диапазонов, а также функции продолжительности, которые извлекают время определения значения величины.
• Пространственно-темпоральные функции и операторы - в эту категорию попадают все остальные функции. Примеры: speed(tgeompoint/tgeogpoint), azimuth(tgeompoint/tgeogpoint), maxValue(tfloat/tint), взвешенное по времени среднее twAvg(tfloat) и т.д.

Как GiST, так и SP-GiST индексы были расширены для поддержки темпоральных типов данных. Индекс GiST реализует R-дерево для темпоральных численно-буквенных типов данных, а TB-дерево - для темпоральных координат. Индекс SP-GiST реализует Quad-дерево для темпоральных численно-буквенных типов данных, а Oct-дерево - для темпоральных координат. Подход, использованный в MobilityDB при разработке SP-GIST индекса, позволил нам добавить индексы SP-GIST для двумерных, трехмерных и n-мерных геометрий в PostGIS.

Доступны два типа числовых функций аггрегирования. В дополнение к традиционным функциям min, max, count, sum, and avg, теперь есть и их оконные версии (также известные как кумулятивные). Для заданного промежутка времени w, оконная аггрегативная функция вычисляет значение функции в момент времени t, принимая в расчет значения на интервале [t − w, t]. В противоположность стандартной аггрегации, темпоральная аггрегация может возвращать результат большего размера, чем входящие данные. По этой причине темпоральные функции аггрегирования были подвергнуты жесткой оптимизации, чтобы обеспечить их эффективную работу.

В MobilityDB также есть предварительная реализация функций сбора статистики и селективности для темпоральных типов данных.

С точки зрения размера, расширение состоит из 67k строк кода на C, 19k строк SQL кода и 67k строк модульных тестов SQL. В нем определены 40 типов, 2300 функций и 1350 операторов.

В ходе доклада будет проиллюстрирована пространственно-темпоральная концепция и модель данных для темпорального типа. Кратко остановимся на основных компонентах MobilityDB: индексах, аггрегировании, функциях и операторах, а также SQL-интерфейсе. Рассказ будет дополнен примерами запросов и практических случаев использования. Также будет рассказано о текущем статусе проекта MobilityDB и планируемых разработках.

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

Для того, чтобы решить эту проблему, я разработал инструмент под названием pg_plan_advsr - это расширение для PostgreSQL, которое исправляет ошибки оценки путем неоднократного возвращения в планировщик информации, собранной в ходе исполнения запроса.

Расширение содержит три фичи:

1. Автоматическая оптимизация плана запроса за счет неоднократного возвращения информации о ходе выполнения запроса в планировщик.
2. Сохранение всех выработанных при оптимизации планов запросов в таблицу истории.
3. Создание и сохранение хинтов оптимизатора с тем, чтобы иметь возможность воспроизвести выработанные планы исполнения запросов в процессе настройки.

Я верифицировал эффективность pg_plan_advsr путем запуска join order benchmark (JOB) на PG 10.4, в ходе чего наблюдалось сокращение времени исполнения запроса до 50% от первоначального. Таким образом, расширение будет полезно пользователям, который хотят настроить планировщик для OLAP и пакетной обработки данных.

В ходе презентации я расскажу о следующие моментах:

• Принципы построения и архитектура pg_plan_advsr.
• Подробная информация о результатах тестирования JOB.
• Направления улучшений в будущем.
• Совместное использование расширений aqo и pg_plan_advsr together (экспериментальное).

Многие специалисты, обслуживающие СУБД не любят эти три буквы - ORM, потому что не раз видели сгенерированные многоэтажные запросы для простейших операций. Однако, практика показывает, что источник проблемы - не ORM, а разработчики, не умеющие ими пользоваться. В этом докладе я расскажу основные принципы, как писать код для ORM, генерирующий «хорошие» запросы, а также покажу «плохие» примеры кода, и что из них получается на выходе. Основные идеи – при написании кода мыслить в SQL, научиться заранее видеть, какой запрос будет сгенерирован. Но даже обретя такой навык нужно всегда проверять выходной SQL для сложных запросов. Приведу конкретный пример, когда незначительное изменение в ORM-логике меняет объём выходного SQL в десятки(!) раз. Расскажу о дополнительных инструментах и хитростях. А именно – отключение трекинга, конструкция Include, разный синтаксис для JOIN, как получить больше данных за меньшее число запросов, как эффективно писать запросы с группировкой, и зачем нужны проекции. Не обойду стороной и случаи, когда эффективно решить задачу средствами ORM не получается (например, запросы с рекурсией). Кроме SELECT-запросов немного расскажу о средствах Batch-Update/Delete, позволяющих обновлять и удалять данные средствами ORM без загрузки на клиент. Несколько слов будет и о вставке – как заставить ORM быстро вставлять большие объёмы данных через Multi-Insert и COPY. Будет упомянуто и о поддержке в ORM специфичных для PostgreSQL типов данных – массивов, hstore и jsonb. Может возникнуть вопрос – а есть ли вообще смысл использовать ORM, раз нужно столькому научиться. Преимущества их использования есть, и об этом тоже будет сказано. Все примеры будут на технологии Entity Framework для платформ .Net Core и .Net Framework на языке C#. Для Hibernate/NHibernate могут быть отличия в некоторых тонкостях, но основные принципы те же, поэтому доклад будет полезен разработчикам, использующим различные технологии.