Администрирование баз данных в будущем будет полностью автоматизировано. Это уже так для базовых операций DBA: поднятие инстансов, бэкапы, управление репликацией, failover — мы наблюдаем это по бурному развитию облачных «управляемых» СУБД (AWS RDS, Google Cloud SQL и десятков игроков поменьше), работе над k8s-оператором для Postgres и MySQL в ряде компаний, внедрению внутренних RDS-like DBaaS (database-as-a-service) решений внутри крупных организаций.
Но диагностика и оптимизация производительности баз данных сегодня всё ещё очень «ручные». Например, в Postgres: находим медленную группу запросов в pg_stat_statements, ищем конкретный пример (а то и «выдумываем» его на ходу), пробуем EXPLAIN ANALYZE сначала в dev/staging-окружении, где, как правило, данных не так много, а потом на prod'е... Подбираем индекс, убеждаемся, что он ускоряет (вроде бы) один SQL-запрос и — всё, отправляем в production. Метод «чик-чик и в production» должен остаться в прошлом! Как остались в прошлом развёртывание и настройка серверов и сервисов вручную.
Nancy CLI (https://github.com/postgres-ai/nancy) – открытый фреймворк для проведения экспериментов над базами данных PostgreSQL, позволяющий любому инженеру наладить системный подход к анализу и оптимизации производительности БД. Nancy поддерживает проведение экспериментов локально (на любом сервере) и удалённо на дешёвых высокопроизводительных спот-инстансах AWS EC2.
Без каких-либо специальных знаний, используя Nancy CLI, любой инженер может теперь:
- собрать подробную информацию о поведении «SQL-запросов с прода» на «клоне прода», но «не трогая прод» с целью выявления узких мест (на «проде» под нагрузкой включать обширную диагностику неразумно, а иногда и невозможно);
- проверить, как тот или иной индекс влияет на производительность SQL (в том числе, насколько он замедлит UPDATE'ы);
- подобрать оптимальные параметры настройки Postgres'а (пример: запустить в облаке проверку 100 вариантов default_statistics_target с подробным исследованием эффекта и анализом для каждой группы SQL-запросов);
- сравнить 2+ прогонов моделированной нагрузки на клоне реальной БД в различных условиях (разное оборудование, разные версии Postgres, разные настройки, разные наборы индексов).
В докладе мы также обсудим конкретные примеры внедрения метода автоматизации экспериментов над БД и Nancy CLI в ряд проектов различных компаний (БД до 2ТБ, hybrid workload, до 15k TPS) и трудности, которые пришлось преодолеть на пути:
1. Включение полного логирования запросов: когда это просто страх, а когда это действительно серьёзный стресс для сервера? Как быть, если диски «не тянут» полное логирование?
2. Вопросы безопасности: нужно ли давать доступ к экспериментальным узлам всем разработчикам или можно обойтись без этого? Обфускировать ли данные?
3. Как убедиться, что результаты эксперимента достоверны?
4. Как проводить эксперименты над терабайтной базой данных быстро?
5. Стоит ли включать Nancy в CI/CD-конвейер?
Оптимизация high-contention write в PostgreSQL / Александр Коротков, Олег Бар...Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 7 ноября, 11:00
Тезисы:
http://www.highload.ru/2017/abstracts/3030.html
Оптимизация производительности – дело тонкое. Улучшая производительность системы при одной нагрузке, можно запросто ухудшить её при другой нагрузке. Основным мерилом производительности PostgreSQL в среде его разработчиков является pgbench. Как следствие, PostgreSQL стал "pgbench-optimized DBMS" (СУБД, оптимизированная для pgbench).
...
HighLoad++ 2017
Зал «Рио-де-Жанейро», 7 ноября, 12:00
Тезисы:
http://www.highload.ru/2017/abstracts/3111.html
This talk is prepared as a bunch of slides, where each slide describes a really bad way people can screw up their PostgreSQL database and provides a weight - how frequently I saw that kind of problem. Right before the talk I will reshuffle the deck to draw ten random slides and explain you why such practices are bad and how to avoid running into them.
что пришлось тестировать и о чем узнать при подготовке Linux версии pvs-studiocorehard_by
Большинство программистов плохо представляют, что означает создание PVS-Studio для Linux. Многие думают, что вся сложность в портировании кода, однако это очень далеко от истины: портировать код очень просто, однако это только 5% работы. Остальная работа скрыта от стороннего наблюдателя и заключается в решении многих инфраструктурных вопросов. Предлагаем заглянуть на кухню разработчиков анализатора PVS-Studio и узнать разные интересные нюансы их работы.
В ногу со временем, или как делать upgrade PostgreSQL / Андрей Сальников (Dat...Ontico
HighLoad++ 2017
Зал «Кейптаун», 7 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3082.html
Любое обновление чего-либо в продакшне - это проблема для администраторов, да и для всей компании в общем. И это особенная проблема, когда необходимо обновлять версию базы данных, и самый пик проблематичности, когда эта база - основное место хранения всех критически важных данных для проекта.
...
о некоторых вопросах бинарной совместимости в C++corehard_by
При написании кода на C++ часто появляются вопросы о том, как он будет взаимодейтсвовать с внешним миром. Ответить на эти вопросы порой бывает нелегко, и причиной этому служит отсуствие описания ABI в стандарте C++. В докладе рассмотрим, что такое ABI, и как программисты C++ живут в отсутсвии стандарта на него.
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2854.html
Из этого доклада вы узнаете о возможностях репликации и автофейловера PostgreSQL, в том числе о возможностях, ставших доступных в PostgreSQL 10.
Среди прочих, будет затронуты следующие темы:
* Виды репликации и решаемые с ее помощью проблемы.
* Настройка потоковой репликации.
* Настройка логической репликации.
* Настройка автофейловера / HA средствами Stolon и Consul.
После прослушивания доклада вы сможете самостоятельно настраивать репликацию и автофейловер PostgreSQL.
Оптимизация high-contention write в PostgreSQL / Александр Коротков, Олег Бар...Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 7 ноября, 11:00
Тезисы:
http://www.highload.ru/2017/abstracts/3030.html
Оптимизация производительности – дело тонкое. Улучшая производительность системы при одной нагрузке, можно запросто ухудшить её при другой нагрузке. Основным мерилом производительности PostgreSQL в среде его разработчиков является pgbench. Как следствие, PostgreSQL стал "pgbench-optimized DBMS" (СУБД, оптимизированная для pgbench).
...
HighLoad++ 2017
Зал «Рио-де-Жанейро», 7 ноября, 12:00
Тезисы:
http://www.highload.ru/2017/abstracts/3111.html
This talk is prepared as a bunch of slides, where each slide describes a really bad way people can screw up their PostgreSQL database and provides a weight - how frequently I saw that kind of problem. Right before the talk I will reshuffle the deck to draw ten random slides and explain you why such practices are bad and how to avoid running into them.
что пришлось тестировать и о чем узнать при подготовке Linux версии pvs-studiocorehard_by
Большинство программистов плохо представляют, что означает создание PVS-Studio для Linux. Многие думают, что вся сложность в портировании кода, однако это очень далеко от истины: портировать код очень просто, однако это только 5% работы. Остальная работа скрыта от стороннего наблюдателя и заключается в решении многих инфраструктурных вопросов. Предлагаем заглянуть на кухню разработчиков анализатора PVS-Studio и узнать разные интересные нюансы их работы.
В ногу со временем, или как делать upgrade PostgreSQL / Андрей Сальников (Dat...Ontico
HighLoad++ 2017
Зал «Кейптаун», 7 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3082.html
Любое обновление чего-либо в продакшне - это проблема для администраторов, да и для всей компании в общем. И это особенная проблема, когда необходимо обновлять версию базы данных, и самый пик проблематичности, когда эта база - основное место хранения всех критически важных данных для проекта.
...
о некоторых вопросах бинарной совместимости в C++corehard_by
При написании кода на C++ часто появляются вопросы о том, как он будет взаимодейтсвовать с внешним миром. Ответить на эти вопросы порой бывает нелегко, и причиной этому служит отсуствие описания ABI в стандарте C++. В докладе рассмотрим, что такое ABI, и как программисты C++ живут в отсутсвии стандарта на него.
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2854.html
Из этого доклада вы узнаете о возможностях репликации и автофейловера PostgreSQL, в том числе о возможностях, ставших доступных в PostgreSQL 10.
Среди прочих, будет затронуты следующие темы:
* Виды репликации и решаемые с ее помощью проблемы.
* Настройка потоковой репликации.
* Настройка логической репликации.
* Настройка автофейловера / HA средствами Stolon и Consul.
После прослушивания доклада вы сможете самостоятельно настраивать репликацию и автофейловер PostgreSQL.
Особенности архитектуры распределённого хранилища в Dropbox / Слава Бахмутов ...Ontico
Так как я работаю в позиции SRE (site reliability engineer), то более подробно затрону вопросы того, как мы добились годового durability 99.9999999999% и доступности более 99.99%:
- Изоляция
-- Физическая
--- Хранение данных в разных стойках, датацентрах, с разными версиями оборудования и вендорами.
--- Бэкапы вне основной инфраструктуры.
-- Логическая
--- Слабая связанность компонентов.
--- Не давать падению одного мастера (в зукипере или базе) утащить за собой всю зону.
-- Операционная
--- Процесс релиза.
--- Инструменты деплоя, сборки, хелзчекинга и т.д.
--- Контроль доступа.
- Защита данных
-- Восстановление
--- Восстановление после опасных операций (удаление).
-- Охрана данных и валидация операций
----в том числе от операторов.
- Контроль
-- Все совершают ошибки, нужно уметь детектировать их.
-- Метрики, SRE, OnCall.
-- Различные системы детектирование проблем, не связанные между собой, на каждом уровне систем (хост, кластер, ячейка, дата центр, внешние).
-- Тестирование
--- Disaster recovery testing.
- Автоматизация
-- Быстрое восстановление.
-- Быстрая реакция на события (нет времени реагировать вручную).
-- (introduce autoremedeation systems).
Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)Ontico
Исторически сложилось так, что одни люди разрабатывают приложения (Dev), а другие эксплуатируют их в продакшне (Ops). И у последних есть немало проблем с тем, что невозможно понять, что происходит.
Причем это касается как собственных разработок, так и популярных open source решений.
Я расскажу, как устроена диагностика у некоторых популярных софтин:
- nginx
- postgresql
- mongodb
Мы попробуем разобраться, что там сделано хорошо, и чего не хватает для полного счастья.
Во второй части доклада мы поговорим про то, как нужно инструментировать собственное приложение для прозрачной работы в продакшне:
- что считать и зачем: ошибки, тайминги, разные состояния приложения,
- инструментарий: your_lang-metrics, your_lang-statsd-client, логи,
- как не перемудрить и не убить прод диагностикой.
Может показаться, что этот доклад про DevOps, но нет - про docker не будет ни слова :)
Промышленный подход к тюнингу PostgreSQL: эксперименты над базами данныхNikolay Samokhvalov
Shared_buffers = 25% – это много или мало? Или в самый раз? Как понять, подходит ли эта – довольно устаревшая – рекомендация в вашем конкретном случае?
Пришло время подойти к вопросу подбора параметров postgresql.conf "по-взрослому". Не с помощью слепых "автотюнеров" или устаревших советов из статей и блогов, а на основе:
строго выверенных экспериментов на БД, производимых автоматизированно, в больших количествах и в условиях, максимально приближенных к "боевым",
глубокого понимания особенностей работы СУБД и ОС.
Используя Nancy CLI (https://gitlab.com/postgres.ai/nancy), мы рассмотрим конкретный пример – пресловутые shared_buffers – в разных ситуациях, в разных проектах и попробуем разобраться, как же подобрать оптимальную настройку для нашей инфраструктуры, БД и нагрузки.
https://pgconf.ru/2019/242809
Отладка и устранение проблем в PostgreSQL Streaming Replication.Alexey Lesovsky
Потоковая репликация, которая появилась в 2010 году, стала одной из прорывных фич постгреса и в настоящее время практически ни одна инсталляция не обходится без использования потоковой репликации. Она надежна, легка в настройке, нетребовательна к ресурсам. Однако при всех своих положительных качествах, при её эксплуатации могут возникать различные проблемы и неприятные ситуации. Для диагностики и решения проблем, связанных с потоковой репликацией, есть множество инструментов, как встроенных в PostgreSQL, так и сторонних.
В этом докладе я сделаю обзор доступных инструментов и расскажу, как с помощью этих средств диагностировать различные типы проблем и как устранять их. Рассматривая методы решения, мы также рассмотрим проблемы, которые возникают при эксплуатации потоковой репликации.
Доклад будет полезен DBA и системным администраторам.
В докладе мы поделимся опытом создания content-based рекомендательной системы для электронной коммерции, работающей на семантическом ядре рунета (десятки миллионов профилей). Расскажем, как организовали централизованный сбор и обработку информации о посещении пользователями более 100 000 сайтов различной направленности на основе Amazon Kinesis. Поделимся опытом многопоточной онлайн-индексации потоков данных в Lucene. Продемонстрируем используемые базовые алгоритмы ранжирования и формирования персональных рекомендаций для посетителей более 20 000 интернет-магазинов.
Поговорим о плюсах и минусах лямбда-архитектур и обоснуем выбранное нами архитектурное решение. Отдельно остановимся на тонкостях технической реализации многопоточных алгоритмов и особенностях обеспечения реального времени - поступившая информация о действиях посетителя практически мгновенно учитывается рекомендательным движком, обеспечивая максимальную конверсию.
noBackend, или Как выжить в эпоху толстеющих клиентов / Самохвалов НиколайOntico
Набирает обороты мода на парадигму noBackend (см., например, http://nobackend.org/). Название не стоит понимать буквально: backend никуда не делся, просто фокус разработки — особенно на начальном этапе развития нового проекта — сильно смещается в сторону «клиентской части». Это очень понятно и закономерно в эпоху Mobile First и React Ecosystem с её новомодными GraphQL и React Native.
Появляется большой соблазн взять что-то понятное для хранения данных и уже «обвязанное» REST API, максимально отказаться от PHP/Python/Ruby/Java/etc, писать 80% кода «на стороне клиента», минимально заботясь о возне «на стороне сервера». У некоторых возникает и настоящая эйфория — чувство приятное, но очень опасное (прежде всего, если в команде нет сильного backend-опыта).
Этот доклад — компиляция опыта ряда проектов, написанных на React, React Native и Swift и переходящих на парадигму (или же сразу стартанувших с неё) noBackend за счёт PostgreSQL+PostgREST.
Мы обсудим важные вопросы, которые обязан задавать себе каждый, выбравший noBackend-подход (и не обязательно на связке Postgres+PostgREST): безопасность (аутентификация/авторизация; ограничение чтения и — особенно! — модификации «чужих» данных), производительность (нетривиальные запросы а-ля «свежий контент от тех, на кого я подписан»; компромисс между сетевой сложностью и CPU; защита от «домашнего» ddos — ситуации, когда свои же, родные «фронтендеры» кладут «бэкэнд»), масштабируемость и асинхронная обработка задач.
Задача-минимум (для всех): у каждого слушателя остаётся список must-check-вопросов для работы с noBackend-подходом.
Задача-максимум (для тех, кто с Postgres-опытом): разворачивание безопасного, высокопроизводительного и годного для быстрого развития REST API — сегодня же, в день док
При проектировании нагруженных систем приходится сталкиваться с тем, что разные типы запросов к веб-серверам затрачивают разное количество ресурсов, выполняются за разное количество времени и имеют разные приоритеты выполнения. Некоторые запросы «стоят» мало и должны выполняться как можно быстрее. Некоторые «стоят» дорого, и главное, чтобы они не блокировали обработку быстрых запросов. Существующие схемы приоритезации показались нам громоздкими и неудобными – при росте количества типов запросов конфигурация системы усложнялась в разы. Поэтому, чтобы решить эту проблему, а также для того, чтобы сделать ответы на запросы еще более быстрыми, мы написали свой веб-сервер – Phantom. Я расскажу вам, как он устроен, покажу, какие задачи можно решать с его помощью, а в завершение покажу на практике, как работает приоритезация разных типов запросов, используя для этого инструмент нагрузочного тестирования, основанный на Phantom.
DC/OS – больше чем PAAS, Никита Борзых (Express 42)Ontico
Доклад про ближайшее будущее в эксплуатации распределённых систем.
Компания Mesosphere весной 2016 сделала свою платформу DC/OS (data center operation system) бесплатной и открытой. Платформа DC/OS унифицирует и упрощает процесс поставки и эксплуатации систем.
Основными особенностями платформы являются:
– переход от host centric к resource centric подходу для всех компонентов вашего проекта за счёт представления серверов как ресурсов для приложения (с помощью mesos и marathon);
– наличие инструментов автоматического восстановления вашего проекта после аварии;
– marketplace для приложений. Например, можно развернуть MySQL, Elasticsearch, Kafka или mongodb кластер, используя готовые скрипты развертывания. Процесс развертывания кастомизируется, в случае необходимости можно описать кастомные приложения и поправить скрипты существующих;
– наличие API для интеграции в ваши системы CI/CD, мониторинга, и т.д.
Основные компоненты DC/OS:
– Apache Mesos — абстракция над датацентром, которая представляет сервера (физические и виртуальные) как ресурсы и распределяет эти ресурсы на основании данных о потребностях приложения;
– Marathon — система распределённого запуска приложений (в т.ч. docker контейнеров), основной фишкой является возможность декларативного описания вашей системы. Вы можете описать, сколько ресурсов нужно вашему приложению, зависимости между приложениями, и в каком порядке производить деплой.
Доклад разбит на три части:
– Интро про DC/OS, сравнение с kubernetes и coreos стеком;
– Рассказ про компоненты mesos и marathon, как их можно использовать с докером (и без!) уже сейчас;
– Опыт Express 42. Мы построили CI/CD платформу для приложений, с использованием Mesos, Marathon, Docker и Jenkins 2.0.
В презентации описан подход к оценке производительности hadoop кластера. Описаны вероятные узкие места, влияющие на производительность кластера. Приведен пример сравнения производительности двух кластеров на различном железе.
Особенности архитектуры распределённого хранилища в Dropbox / Слава Бахмутов ...Ontico
Так как я работаю в позиции SRE (site reliability engineer), то более подробно затрону вопросы того, как мы добились годового durability 99.9999999999% и доступности более 99.99%:
- Изоляция
-- Физическая
--- Хранение данных в разных стойках, датацентрах, с разными версиями оборудования и вендорами.
--- Бэкапы вне основной инфраструктуры.
-- Логическая
--- Слабая связанность компонентов.
--- Не давать падению одного мастера (в зукипере или базе) утащить за собой всю зону.
-- Операционная
--- Процесс релиза.
--- Инструменты деплоя, сборки, хелзчекинга и т.д.
--- Контроль доступа.
- Защита данных
-- Восстановление
--- Восстановление после опасных операций (удаление).
-- Охрана данных и валидация операций
----в том числе от операторов.
- Контроль
-- Все совершают ошибки, нужно уметь детектировать их.
-- Метрики, SRE, OnCall.
-- Различные системы детектирование проблем, не связанные между собой, на каждом уровне систем (хост, кластер, ячейка, дата центр, внешние).
-- Тестирование
--- Disaster recovery testing.
- Автоматизация
-- Быстрое восстановление.
-- Быстрая реакция на события (нет времени реагировать вручную).
-- (introduce autoremedeation systems).
Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)Ontico
Исторически сложилось так, что одни люди разрабатывают приложения (Dev), а другие эксплуатируют их в продакшне (Ops). И у последних есть немало проблем с тем, что невозможно понять, что происходит.
Причем это касается как собственных разработок, так и популярных open source решений.
Я расскажу, как устроена диагностика у некоторых популярных софтин:
- nginx
- postgresql
- mongodb
Мы попробуем разобраться, что там сделано хорошо, и чего не хватает для полного счастья.
Во второй части доклада мы поговорим про то, как нужно инструментировать собственное приложение для прозрачной работы в продакшне:
- что считать и зачем: ошибки, тайминги, разные состояния приложения,
- инструментарий: your_lang-metrics, your_lang-statsd-client, логи,
- как не перемудрить и не убить прод диагностикой.
Может показаться, что этот доклад про DevOps, но нет - про docker не будет ни слова :)
Промышленный подход к тюнингу PostgreSQL: эксперименты над базами данныхNikolay Samokhvalov
Shared_buffers = 25% – это много или мало? Или в самый раз? Как понять, подходит ли эта – довольно устаревшая – рекомендация в вашем конкретном случае?
Пришло время подойти к вопросу подбора параметров postgresql.conf "по-взрослому". Не с помощью слепых "автотюнеров" или устаревших советов из статей и блогов, а на основе:
строго выверенных экспериментов на БД, производимых автоматизированно, в больших количествах и в условиях, максимально приближенных к "боевым",
глубокого понимания особенностей работы СУБД и ОС.
Используя Nancy CLI (https://gitlab.com/postgres.ai/nancy), мы рассмотрим конкретный пример – пресловутые shared_buffers – в разных ситуациях, в разных проектах и попробуем разобраться, как же подобрать оптимальную настройку для нашей инфраструктуры, БД и нагрузки.
https://pgconf.ru/2019/242809
Отладка и устранение проблем в PostgreSQL Streaming Replication.Alexey Lesovsky
Потоковая репликация, которая появилась в 2010 году, стала одной из прорывных фич постгреса и в настоящее время практически ни одна инсталляция не обходится без использования потоковой репликации. Она надежна, легка в настройке, нетребовательна к ресурсам. Однако при всех своих положительных качествах, при её эксплуатации могут возникать различные проблемы и неприятные ситуации. Для диагностики и решения проблем, связанных с потоковой репликацией, есть множество инструментов, как встроенных в PostgreSQL, так и сторонних.
В этом докладе я сделаю обзор доступных инструментов и расскажу, как с помощью этих средств диагностировать различные типы проблем и как устранять их. Рассматривая методы решения, мы также рассмотрим проблемы, которые возникают при эксплуатации потоковой репликации.
Доклад будет полезен DBA и системным администраторам.
В докладе мы поделимся опытом создания content-based рекомендательной системы для электронной коммерции, работающей на семантическом ядре рунета (десятки миллионов профилей). Расскажем, как организовали централизованный сбор и обработку информации о посещении пользователями более 100 000 сайтов различной направленности на основе Amazon Kinesis. Поделимся опытом многопоточной онлайн-индексации потоков данных в Lucene. Продемонстрируем используемые базовые алгоритмы ранжирования и формирования персональных рекомендаций для посетителей более 20 000 интернет-магазинов.
Поговорим о плюсах и минусах лямбда-архитектур и обоснуем выбранное нами архитектурное решение. Отдельно остановимся на тонкостях технической реализации многопоточных алгоритмов и особенностях обеспечения реального времени - поступившая информация о действиях посетителя практически мгновенно учитывается рекомендательным движком, обеспечивая максимальную конверсию.
noBackend, или Как выжить в эпоху толстеющих клиентов / Самохвалов НиколайOntico
Набирает обороты мода на парадигму noBackend (см., например, http://nobackend.org/). Название не стоит понимать буквально: backend никуда не делся, просто фокус разработки — особенно на начальном этапе развития нового проекта — сильно смещается в сторону «клиентской части». Это очень понятно и закономерно в эпоху Mobile First и React Ecosystem с её новомодными GraphQL и React Native.
Появляется большой соблазн взять что-то понятное для хранения данных и уже «обвязанное» REST API, максимально отказаться от PHP/Python/Ruby/Java/etc, писать 80% кода «на стороне клиента», минимально заботясь о возне «на стороне сервера». У некоторых возникает и настоящая эйфория — чувство приятное, но очень опасное (прежде всего, если в команде нет сильного backend-опыта).
Этот доклад — компиляция опыта ряда проектов, написанных на React, React Native и Swift и переходящих на парадигму (или же сразу стартанувших с неё) noBackend за счёт PostgreSQL+PostgREST.
Мы обсудим важные вопросы, которые обязан задавать себе каждый, выбравший noBackend-подход (и не обязательно на связке Postgres+PostgREST): безопасность (аутентификация/авторизация; ограничение чтения и — особенно! — модификации «чужих» данных), производительность (нетривиальные запросы а-ля «свежий контент от тех, на кого я подписан»; компромисс между сетевой сложностью и CPU; защита от «домашнего» ddos — ситуации, когда свои же, родные «фронтендеры» кладут «бэкэнд»), масштабируемость и асинхронная обработка задач.
Задача-минимум (для всех): у каждого слушателя остаётся список must-check-вопросов для работы с noBackend-подходом.
Задача-максимум (для тех, кто с Postgres-опытом): разворачивание безопасного, высокопроизводительного и годного для быстрого развития REST API — сегодня же, в день док
При проектировании нагруженных систем приходится сталкиваться с тем, что разные типы запросов к веб-серверам затрачивают разное количество ресурсов, выполняются за разное количество времени и имеют разные приоритеты выполнения. Некоторые запросы «стоят» мало и должны выполняться как можно быстрее. Некоторые «стоят» дорого, и главное, чтобы они не блокировали обработку быстрых запросов. Существующие схемы приоритезации показались нам громоздкими и неудобными – при росте количества типов запросов конфигурация системы усложнялась в разы. Поэтому, чтобы решить эту проблему, а также для того, чтобы сделать ответы на запросы еще более быстрыми, мы написали свой веб-сервер – Phantom. Я расскажу вам, как он устроен, покажу, какие задачи можно решать с его помощью, а в завершение покажу на практике, как работает приоритезация разных типов запросов, используя для этого инструмент нагрузочного тестирования, основанный на Phantom.
DC/OS – больше чем PAAS, Никита Борзых (Express 42)Ontico
Доклад про ближайшее будущее в эксплуатации распределённых систем.
Компания Mesosphere весной 2016 сделала свою платформу DC/OS (data center operation system) бесплатной и открытой. Платформа DC/OS унифицирует и упрощает процесс поставки и эксплуатации систем.
Основными особенностями платформы являются:
– переход от host centric к resource centric подходу для всех компонентов вашего проекта за счёт представления серверов как ресурсов для приложения (с помощью mesos и marathon);
– наличие инструментов автоматического восстановления вашего проекта после аварии;
– marketplace для приложений. Например, можно развернуть MySQL, Elasticsearch, Kafka или mongodb кластер, используя готовые скрипты развертывания. Процесс развертывания кастомизируется, в случае необходимости можно описать кастомные приложения и поправить скрипты существующих;
– наличие API для интеграции в ваши системы CI/CD, мониторинга, и т.д.
Основные компоненты DC/OS:
– Apache Mesos — абстракция над датацентром, которая представляет сервера (физические и виртуальные) как ресурсы и распределяет эти ресурсы на основании данных о потребностях приложения;
– Marathon — система распределённого запуска приложений (в т.ч. docker контейнеров), основной фишкой является возможность декларативного описания вашей системы. Вы можете описать, сколько ресурсов нужно вашему приложению, зависимости между приложениями, и в каком порядке производить деплой.
Доклад разбит на три части:
– Интро про DC/OS, сравнение с kubernetes и coreos стеком;
– Рассказ про компоненты mesos и marathon, как их можно использовать с докером (и без!) уже сейчас;
– Опыт Express 42. Мы построили CI/CD платформу для приложений, с использованием Mesos, Marathon, Docker и Jenkins 2.0.
В презентации описан подход к оценке производительности hadoop кластера. Описаны вероятные узкие места, влияющие на производительность кластера. Приведен пример сравнения производительности двух кластеров на различном железе.
Доклад от Parallels:
Методики тестировния производительности database-centric приложений
Описание: При работе над сложными продуктами в database-centric приложениях изменения в коде и тем более в SQL запросах к базе данных могут приводить к неожиданным падениям производительности или же деградации производительности приложения с ростом размера базы данных. Поэтому важно уметь как можно быстрее отлавливать и исправлять причины таких деградаций.
Доклад о том, как устроен процесс мониторинга производительности продукта автоматизации хостинга и облачных сервисов Parallels Automation, для которого определяющим фактором является производительность базы данных.
Компания покажет, как анализирует планы исполнения SQL запросов внутри PostgreSQL, как проверяет насколько быстро и эффективно в целом работают SQL запросы, как определяет стратегию дальнейшей оптимизации.
Привет, Санкт-Петербург!
В разгар летнего сезона, мы поговорим об историях обновлений,
например, с 6.4 до 7.х, с разными трюками, а также об истории исследования разных регрессий на продуктах Atlassian и других плагинов.
Наша программа будет пополняться, и мы рады к сотрудничеству.
Ждем Вас на встрече в Яндекс Деньгах.
DevConf 2016
"Новые возможности MySQL 5.7", Дмитрий Ленев (Oracle)
MySQL 5.7 наиболее свежая стабильная ветка СУБД MySQL. Данный доклад
посвящен новым функциональным возможностям появившимся в этой версии.
В частности мы поговорим о:
- родной поддержке JSON данных и операций с ними
- генерируемых столбцах
- улучшениях в системе безопасности
- многочисленных измененениях в InnoDB
- изменениях в репликации, таких как поддержка multi-source репликации.
- многом другом
Кроме того будут освещены возможности связанные с новым X плагином, который
стал доступен с релизом версии 5.7.12 в апреле этого года.
Обсудим использование MySQL как Document Store, новый протокол и X DevApi
для коннекторов, новый клиент MySQL Shell.
Последние новости постгреса с PGCon / О.Бартунов, А.Коротков, Ф.Сигаев (Postg...Ontico
Как быстро развивается сейчас PostgreSQL — общеизвестно. За несколько дней до РИТ++ заканчивается главный мировой форум разработчиков этой СУБД — конференция PGCon в Канаде. Большая команда разработчиков Postgres Professional принимает участие в этой конференции и готова рассказать все последние новости прямо с PGCon.
Параллельное исполнение запросов, новые стораджи, неутихающая тема Postgres vs key-value storage, распределенный Postgres, высокая доступность, многочисленные улучшения производительности, планы и интриги разработчиков — вот основные темы этой конференции.
Я остановлюсь подробнее на нашем вкладе в ожидаемый релиз 9.6 и планах на, возможно, релиз 10.0.
Плюсы и минусы Go для разработчиков на C++, Вячеслав БахмутовYandex
В докладе речь пойдёт о языке Go. Вячеслав расскажет о внутреннем устройстве языка (структуре, оптимизации, сборщике мусора и т.д.), о том, как и почему Go используют в Яндексе и что о нём говорят разработчики на С++. Отдельно Вячеслав остановится на многопоточном программировании и особенностях отладки и профилирования в Go.
СУБД Firebird: Краткий обзор, Дмитрий Еманов (in Russian)Alexey Kovyazin
Небольшая презентация Дмитрия Еманова, ведущего разработчика Firebird, посвящена обзору СУБД Firebird, в том числе текущему состоянию и планам развития.
The Art of Database Experiments – PostgresConf Silicon Valley 2018 / San JoseNikolay Samokhvalov
Future database administration will be highly automated. Until then, we still live in a world where extensive manual interactions are required from a skilled DBA. This will change soon as more "autonomous databases" reach maturity and enter the production environment.
Postgres-specific monitoring tools and systems continue to improve, detecting and analyzing performance issues and bottlenecks in production databases. However, while these tools can detect current issues, they require highly-experienced DBAs to analyze and recommend mitigations.
In this session, the speaker will present the initial results of the POSTGRES.AI project – Nancy CLI, a unified way to manage automated database experiments. Nancy CLI is an automated database management framework based on well-known open-source projects and incorporating major open-source tools and Postgres modules: pgBadger, pg_stat_kcache, auto_explain, pgreplay, and others.
Originally developed with the goal to simulate various SQL query use cases in various environments and collect data to train ML models, Nancy CLI turned out to be very a universal framework that can play a crucial role in CI/CD pipelines in any company.
Using Nancy CLI, casual DBAs and any engineers can easily conduct automated experiments today, either on AWS EC2 Spot instances or on any other servers. All you need is to tell Nancy which database to use, specify workload (synthetic or "real", generated based on the Postgres logs), and what you want to test – say, check how a new index will affect all most expensive query groups from pg_stat_statements, or compare various values of "default_statistics_target". All the collected information with a very high level of confidence will give you understanding, how various queries and overall Postgres performance will be affected when you apply this change to production.
Nancy CLI, a unified way to manage automated database experiments. Nancy CLI is an automated database management framework based on well-known open-source projects and incorporating major open-source tools.
Using these tools, casual DBAs can conduct automated experiments today, either on AWS EC2 Spot instances or on any other servers. All you need is to tell Nancy which database to use, how to determine workloads and what you want to verify – say, check how some index will help, or compare various values of "default_statistics_target" for your database and your workload.
Everything else Nancy will do for you, in fully automated fashion, in the end presenting you detailed results for comparison.
#RuPostgresLive 4: как писать и читать сложные SQL-запросыNikolay Samokhvalov
Онлайн-опросы неизменно показывают — всех нас очень интересуют две вещи: а) как писать наиболее эффективные SQL-запросы, б) как «читать» такие запросы, а точнее, как понимать, что именно делает или будет делать СУБД при их выполнении.
Эти две неразрывно связанные друг с другом темы чрезвычайно обширны, SQL-искусству можно (и нужно) учиться годами. Во время нашей очередной встречи в прямом эфире мы затронем некоторые аспекты обеих.
ЧАСТЬ 1: EXPLAIN
Алексей Ермаков. Как читать и интерпретировать вывод команды EXPLAIN
Команда EXPLAIN — основной инструмент анализа запросов, позволяющий разобраться, каким образом запрос будет выполняться и как можно его ускорить. Для сложных запросов вывод может быть довольно громоздким и его становится сложно читать. Я расскажу, из каких частей состоит план запроса, на какие «маркеры» в нём следует обращать внимание в первую очередь и как на это реагировать.
ЧАСТЬ 2: ADVANCED SQL
Николай Самохвалов. SQL современный и «продвинутый»
«Я не волшебник, я только учусь». Продвинутому SQL нас постоянно учат такие видные гуру как Markus Winand и Макс Богук. Рекурсивные CTE, LATERAL JOIN, виртуозная работа с массивами и строками, window functions и прочие модные штучки, которые помогут вам в дрессировке вашего Постгреса, — я постараюсь сделать хороший обзор, а если вдруг тема покажется интересной, то в следующих сеансах группового Постгреса мы обязательно пригласим настоящих гуру :)
#RuPostgresLive 4: как писать и читать сложные SQL-запросыNikolay Samokhvalov
Онлайн-опросы неизменно показывают — всех нас очень интересуют две вещи: а) как писать наиболее эффективные SQL-запросы, б) как «читать» такие запросы, а точнее, как понимать, что именно делает или будет делать СУБД при их выполнении.
Эти две неразрывно связанные друг с другом темы чрезвычайно обширны, SQL-искусству можно (и нужно) учиться годами. Во время нашей очередной встречи в прямом эфире мы затронем некоторые аспекты обеих.
ЧАСТЬ 1: EXPLAIN
Алексей Ермаков. Как читать и интерпретировать вывод команды EXPLAIN
Команда EXPLAIN — основной инструмент анализа запросов, позволяющий разобраться, каким образом запрос будет выполняться и как можно его ускорить. Для сложных запросов вывод может быть довольно громоздким и его становится сложно читать. Я расскажу, из каких частей состоит план запроса, на какие «маркеры» в нём следует обращать внимание в первую очередь и как на это реагировать.
ЧАСТЬ 2: ADVANCED SQL
Николай Самохвалов. SQL современный и «продвинутый»
«Я не волшебник, я только учусь». Продвинутому SQL нас постоянно учат такие видные гуру как Markus Winand и Макс Богук. Рекурсивные CTE, LATERAL JOIN, виртуозная работа с массивами и строками, window functions и прочие модные штучки, которые помогут вам в дрессировке вашего Постгреса, — я постараюсь сделать хороший обзор, а если вдруг тема покажется интересной, то в следующих сеансах группового Постгреса мы обязательно пригласим настоящих гуру :)
Database First! О распространённых ошибках использования РСУБДNikolay Samokhvalov
Мы обсудим несколько фундаментальных ситуаций использования РСУБД (каждая из которых неоднократно встречалась автору), попутно разбирая возможные ошибки:
- элементарная модификация данных;
- работа с датой, временем и временными зонами;
- проверка ограничений целостности;
- очередь заданий;
- пакетная работа с данными (например, удаление пачки записей в таблице);
- полнотекстовый поиск;
- относительно новые задачи (создание API, machine learning).
#RuPostges в Yandex, эпизод 3. Что же нового в PostgreSQL 9.6Nikolay Samokhvalov
Первый релиз-кандидат версии 9.6 вышел 1 сентября, а это значит, что совсем скоро будет полноценный релиз. Все вокруг уже успели обсудить новинки, и теперь уже стыдно ничего не знать о таких вещах, как параллелизация выполнения запросов, pushdown для FDW, мониторинг waitlocks, полнотекстовый поиск по фразам или магический \gexec в psql. Чтобы никому не приходилось краснеть, мы быстро пройдёмся по всем основным и интересным моментам версии 9.6.
A Lightning talk about Postgres in Russia and #PostgreSQLRussia, Nikolay Samokhvalov, includes 2016 CfPs inviting speakers to PgDay.ru, PgConf.ru and Highload.co convefereces
Владимир Бородин: Как спать спокойно - 2015.10.14 PostgreSQLRussia.org meetu...Nikolay Samokhvalov
More: http://PostgreSQLRussia.org
Доклад посвящён резервному хранению СУБД PostgreSQL. Мы поговорим о том, как устроено хранение данных на диске и организован WAL в PostgreSQL, какие есть средства для резервного копирования и восстановления данных. Обсудим, как перестать беспокоиться за свои данные и почему PostgreSQL славится своей надёжностью.
#PostgreSQLRussia 2015.09.15 - Николай Самохвалов - 5 главных особенностей Po...Nikolay Samokhvalov
Встречи сообщества http://PostgreSQLRussia.org -
Миграция из Oracle в Postgres. Встреча в компании CUSTIS.
План встречи:
19:00 Приветственная пицца, свободное общение.
19:20 Вступление. Рассказ о CUSTIS.
19:25 Николай Самохвалов. Коротко о PostgreSQL.
19:35 Максим Трегубов, CUSTIS. Миграция данных из Oracle в Postgres. Доклад о том, как мы для одного из заказчиков тестировали переход с СУБД Oracle на Postgres. Расскажем о выборе инструмента миграции данных, настройке тестовой среды и о полученных результатах. Также немного затронем модную тему DevOps и покажем роль Ansible в миграции данных.
20:10 Вячеслав Муравлев, CUSTIS. Data Access Layer как страховка при миграции СУБД. Для многих АС миграция с одной СУБД на другую сродни наступлению страхового случая «тотал» - необходимо переписать львиную долю кода. Подстраховаться от такого ущерба можно с помощью шаблона проектирования Data Access Layer (DAL). Мы расскажем как этот подход помог нам провести первый этап миграции АС одного из заказчиков с Oracle на PostgreSQL, рассмотрим инструментарий, обсудим применимость подхода на уровне предприятия.
20:30 Иван Кухарчук, ЯНДЕКС. Как можно сэкономить на лицензиях и снизить нагрузку на Oracle, переселив отчёты в PostgreSQL.
20:50 Завершение встречи, свободное общение.
Максим Трегубов, CUSTIS. Миграция данных из Oracle в Postgres. Доклад о том, как мы для одного из заказчиков тестировали переход с СУБД Oracle на Postgres. Расскажем о выборе инструмента миграции данных, настройке тестовой среды и о полученных результатах. Также немного затронем модную тему DevOps и покажем роль Ansible в миграции данных.
Три вызова реляционным СУБД и новый PostgreSQL - #PostgreSQLRussia семинар по...Nikolay Samokhvalov
Реляционной модели скоро исполнится полвека – это огромный срок для любой технологической индустрии, не говоря уже об ИТ. За прошедшие годы этой модели было брошено немало вызовов, оказавших немалое влияние на развитие реляционных СУБД. В докладе обсуждаются три главных вызова реляционной модели, включая и NoSQL. На основе многолетнего опыта использования PostgreSQL для создания социальных сетей, объединяющих многомиллионные аудитории, наглядно демонстрируется как эта СУБД реагировала на возникающие вызовы. Речь также пойдет о «трех китах» PostgreSQL, которые не дают этой системе превратиться в монстра и позволяют обогащаться функционалом, необходимым для создания современных высоконагруженных проектов. Особое внимание в докладе уделено новым типам данных, JSON и JSONB — их возможностям, способам индексирования, а также разбору имеющихся недостатков.
2014.12.23 Николай Самохвалов, Ещё раз о JSON(b) в PostgreSQL 9.4Nikolay Samokhvalov
Тип данных JSONb – это, пожалуй, самая яркая новинка PostgreSQL 9.4, который вышел 18 декабря 2014.
Уже немало докладов и статей посвящено этому типу данных, работе с ним и индексации. Но как правило, информация в них перегружена специфичными для PostgreSQL терминами.
Запутались в моделях данных? В том, какие индексы могут вам помочь ускорить вашу работу с СУБД?
Этот доклад помогает сложить паттерн. Он для тех, кто начал использовать PostgreSQL совсем недавно или только планирует работать с ним. В нём рассказано о месте PostgreSQL в современном мире СУБД, о борьбе различных моделей данных за место под солнцем на этом рынке и то, как это отразилось на развитие Postgres.
Помимо прочего, рассказывается о том, какие вообще бывают деревья, как они помогают ускорять базы данных и почему PostgreSQL — просто райский лес для деревьев самого разного типа :)
См. также видео: http://postgresmen.ru/meetup/2014-12-23-parallels
* приемы доступа к данным;
* прикладной класс работы с БД поверх PDO, особенности PDO;
* связки пуллов коннектов;
* API хранимых процедур;
* работа c распределенным хранилищем;
* RPC между базами на примере асинхронного геокодинга.
PostgreSQL Moscow Meetup - September 2014 - Ilya Kosmodemyansky
Эксперименты с Postgres в Docker и облаках — оптимизация настроек и схемы вашей БД без риска «уронить прод» — Highload++ 2018
1. Эксперименты над базами данных
Postgres в Docker и облаках —
оптимизация настроек и схемы вашей БД
без риска «уронить прод»
Николай Самохвалов
email: nik@postgres.ai
twitter: @postgresmen
2. О докладчике:
Опыт Postgres: 13+ лет (СУБД: 17+)
Прошлое: co-founder/CTO MoiKrug.ru, MirTesen.ru, Postila.ru (везде — Postgres)
Co-founder #RuPostgres (1700+ пользователей на Meetup.com, 2-е место в мире)
PostgreSQL-консалтинг в SF Bay Area (PostgreSQL.support)
Основатель Postgres.ai – платформа для Postgres DBA, автоматизация тех
задач DBA, которые ещё не автоматизированы «облаками»
Twitter: @postgresmen
Email: ns@postgres.ai
9. prod
monitoring
Engineer
Сигналы о проблемах (alerts)
наблюдения «вручную»
● pg_stat_statements
○ нет экземпляров
запросов
○ нет планов
Наиболее популярные средства для анализа запросов «в целом»:
10. prod
monitoring
Engineer
Сигналы о проблемах (alerts)
наблюдения «вручную»
● pg_stat_statements
○ нет экземпляров
запросов
○ нет планов
● log analysis (pgBadger)
○ требует поддержки
○ не «realtime»
○ обычно нет планов (есть, если auto_explain)
○ часто неполноценная картина
(log_min_duration_statement >> 0)
Наиболее популярные средства для анализа запросов «в целом»:
25. Почитали умные статьи или посты в блогах. Возникла идея:
Значение default_statistics_target (100) слишком мало.
Давайте поменяем на 1000!
...Отличная идея!
...Сделано — уже в production!
26. Но всe ли запросы улучшились?
Как именно изменился каждый запрос?
27. Но всe ли запросы улучшились?
Как именно изменился каждый запрос?
Проверим с помощью экспериментов!
28. A real-life example. default_statistics_target: 100 vs 10002 года спустя: проверка с помощью эксперимента, значения 100 и 1000:
32. A real-life example. default_statistics_target: 100 vs 1000
Эта группа запросов стала намного
медленнее после изменения!
Решили с помощью:
“ALTER TABLE/INDEX … ALTER COLUMN SET
STATISTICS …“
на конкретном столбце
ДО: default_statistics_target = 100 ПОСЛЕ: default_statistics_target = 1000
36. GFDL and CC-BY-2.5, Wikipedia.org
Ещё один пример
Авиация, космос, автомобилестроение и т.д.:
аэродинамическая труба
37. Эксперименты в развитых отраслях:
1. …производятся в специальном окружении,
не в production!
(staging”, “лаборатория”)
2. Детальный анализ за счёт спецсредств
3. Высокий уровень автоматизации.
Много “прогонов”. Серии. Дешёвый, быстрый запуск
43. Из чего состоит эксперимент над БД
Входящие:
1. Среда
“железо”, ОС, ФС,
Версия Postgres, конфигурация
44. Из чего состоит эксперимент над БД
Входящие:
1. Среда
“железо”, ОС, ФС,
Версия Postgres, конфигурация
2. Объект
Некоторая БД (например, “клон прода”)
45. Из чего состоит эксперимент над БД
Входящие:
1. Среда
“железо”, ОС, ФС,
Версия Postgres, конфигурация
2. Объект
Некоторая БД (например, “клон прода”)
3. Нагрузка
Некоторый набор SQL-запросов
46. Из чего состоит эксперимент над БД
Входящие:
1. Среда
“железо”, ОС, ФС,
Версия Postgres, конфигурация
2. Объект
Некоторая БД (например, “клон прода”)
3. Нагрузка
Некоторый набор SQL-запросов
4. Изменение (может быть несколько значений)
Некоторое изменение конфига Postgres
или, например, новый индекс
47. Из чего состоит эксперимент над БД
Входящие:
1. Среда
“железо”, ОС, ФС,
Версия Postgres, конфигурация
2. Объект
Некоторая БД (например, “клон прода”)
3. Нагрузка
Некоторый набор SQL-запросов
4. Изменение (может быть несколько значений)
Некоторое изменение конфига Postgres
или, например, новый индекс
Результат:
1. Summary
лучше или хуже, в целом?
48. Из чего состоит эксперимент над БД
Входящие:
1. Среда
“железо”, ОС, ФС,
Версия Postgres, конфигурация
2. Объект
Некоторая БД (например, “клон прода”)
3. Нагрузка
Некоторый набор SQL-запросов
4. Изменение (может быть несколько значений)
Некоторое изменение конфига Postgres
или, например, новый индекс
Результат:
1. Summary
лучше или хуже, в целом?
2. Артифакты
любые полезные подробности
49. Из чего состоит эксперимент над БД
Входящие:
1. Среда
“железо”, ОС, ФС,
Версия Postgres, конфигурация
2. Объект
Некоторая БД (например, “клон прода”)
3. Нагрузка
Некоторый набор SQL-запросов
4. Изменение (может быть несколько значений)
Некоторое изменение конфига Postgres
или, например, новый индекс
Результат:
1. Summary
лучше или хуже, в целом?
2. Артифакты
любые полезные подробности
3. Подробный анализ SQL-запросов
каждая группа: лучше или хуже?
+ гистограммы:
ms
query group #
before
after
50. Возможно ли посредством существующих решений?
● Docker
● pgreplay
● pg_stat_***
● auto_explain
● pgBadger (with JSON output)
● AWS EC2 spot instances
— Необходимые “строительные блоки” уже существуют
51. Возможно ли посредством существующих решений?
● Docker
● pgreplay
● pg_stat_***
● auto_explain
● pgBadger (with JSON output)
● AWS EC2 spot instances
— Необходимые “строительные блоки” уже существуют
Nancy CLI: эти (и не только) блоки, интегрированные в единое решение
https://github.com/postgres-ai/nancy
52. DIY automated pipeline for DB experiments and optimization
How to automate database optimization using ecosystem tools and AWS?
Analyze:
● pg_stat_statements
● auto_explan
● pgBadger to parse logs, use JSON output
● pg_query to group queries better
● pg_stat_kcache to analyze FS-level ops
Configuration:
● annotated.conf, pgtune, pgconfigurator, postgresqlco.nf
● ottertune
Suggested indexes (internal “what-if” API w/o actual execution)
● (useful: pgHero, POWA, HypoPG, dexter, plantuner)
Conduct experiments:
● pgreplay to replay logs (different log_line_prefix, you need to handle it)
● EC2 spot instances
Machine learning
● MADlib
pgBadger:
● Grouping queries can be implemented better (see pg_query)
● Makes all queries lower cased (hurts "camelCased" names)*
● Doesn’t really support plans (auto_explain)*
pgreplay and pgBadger are not friends,
require different log formats
*)
Fixed/improved in pgBadger 10.0
53. Postgres.ai — artificial DBA/DBRE assistants
AI-based cloud-friendly platform to automate database administration
53
Steve
AI-based expert in capacity planning and
database tuning
Joe
AI-based expert in query optimization and
Postgres indexes
Nancy
AI-based expert in database experiments.
Conducts experiments and presents
results to human and artificial DBAs
https://Postgres.ai
54. Postgres.ai — artificial DBA/DBRE assistants
AI-based cloud-friendly platform to automate database administration
54
Steve
AI-based expert in capacity planning and
database tuning
Joe
AI-based expert in query optimization and
Postgres indexes
Nancy
AI-based expert in database experiments.
Conducts experiments and presents
results to human and artificial DBAs
https://Postgres.ai
55. Meet Nancy CLI (open source)
Nancy CLI https://github.com/postgres-ai/nancy
● custom docker image (Postgres with extensions & tools)
● nancy prepare-workload to convert Postgres logs (now only .csv)
to workload binary file
● nancy run to run experiments
● able to run locally (any machine) on in EC2 spot instance (low price!),
including i3.*** instances (with NVMe)
● fully automated management of EC2 spots
56. Что внутри docker-контейнера Nancy
Исходники: https://github.com/postgres-ai/nancy/tree/master/docker
Образ: https://hub.docker.com/r/postgresmen/postgres-nancy
Внутри:
● Ubuntu 16.04
● Postgres (9.6, 10, 11)
● postgres_dba на случай ручного “дебаггинга” https://github.com/NikolayS/postgres_dba
● log_min_duration_statement = 0
● pg_stat_statements включены, с track_io_timing = on
● auto_explain опционально
● pgreplay
● pgBadger
● FlameGraph (perf cpu) https://github.com/postgres-ai/nancy/pull/159
57. Nancy CLI – вариант использования
- Детальный анализ SQL-запросов (“clean run”), не затрагивающий “прод”
- Управление изменениями (конфигурация, DDL)
- Регрессионное тестирование при апгрейдах (софта, железа)
- Проверка гипотез оптимизации
- Подбор оптимальной конфигурации
- Генерация обучающих данных для ML-моделей
60. Страхи log_min_duration_statement = 0
Как оценить поток лога при log_min_duration_statement = 0 (быстро и ничего не меняя!):
https://gist.github.com/NikolayS/08d9b7b4845371d03e195a8d8df43408 (внимание на комментарии)
Всего ожидаем ~300 kB/s,
~800 записей в лог в секунду
62. log_destination = syslog
logging_collector = off
или
log_destination = stderr
logging_collector = off
или
log_destination = csvlog
logging_collector = on
Какой вариант выбрать при
интенсивном логировании?
66. # Postgres 9.6.10
pgbench -U postgres -j2 -c24 -T60 -rnf - <<EOF
select;
EOF
All-queries logging with syslog is
● 44x slower compared to “no logging”
● 33x slower compared to stderr /
logging collector
Be careful with syslog / journald
67. ● Оцените IOPS и поток записи
● Проверьте свою систему логирования (syslog/journald может замедлять
всё радикально, подумайте о переходе на STDERR, logging collector)
● Если прогнозируемая нагрузка чрезмерно велика (десятки мегабайт и
более), рассмотрите вариант с сэмплированием
( "SET log_min_duration_statement = 0;" в конкретных, случайно
выбранных сессиях)
Советы для случая log_min_duration_statement = 0
69. Собираем самые “влиятельные” группы запросов для “crafted workload”:
with stats_age(seconds) as (
select extract('epoch' from now() - stats_reset)::numeric
from pg_stat_database
where datname = current_database()
)
select
row_number() over (order by total_time desc),
round(total_time::numeric / (sum(total_time) over (partition by 1))::numeric, 5) as
total_time_ratio,
round(calls::numeric / (sum(calls) over (partition by 1))::numeric, 5) as calls_ratio,
round(total_time::numeric / (select seconds from stats_age), 2) as time_per_second,
round(calls::numeric / (select seconds from stats_age), 2) as calls_second,
total_time,
calls,
rows,
query
from pg_stat_statements
where dbid = (select oid from pg_database where datname = current_database())
order by total_time desc
limit 20
;
70. Nancy real-world examples: seq_page_cost
GitLab.com: random_page_cost = 1.5 and seq_page_cost = 1
Decision was made to switch to seq_page_cost = 4
DB experiments with Nancy CLI were made to check was this decision good in
terms of performance.
Results:
https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/4835#note_106669373
– in general, SQL performance improved ~40%
WIP here, it is an open question, why is it so.
72. Nancy real-world examples: shared_buffers
postila.ru,
Real workload (5 min),
61 GB RAM (ec2 i3.2xlarge),
DB size: ~500GB
Various shared_buffers
values
shared_buffers = 15GB (25%)
If we go from 25% o higher values (~80%), we improve SQL performance ~50%
74. pgbench/pgreplay — на той же машине, что и Postgres
или обязательно отдельно?
FlameGraphs/perf
(thanks Victor Yagofarov!
https://github.com/postgres-ai/nancy/pull/159)
75. pgbench/pgreplay — на той же машине, что и Postgres
или обязательно отдельно?
FlameGraphs/perf
(thanks Victor Yagofarov!
https://github.com/postgres-ai/nancy/pull/159)
«Вклад» pgbench всего 6%
76. Nancy real-world examples: educate yourself
PostgreSQL Documentation “19.5. Write Ahead Log”
https://www.postgresql.org/docs/current/static/runtime-config-wal.html
Just conduct DB experiment with Nancy CLI,
use --keep-alive 3600 and compare!
77. Главное:
● Эксперименты БД — переход от «чёрной магии» к промышленным
методам и решениям, основанным на данных
● Staging DB — как можно ближе к production
● Лучше иметь много “staging DB”. Ещё лучше — создавать по запросу
● Используйте готовые open source решения для того, чтобы знать о
своей БД и нагрузке как можно больше
80. ● plain text pg_dump
○ restoration is very slow (1 vcpu utilized)
○ “logical” – physical structure is lost (cannot experiment with bloat, etc)
○ small (if compressed)
○ “snapshot” only
● pg_dump with either -Fd (“directory”) or -Fc (“custom”):
○ restoration is faster (multiple vCPUs, -j option)
○ “logical” (again: bloat, physical layout is “lost”)
○ small (because compressed)
○ “snapshot” only
● pg_basebackup + WALs, point-in-time recovery (PITR), possibly with help from WAL-E, WAL-G, pgBackRest
○ less reliable, sometimes there issues (especially if 3rd party tools involved - e.g. WAL-E & WAL-G don’t support
tablespaces, there are bugs sometimes, etc)
○ “physical”: bloat and physical structure is preserved
○ not small – ~ size of the DB
○ can “walk in time” (PITR)
○ requires warm-up procedure (data is not in the memory!)
● AWS RDS: create a replica + promote it
○ no Spots :-/
○ Lazy Load is tricky (it looks like the DB is there but it’s very slow – warm-up is needed)
● Snapshots
● Ideas for serialization
○ Stop Postgres / rsync “back” or re-copy locally on NVMe / start Postgres
81. How can we speed up experimental runs?
● Prepare the EC2 instance(s) in advance and keep it
● Prepare EBS volume(s) only (perhaps, using an instance of the different
type) and keep it ready. When attached to the new instance, do warm-up
● Resource re-usage:
○ reuse docker container
○ reuse EC2 instance
○ serialize experimental runs serialization (DDL Do/Undo; VACUUM FULL; cleanup)
● Partial database snapshots (dump/restore only needed tables)
● Filesystem snapshots to have few-second resets
(examples: https://events.yandex.ru/lib/talks/4402/,
https://heapanalytics.com/blog/engineering/testing-database-changes-right-way)
82. The future development of Nancy CLI● ZFS/XFS snapshots to revert PGDATA state within seconds
● FlameGraphs (perf) – DONE https://github.com/postgres-ai/nancy/pull/159
● Support GCP
● More artifacts delivered: pg_stat_kcache, etc
● nancy describe to print the summary + top-N queries – DONE
● nancy describe to print the “diff” for 2+ reports (the summary + numbers for top-30 queries, ordered by
by total time based on the 1st report) – DONE
● Postgres 11 – DONE
● pgbench -i for database initialization – DONE
● pgbench to generate multithreaded synthetic workload – DONE
● Workload analysis: automatically detect “N+1 SELECT” when running workload
● Better support for the serialization of experimental runs
● Better support for multiple runs https://github.com/postgres-ai/nancy/pull/97
○ interval with step – WIP
○ gradient descent
● Provide costs estimation (time + money) – DONE
● Go
Feedback/contributions welcome
https://github.com/postgres-ai/nancy
83. Challenge: security issues
Problem: a developer doesn’t have access to production.
Nancy works with production data/workload.
What about permissions and data protection?
Possible solutions:
● Option 1: allow using Nancy CLI only to those who already have access
production (DBAs, SREs, DBREs)
● Option 2: obfuscate data when preparing a DB clone (no universal
solution yet, TODO)
● Option 3: allow access only to GUI, hide/obfuscate parameters (TODO)
84. Challenge: reliable results
Issues:
1. Single runs is not enough (fluctuations) – must repeat
2. “Before”/”after” runs on 2 different machines / EC2 nodes – “not fair” comparison
(defective hardware, throttling)
Solutions (ideally: combination of them):
● Sequential runs
● 4+ iterations of each experimental run
● “Baseline benchmark” https://github.com/postgres-ai/nancy/issues/94