PgConf.Russia 2019
PGConf.Russia – международная техническая конференция по открытой СУБД PostgreSQL, ежегодно собирающая более 500 разработчиков, администраторов баз данных и IT-менеджеров для обмена опытом и профессионального общения. В программе – мастер-классы ведущих мировых экспертов, доклады в три тематических потока, примеры лучшего опыта и разбор ошибок, гостиная разработчиков и блиц-доклады из зала.
Темы встречи
- PostgreSQL на переднем крае: большие данные, интернет вещей, блокчейн
- новое в PostgreSQL и вокруг: развитие PostgreSQL и его экосистемы
- PostgreSQL в реальных системах: архитектура, миграция, эксплуатация
- Использование PostgreSQL в платформе 1С
- PostgreSQL в геоинформационных системах (GIS)
Доклады
Архив докладов
-
Андрей Фефелов Mastery.pro Технический директорДля одного из наших проектов понадобилось решать задачу построения отказоустойчивой БД, желательно к тому же географический распределенной.
Первое на что мы посмотрели - это облачные решения от большой тройки, однако, стоимость их эксплуатации превзошла все наши скромные ожидания. К тому же у нас есть всякие штуки вроде экстеншенов и londiste репликации, и они не совместимы с тем, что предлагают облака.
В докладе я расскажу о том, почему мы остановились на patroni, на какие грабли наступили и какие у него есть неочевидные, но прикольные штуки, которые сильно облегчают жизнь.
-
Алексей Фадеев Sibedge Старший разработчик .NET, евангелист Postgres.Многие специалисты, обслуживающие СУБД не любят эти три буквы - 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 могут быть отличия в некоторых тонкостях, но основные принципы те же, поэтому доклад будет полезен разработчикам, использующим различные технологии.
-
Джошуа Дрейк Command Prompt, Inc. PioneerКогда вы оптимизируете Postgres, обычно вопросы эксплуатации оказываются задвинуты на обочину. Каким образом наладить autovacuum? Почему bloat? Из-за чего я получаю IO spikes? Как мне заставить RDS правильно себя вести?! Почему коммиты при репликации происходят так медленно? Ответ на все эти вопросы лежит в понимании взаимосвязи между надлежащей эксплуатацией Postgres и его производительностью. Приглашаю присоединиться к увлекательному 3-часовому путешествию по хитрому миру отладки Postgres!
-
Мирослав Шедиви solute GmbH Senior Software DeveloperИтак, вы наконец создали модель базы данных для вашего приложения и наполнили ее текущими данными. Каким образом обеспечить их актуальность? Хотя команда INSERT может быть все еще прозрачной, команды UPDATE и DELETE перезапишут ваши предыдущие данные, так что вы не сможете их воспроизвести. Клонирование целиком огромного контента при каждом небольшом обновлении - не вариант. Для богатых и сложных данных о сотнях тысяч электрогенераторов в Германии и по всему миру я построил базу данных, используя тип данных range, недавно появившийся в PostgreSQL. Это позволило мне добавлять, обновлять и удалять данные, при том обладая полным доступом к состоянию базы данных в любой исторический момент. Во время выступления я представлю очень упрощенную версию базы данных, чтобы аудитория смогла тут же применить знания на практике. Также я покожу несколько хитрых приемов в работе с Python и Psycopg2, которые позволят всей команде подготавливать, просматривать и развертывать все изменения в базе данных без конфликтов слияния. И подкину несколько идей о том, как можно эти данные эффективно извлекать.
Фотографии
Архив фотографий