PgConf.Russia 2019

В докладе будет представлена новая платформа распределенной системы управления АЭС.

Вы узнаете, как обеспечивается управление сложнейшими объектами автоматизации в мире. В режиме жесткого реального времени обеспечивается работа более 150 специальных подсистем, управляющих различными технологическими процессами АЭС, таких как система управления реактором мощностью выше 1000 МВт и турбиной весом более 2000 тонн. Более 100К источников данных от датчиков и до 500К расчетных параметров. 5 разновидностей физических процессов: нейтронная кинетика, гидродинамика, химия и радиохимия и физика прочности.

При некоторых отклонениях вся система превращается в огромный источник DDoS полезной диагностической информации, которой всегда больше, чем способна переварить сеть и вычислительные ресурсы автоматизированной системы, что мешает нормальному управлению объектом. Вы узнаете, как мы «разруливаем» такие проблемы.

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

Но мы все же про кодинг. Никаких SSD и HDD, только InMemory, структуры данных из десятков миллионов элементов, забудьте про кэш процессора, он не работает. Ваш новый Xeon 4-го поколения потерял все преимущества и превратился в "тыкву", поэтому закатываем рукава и ковыряемся в таймингах, жесточайшей аcинхронике и выжимаем из железа максимум. Кто слабое звено - процессор, память, ОС или сеть. Выясняем это.

Возможно, Python не самый быстрый язык программирования на CPU, но быстрая и простая разработка на нем экономит массу усилий того, кто находится между креслом и клавиатурой. Поскольку программные клиенты базы данных большую часть времени находятся в ожидании отклика от сервера базы данных, аснихронная функциональность Python, ставшая доступной в последних версиях (3.5+), может оказаться полезной для значительной оптимизации скорости работы приложения за счет того, что время подготовки ответа сервером может быть использовано приложением для работы над другими задачами. Асинхронный интерфейс между Python и PostgreSQL называется "asyncpg". В ходе мастер-класса я разберу работу с данной библиотекой и напишу короткое приложение, использую некоторые полезные свойства библиотеки.

При 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 (экспериментальное).

Надежное резервное копирование и восстановление данных уровня предприятия для среды PostgreSQL. Больше никаких традиционных резервных копий. Технология CBT (Change Block Tracking) - это следующее поколение инкрементного резервного копирования. Быстрее, чем моментальные снимки, CBT создает резервные копии только блоков, которые изменяются, а не всех ваших данных, уменьшая нагрузку на сервер и сетевой трафик и устраняя необходимость в традиционных резервных копиях. Преимущества: • Защита данных в режиме близком к Real-Time • Обновление с легкостью