title

text

Андрей Фефелов
Андрей Фефелов Mastery.pro Технический директор
11:45 05 февраля
45 мин

Как мы выбирали среди patroni, stolon, repmgr для нашего отказоустойчивого Постгреса

Для одного из наших проектов понадобилось решать задачу построения отказоустойчивой БД, желательно к тому же географический распределенной.

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

В докладе я расскажу о том, почему мы остановились на patroni, на какие грабли наступили и какие у него есть неочевидные, но прикольные штуки, которые сильно облегчают жизнь.

Слайды

Видео

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

  • Дмитрий Юхтимовский
    Дмитрий Юхтимовский Gilev.ru технический лидер
    22 мин

    Магические фокусы с последующим разоблачением (1С+PG)

    Магические фокусы с последующим разоблачением (1С+PG):

    • Фокус первый. Как убедить бухгалтерию купить новый сервер.
    • Фокус второй. Как показать, что MS SQL быстрее PostgreSQL.
    • Фокус третий. Как показать, что PostgreSQL быстрее MS SQL Server.

  • Александр Шелудченков
    Александр Шелудченков ГК "Митра" Программист
    22 мин

    Нестандартный кластер 1C

    • Перенос стандартного кластера 1С в MPI окружение - "миграция сервисов между машинами".
    • Перенос postgreSQL на GPU.

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

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

  • Джошуа Дрейк
    Джошуа Дрейк Command Prompt, Inc. Pioneer
    180 мин

    Производительность и эксплуатация Postgres

    Когда вы оптимизируете Postgres, обычно вопросы эксплуатации оказываются задвинуты на обочину. Каким образом наладить autovacuum? Почему bloat? Из-за чего я получаю IO spikes? Как мне заставить RDS правильно себя вести?! Почему коммиты при репликации происходят так медленно? Ответ на все эти вопросы лежит в понимании взаимосвязи между надлежащей эксплуатацией Postgres и его производительностью. Приглашаю присоединиться к увлекательному 3-часовому путешествию по хитрому миру отладки Postgres!