title

text

Анатолий Анфиногенов
Анатолий Анфиногенов АО "ВНИИЖТ" Зам. директора научного центра - начальник отдела разработки ПО
: декабря
22 мин

Вакуумотерапия: лечим хронические заболевания БД

После импортозамещения и перехода с СУБД Oracle на PostgreSQL мы столкнулись как с "детскими" болезнями нашего приложения на новой СУБД, которые успешно вылечили, так и с "хроническими заболеваниями", с которыми пришлось разбираться существенно дольше. Одной из наиболее запомнившихся проблем стала проблема деградации производительности, которая, как выяснилось, была вызвана недостаточным вакуумированием нашей БД. Опыт осознания и решения этой проблемы предлагается вашему вниманию в виде практических рекомендаций по борьбе с эффектом bloat для таблиц и индексов БД, а также настройке VACUUM/autovacuum PostgreSQL.

Слайды

Видео

Видео доступно участникам мероприятия, выполнившим вход в личный кабинет

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

  • Christopher Travers
    Christopher Travers Independent Community Member Principal Engineer
    45 мин

    PostgreSQL vs Redis: Making the Right Choice

    With the rise of NoSQL databases, a number of falsehoods have flourished regarding how to choose a database engine. This talk focuses specifically on Redis and PostgreSQL, and why one might choose one or the other.

    At small scales, we can often get by thinking of database servers as black boxes, but as we scale, the internals and architecture become more and more important. This talk focuses on behavior of these systems at scale and under load.

    In this presentation you will learn:

    • How Redis and PostgreSQL differ architecturally
    • How differences in architecture affect scalability and performance
    • Cases here Redis is the clear winner
    • Cases where PostgreSQL is the clear winner

    Additionally, some notes will be offered in terms of where PostgreSQL can improve in to compete with the sorts of workloads that generally favor Redis.

  • Павел Толмачев
    Павел Толмачев Postgres Professional Специалист образовательного отдела
    22 мин

    Познакомимся с GEQO за 20 минут

    ----------------------------------------QUERY PLAN--------------------------------------------
    Hash Join
      Hash Cond: (Subject = GEQO)
       -> Hash Join
            Hash Cond: (Задача оптимизатора = выбрать наилучший план выполнения запроса)
            -> Seq Scan on Количество потенциальных планов экспоненциально растет при увеличении числа таблиц в запросе
            -> Hash
                  -> Seq Scan on PostgreSQL решает эту проблему с помощью использования генетического оптимизатора (GEQO)
      -> Hash
            -> Seq Scan on Темы доклада:
                  Filter: ((Что такое GEQO) AND (Достоинства и недостатки) AND (Принцип работы))
    (10 rows)
    

  • Павел Конотопов
    Павел Конотопов inCountry DBA team lead
    45 мин

    Пять оттенков шардинга

    Колоссальное значение сейчас приобретает шардинг. Размеры современных БД перешагивают 100 терабайтные пределы, вертикальное масштабирование, добавление реплик, содержащих полную физическую копию БД, становится затруднительным, особенно при дефиците вычислительных ресурсов. Шардирование базы данных – это способ горизонтально масштабироваться, разделив данные между независимыми друг от друга вычислительными узлами.

    В мире PostgreSQL существуют как давно известные инструменты масштабирования: CitusDB, Greenplum, так и решения нового поколения – Cockroach DB, Yugabyte DB, SPQR, Shardman.

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

  • Дмитрий Умников
    Дмитрий Умников https://axenix.pro/ Руководитель направления системного анализа
    45 мин

    Миграция Oracle на PostgreSQL в высоконагруженной системе с микросервисной архитектурой

    Доклад о нашем опыте внедрения PostgreSQL вместо Oralce в высоконагруженную систему с микросервисной архитектурой, обрабатывающую несколько террабайт данных. Расскажем о том, как прошли путь от пилотирования Greenplum до перехода на несколько взаимодействующих баз PosgreSQL с разными профилями нагрузки, и о проблемах, с которыми столкнулись в процессе.