Узкие места PostgreSQL

Хорошо, когда база работает предсказуемо. Если сервер не справляется с нагрузкой, то только знай добавляй процессорные ядра, терабайты оперативной памяти и миллионы IOPS'ов – всё станет хорошо. Гораздо неприятнее, когда у сервера куча свободных ресурсов, но база данных всё равно тормозит. И особенно обидно, когда при нагрузочном тестировании всё работало как часы, а при реальной нагрузке такого же объёма – встаёт колом.

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

CTE запросы как основа бизнес-логики

Рассмотрены особенности разработки и некоторые варианты реализации бизнес-логики высоконагруженных web-приложений на базе хранимых процедур в парадигме широкого применения Common Table Expression запросов.

ORM: как писать запросы и не сводить с ума СУБД

Многие специалисты, обслуживающие СУБД не любят эти три буквы - 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 могут быть отличия в некоторых тонкостях, но основные принципы те же, поэтому доклад будет полезен разработчикам, использующим различные технологии.

Битемпоральность: отслеживание воспроизводимых изменений в PostgreSQL с помощью типа данных RANGE

Итак, вы наконец создали модель базы данных для вашего приложения и наполнили ее текущими данными. Каким образом обеспечить их актуальность? Хотя команда INSERT может быть все еще прозрачной, команды UPDATE и DELETE перезапишут ваши предыдущие данные, так что вы не сможете их воспроизвести. Клонирование целиком огромного контента при каждом небольшом обновлении - не вариант. Для богатых и сложных данных о сотнях тысяч электрогенераторов в Германии и по всему миру я построил базу данных, используя тип данных range, недавно появившийся в PostgreSQL. Это позволило мне добавлять, обновлять и удалять данные, при том обладая полным доступом к состоянию базы данных в любой исторический момент. Во время выступления я представлю очень упрощенную версию базы данных, чтобы аудитория смогла тут же применить знания на практике. Также я покожу несколько хитрых приемов в работе с Python и Psycopg2, которые позволят всей команде подготавливать, просматривать и развертывать все изменения в базе данных без конфликтов слияния. И подкину несколько идей о том, как можно эти данные эффективно извлекать.