Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2854.html
Из этого доклада вы узнаете о возможностях репликации и автофейловера PostgreSQL, в том числе о возможностях, ставших доступных в PostgreSQL 10.
Среди прочих, будет затронуты следующие темы:
* Виды репликации и решаемые с ее помощью проблемы.
* Настройка потоковой репликации.
* Настройка логической репликации.
* Настройка автофейловера / HA средствами Stolon и Consul.
После прослушивания доклада вы сможете самостоятельно настраивать репликацию и автофейловер PostgreSQL.
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.
Оптимизация 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).
...
libfpta — обгоняя SQLite и Tarantool / Леонид Юрьев (Positive Technologies)Ontico
HighLoad++ 2017
Зал «Найроби + Касабланка», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2837.html
Представление "Позитивных таблиц" – нового C/C++ движка, выполняющего до полумиллиона пишущих транзакций в секунду к табличным и key-value данным, и одновременно до миллиона читающих запросов на каждом ядре процессора.
Компания Positive Technologies производит программные продукты в области информационной безопасности, в том числе обеспечивающие предотвращение вторжений и мониторинг событий безопасности, в том числе на крупномасштабных объектах относящихся к критической инфраструктуре. Для ряда таких продуктов потребовалось разделяемое оперативное хранилище.
...
Эффективная отладка репликации MySQL / Света Смирнова (Percona)Ontico
Репликация - одна из ключевых возможностей MySQL. Лёгкая в установке, позволяющая производить изменения и на мастере, и на слейве, что в свою очередь позволяет создавать сколь угодно сложные развёртывания. Репликация в MySQL асимметричная, допускающая некоторый уровень синхронизации при помощи semi-sync replication plugin. Начиная с версии 5.7 поддерживает одновременную репликацию с нескольких мастеров на один слейв.
Простота использования имеет свою обратную сторону: при проектировании репликации достаточно легко выбрать неправильное решение и познакомиться со всеми его подводными камнями.
В рамках этого доклада я расскажу об особенностях репликации MySQL, типичных ошибках и способах борьбы с ними. Мы затронем как проблемы, приводящие к появлению неожиданных данных и десинхронизации, так и производительность.
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2854.html
Из этого доклада вы узнаете о возможностях репликации и автофейловера PostgreSQL, в том числе о возможностях, ставших доступных в PostgreSQL 10.
Среди прочих, будет затронуты следующие темы:
* Виды репликации и решаемые с ее помощью проблемы.
* Настройка потоковой репликации.
* Настройка логической репликации.
* Настройка автофейловера / HA средствами Stolon и Consul.
После прослушивания доклада вы сможете самостоятельно настраивать репликацию и автофейловер PostgreSQL.
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.
Оптимизация 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).
...
libfpta — обгоняя SQLite и Tarantool / Леонид Юрьев (Positive Technologies)Ontico
HighLoad++ 2017
Зал «Найроби + Касабланка», 8 ноября, 13:00
Тезисы:
http://www.highload.ru/2017/abstracts/2837.html
Представление "Позитивных таблиц" – нового C/C++ движка, выполняющего до полумиллиона пишущих транзакций в секунду к табличным и key-value данным, и одновременно до миллиона читающих запросов на каждом ядре процессора.
Компания Positive Technologies производит программные продукты в области информационной безопасности, в том числе обеспечивающие предотвращение вторжений и мониторинг событий безопасности, в том числе на крупномасштабных объектах относящихся к критической инфраструктуре. Для ряда таких продуктов потребовалось разделяемое оперативное хранилище.
...
Эффективная отладка репликации MySQL / Света Смирнова (Percona)Ontico
Репликация - одна из ключевых возможностей MySQL. Лёгкая в установке, позволяющая производить изменения и на мастере, и на слейве, что в свою очередь позволяет создавать сколь угодно сложные развёртывания. Репликация в MySQL асимметричная, допускающая некоторый уровень синхронизации при помощи semi-sync replication plugin. Начиная с версии 5.7 поддерживает одновременную репликацию с нескольких мастеров на один слейв.
Простота использования имеет свою обратную сторону: при проектировании репликации достаточно легко выбрать неправильное решение и познакомиться со всеми его подводными камнями.
В рамках этого доклада я расскажу об особенностях репликации MySQL, типичных ошибках и способах борьбы с ними. Мы затронем как проблемы, приводящие к появлению неожиданных данных и десинхронизации, так и производительность.
Из презентации вы узнаете:
— как мы пришли к Go, оставив идею использования Node.js, Scala или Rust;
— про первый сервис, который мы написали на Go и запустили в продакшен;
— про ошибки, с которыми сталкивались под нагрузкой;
— про оптимизации, которые мы сделали и еще планируем сделать;
— про тестирование и предотвращение тестирования на продакшене (в частности, websocket'ов).
В ногу со временем, или как делать upgrade PostgreSQL / Андрей Сальников (Dat...Ontico
HighLoad++ 2017
Зал «Кейптаун», 7 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3082.html
Любое обновление чего-либо в продакшне - это проблема для администраторов, да и для всей компании в общем. И это особенная проблема, когда необходимо обновлять версию базы данных, и самый пик проблематичности, когда эта база - основное место хранения всех критически важных данных для проекта.
...
Alexandr Serbul "The Rust language for a high-load network service - a quick ...Fwdays
In this talk, we will talk about the evolution of the development of a high-load network cluster for sending push notifications using technologies from Unix / bash and PHP to asynchronous non-blocking multithreaded connections based on Rust / Tokio. Let's talk about the intricacies of Rust development, language features, pitfalls, and ways to quickly learn and use it for web developers with LAMP skills. Let's also talk about Go, Java, and the reasons for our technological decisions.
The talk will be useful for developers wishing to master the latest and popular Rust programming language, functional programming, Haskell ideas with PHP / Python / JavaScript web development experience.
Девять кругов ада или PostgreSQL Vacuum / Алексей Лесовский (PostgreSQL-Consu...Ontico
Если вы сталкивались с PostgreSQL и зашли дальше, чем инструкция по установке, то, скорей всего, коротко познакомились с вакуумом, ну или, как минимум, что-то слышали про него.
Вакуум или по-русски очистка - это важная задача в жизненном цикле постгреса, которая заключается в регулярном освобождении базы данных от, так скажем, "мусора". Вакуум очень важен, его нельзя игнорировать и тем более отключать; более того, ему следует уделять должное внимание. А за кажущейся простотой скрывается довольно сложный и интересный механизм, к работе которого очень часто возникает много вопросов, на которые не всегда можно найти однозначный ответ.
В этом докладе я буду рассказывать про внутреннее устройство вакуума и раскрою следующие вопросы:
1) Что такое автовакуум (вакуум) и заморозка, и как они устроены изнутри.
2) Какие решения принимаются в процессе обработки таблиц и индексов.
3) Какие существуют возможности для управления вакуумом и как эти возможности влияют на работу вакуума.
4) Вакуум и вопрос производительности.
Язык Lua — секреты производительности / Ник Заварицкий (Mail.ru)Ontico
Lua — высокоуровневый язык, похожий на Python/JS, но существенно более простой. Он гибкий и при этом очень быстрый.
Многие слышали про OpenResty. Это решение для разработки Nginx модулей на Lua. Cloudflare, крупнейший CDN/anti-DDOS провайдер, как раз работает на OpenResty.
У нас была задача валидации данных на соответствие схеме; мы переписали валидацию с Си на Lua и получили ускорение в 4 раза (за счет JIT-компиляции).
Что будет в докладе:
* краткое введение в язык Lua;
* как работает трассирующий JIT-компилятор Lua;
* как писать быстрый код, искать и устранять проблемы с производительностью;
* наш опыт: как мы ускорились в 4 раза, переписав валидацию с Си на Lua.
Что нового в nginx? / Максим Дунин (Nginx, Inc.)Ontico
Что нового появилось в nginx за последнее время и для чего всё это нужно?
В докладе - рассказ про основные новые функции в nginx 1.9.x (1.10.x) и 1.11.x. HTTP/2, модуль stream, динамическая загрузка модулей и так далее - зачем всё это нужно и как это использовать.
Читаем CHANGES вместе и разбираем на примерах.
#RuPostges в Yandex, эпизод 3. Что же нового в PostgreSQL 9.6Nikolay Samokhvalov
Первый релиз-кандидат версии 9.6 вышел 1 сентября, а это значит, что совсем скоро будет полноценный релиз. Все вокруг уже успели обсудить новинки, и теперь уже стыдно ничего не знать о таких вещах, как параллелизация выполнения запросов, pushdown для FDW, мониторинг waitlocks, полнотекстовый поиск по фразам или магический \gexec в psql. Чтобы никому не приходилось краснеть, мы быстро пройдёмся по всем основным и интересным моментам версии 9.6.
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 — сегодня же, в день док
Пайплайн машинного обучения на Apache Spark / Павел Клеменков (Rambler&Co)Ontico
В докладе рассмотрим нашу старую архитектуру пайплайна машинного обучения, обратим внимание на ее недостатки как с точки зрения инфраструктуры и автоматизации, так и с точки зрения настройки моделей машинного обучения и проведения экспериментов. Разберемся с архитектурой Apache Spark, и почему мы решили его использовать. Подробно ознакомимся с новой архитектурой нашего пайплайна и тем, как она позволила оптимизировать обнаружение и устранение проблем, ускорила и упростила работу data scientist'ов по проведению экспериментов и доведения их до продакшена. Также затронем вопросы написания тестов и процесса разработки ПО на больших данных.
Как сделать ваш JavaScript быстрее / Роман Дворнов (Авито)Ontico
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
DevConf 2016
"Производительность MySQL: что нового?", Алексей Копытов
Алексей Копытов — разработчик MySQL и связанных с ним проектов с 2004г. Работал в компаниях MySQL AB, Sun Microsystems и Oracle. В компании Percona участвовал в разработке Percona Server, XtraBackup и XtraDB Cluster. В настоящее время занимается проблемами производительности MySQL на современном оборудовании.
MySQL 5.7 предлагает огромное количество улучшений в производительности практически всех компонентов: InnoDB, секционирования, бэкапов, репликации, DDL и оптимизаторе запросов.
В этом докладе мы рассмотрим эти оптимизации подробно, а также поговорим о проблемах, которые остаются актуальными до сих пор, возможных методах их решения и планируемых дальнейших оптимизациях в MySQL 8.
Отладка производительности приложения на Erlang / Максим Лапшин (Erlyvideo)Ontico
Байткод эрланга выполняет очень хорошо отлаженная виртуальная машина BEAM, которая превосходно работает даже на современных 72-х и более ядерных компьютерах.
Ключевая возможность эрланга в том, чтобы использовать все ядра в одном приложении, т.е. иметь в памяти одни и те же данные и обеспечивать к ним доступ без запуска кучи экземпляров одного и того же приложения по количеству ядер.
С ростом обрабатываемого трафика данных начинают возникать проблемы с многоядерным доступом к данным, возникают бутылочные горлышки и более низкоуровневые проблемы синхронизации.
В этом докладе будет рассказано, какие есть методы поиска, анализа, замера и устранения различных проблем, связанных с многотредностью: синглтонные процессы, простаивания на мьютексах и т.п.
Из презентации вы узнаете:
— как мы пришли к Go, оставив идею использования Node.js, Scala или Rust;
— про первый сервис, который мы написали на Go и запустили в продакшен;
— про ошибки, с которыми сталкивались под нагрузкой;
— про оптимизации, которые мы сделали и еще планируем сделать;
— про тестирование и предотвращение тестирования на продакшене (в частности, websocket'ов).
В ногу со временем, или как делать upgrade PostgreSQL / Андрей Сальников (Dat...Ontico
HighLoad++ 2017
Зал «Кейптаун», 7 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3082.html
Любое обновление чего-либо в продакшне - это проблема для администраторов, да и для всей компании в общем. И это особенная проблема, когда необходимо обновлять версию базы данных, и самый пик проблематичности, когда эта база - основное место хранения всех критически важных данных для проекта.
...
Alexandr Serbul "The Rust language for a high-load network service - a quick ...Fwdays
In this talk, we will talk about the evolution of the development of a high-load network cluster for sending push notifications using technologies from Unix / bash and PHP to asynchronous non-blocking multithreaded connections based on Rust / Tokio. Let's talk about the intricacies of Rust development, language features, pitfalls, and ways to quickly learn and use it for web developers with LAMP skills. Let's also talk about Go, Java, and the reasons for our technological decisions.
The talk will be useful for developers wishing to master the latest and popular Rust programming language, functional programming, Haskell ideas with PHP / Python / JavaScript web development experience.
Девять кругов ада или PostgreSQL Vacuum / Алексей Лесовский (PostgreSQL-Consu...Ontico
Если вы сталкивались с PostgreSQL и зашли дальше, чем инструкция по установке, то, скорей всего, коротко познакомились с вакуумом, ну или, как минимум, что-то слышали про него.
Вакуум или по-русски очистка - это важная задача в жизненном цикле постгреса, которая заключается в регулярном освобождении базы данных от, так скажем, "мусора". Вакуум очень важен, его нельзя игнорировать и тем более отключать; более того, ему следует уделять должное внимание. А за кажущейся простотой скрывается довольно сложный и интересный механизм, к работе которого очень часто возникает много вопросов, на которые не всегда можно найти однозначный ответ.
В этом докладе я буду рассказывать про внутреннее устройство вакуума и раскрою следующие вопросы:
1) Что такое автовакуум (вакуум) и заморозка, и как они устроены изнутри.
2) Какие решения принимаются в процессе обработки таблиц и индексов.
3) Какие существуют возможности для управления вакуумом и как эти возможности влияют на работу вакуума.
4) Вакуум и вопрос производительности.
Язык Lua — секреты производительности / Ник Заварицкий (Mail.ru)Ontico
Lua — высокоуровневый язык, похожий на Python/JS, но существенно более простой. Он гибкий и при этом очень быстрый.
Многие слышали про OpenResty. Это решение для разработки Nginx модулей на Lua. Cloudflare, крупнейший CDN/anti-DDOS провайдер, как раз работает на OpenResty.
У нас была задача валидации данных на соответствие схеме; мы переписали валидацию с Си на Lua и получили ускорение в 4 раза (за счет JIT-компиляции).
Что будет в докладе:
* краткое введение в язык Lua;
* как работает трассирующий JIT-компилятор Lua;
* как писать быстрый код, искать и устранять проблемы с производительностью;
* наш опыт: как мы ускорились в 4 раза, переписав валидацию с Си на Lua.
Что нового в nginx? / Максим Дунин (Nginx, Inc.)Ontico
Что нового появилось в nginx за последнее время и для чего всё это нужно?
В докладе - рассказ про основные новые функции в nginx 1.9.x (1.10.x) и 1.11.x. HTTP/2, модуль stream, динамическая загрузка модулей и так далее - зачем всё это нужно и как это использовать.
Читаем CHANGES вместе и разбираем на примерах.
#RuPostges в Yandex, эпизод 3. Что же нового в PostgreSQL 9.6Nikolay Samokhvalov
Первый релиз-кандидат версии 9.6 вышел 1 сентября, а это значит, что совсем скоро будет полноценный релиз. Все вокруг уже успели обсудить новинки, и теперь уже стыдно ничего не знать о таких вещах, как параллелизация выполнения запросов, pushdown для FDW, мониторинг waitlocks, полнотекстовый поиск по фразам или магический \gexec в psql. Чтобы никому не приходилось краснеть, мы быстро пройдёмся по всем основным и интересным моментам версии 9.6.
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 — сегодня же, в день док
Пайплайн машинного обучения на Apache Spark / Павел Клеменков (Rambler&Co)Ontico
В докладе рассмотрим нашу старую архитектуру пайплайна машинного обучения, обратим внимание на ее недостатки как с точки зрения инфраструктуры и автоматизации, так и с точки зрения настройки моделей машинного обучения и проведения экспериментов. Разберемся с архитектурой Apache Spark, и почему мы решили его использовать. Подробно ознакомимся с новой архитектурой нашего пайплайна и тем, как она позволила оптимизировать обнаружение и устранение проблем, ускорила и упростила работу data scientist'ов по проведению экспериментов и доведения их до продакшена. Также затронем вопросы написания тестов и процесса разработки ПО на больших данных.
Как сделать ваш JavaScript быстрее / Роман Дворнов (Авито)Ontico
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
DevConf 2016
"Производительность MySQL: что нового?", Алексей Копытов
Алексей Копытов — разработчик MySQL и связанных с ним проектов с 2004г. Работал в компаниях MySQL AB, Sun Microsystems и Oracle. В компании Percona участвовал в разработке Percona Server, XtraBackup и XtraDB Cluster. В настоящее время занимается проблемами производительности MySQL на современном оборудовании.
MySQL 5.7 предлагает огромное количество улучшений в производительности практически всех компонентов: InnoDB, секционирования, бэкапов, репликации, DDL и оптимизаторе запросов.
В этом докладе мы рассмотрим эти оптимизации подробно, а также поговорим о проблемах, которые остаются актуальными до сих пор, возможных методах их решения и планируемых дальнейших оптимизациях в MySQL 8.
Отладка производительности приложения на Erlang / Максим Лапшин (Erlyvideo)Ontico
Байткод эрланга выполняет очень хорошо отлаженная виртуальная машина BEAM, которая превосходно работает даже на современных 72-х и более ядерных компьютерах.
Ключевая возможность эрланга в том, чтобы использовать все ядра в одном приложении, т.е. иметь в памяти одни и те же данные и обеспечивать к ним доступ без запуска кучи экземпляров одного и того же приложения по количеству ядер.
С ростом обрабатываемого трафика данных начинают возникать проблемы с многоядерным доступом к данным, возникают бутылочные горлышки и более низкоуровневые проблемы синхронизации.
В этом докладе будет рассказано, какие есть методы поиска, анализа, замера и устранения различных проблем, связанных с многотредностью: синглтонные процессы, простаивания на мьютексах и т.п.
Эксперименты с Postgres в Docker и облаках — оптимизация настроек и схемы ва...Nikolay Samokhvalov
Администрирование баз данных в будущем будет полностью автоматизировано. Это уже так для базовых операций 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-конвейер?
Промышленный подход к тюнингу PostgreSQL: эксперименты над базами данныхNikolay Samokhvalov
Shared_buffers = 25% – это много или мало? Или в самый раз? Как понять, подходит ли эта – довольно устаревшая – рекомендация в вашем конкретном случае?
Пришло время подойти к вопросу подбора параметров postgresql.conf "по-взрослому". Не с помощью слепых "автотюнеров" или устаревших советов из статей и блогов, а на основе:
строго выверенных экспериментов на БД, производимых автоматизированно, в больших количествах и в условиях, максимально приближенных к "боевым",
глубокого понимания особенностей работы СУБД и ОС.
Используя Nancy CLI (https://gitlab.com/postgres.ai/nancy), мы рассмотрим конкретный пример – пресловутые shared_buffers – в разных ситуациях, в разных проектах и попробуем разобраться, как же подобрать оптимальную настройку для нашей инфраструктуры, БД и нагрузки.
https://pgconf.ru/2019/242809
Руслан Гроховецкий "Как Python стал делать погоду в Яндексе"Yandex
2 июля 2011, Я.Субботник в Екатеринбурге
Руслан Гроховецкий "Как Python стал делать погоду в Яндексе"
О докладе:
Про Python и Django: зачем нужна красота и простота перфекционистам с дедлайнами, на примере Яндекс.Погоды.
Когда число сервисов, которые делаются в Яндексе, стало возрастать, дедлайны — поджимать, а от процесса разработки требовалось стать более гибким, возникла потребность в свежих решениях. В докладе на примере Яндекс.Погоды рассказывается, как в Яндексе делают сервисы с помощью языка Python и веб-фреймворка Django.
Tech Talks @NSU: Как приручить дракона: введение в LLVMTech Talks @NSU
http://techtalks.nsu.ru
Видеозапись: http://www.youtube.com/watch?v=v7uBLSm6ft8
06 октября 2015. Как приручить дракона: введение в LLVM (Дмитрий Кашицын, HDsoft)
«В этом докладе мы кратко расскажем о таком звере, о котором много кто слышал, но немногие щупали. Что такое компилятор на самом деле? Чем LLVM отличается от других компиляторов? Как в LLVM происходит компиляция программы, как работают оптимизации? Наконец, какой путь проходит программа от разбора исходного текста до генерации исполняемого файла?
Лекция будет обзорной и не потребует от слушателей глубоких знаний теории компиляторов.»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
10 июня 2015. Дмитрий Кашицын (HDsoft) дает обзор LLVM.
http://techtalks.nsu.ru
Видеозапись: https://plus.google.com/events/ctes98f7uhf19t5jlvlbk24dan4
В этом докладе мы кратко расскажем о таком звере, как LLVM, о котором много кто слышал, но немногие щупали. Что такое компилятор на самом деле? Чем LLVM отличается от других компиляторов? Как в LLVM происходит компиляция программы, как работают оптимизации? Наконец, какой путь проходит программа от разбора исходного текста до генерации исполняемого файла?
Лекция будет обзорной и не потребует от слушателей глубоких знаний теории компиляторов.
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Продолжаем говорить о микрооптимизациях .NET-приложенийAndrey Akinshin
Этот доклад продолжает тему моего выступления с прошлого DotNext про сложную науку о микрооптимизациях. Вас ждут новые увлекательные истории о том, что же происходит под капотом .NET-программ. Будем обсуждать различия разных C# и JIT компиляторов (Roslyn и RyuJIT в том числе), медитировать на IL и ASM листинги, а также разбираться с особенностями современных CPU.
Последние новости постгреса с PGCon / О.Бартунов, А.Коротков, Ф.Сигаев (Postg...Ontico
Как быстро развивается сейчас PostgreSQL — общеизвестно. За несколько дней до РИТ++ заканчивается главный мировой форум разработчиков этой СУБД — конференция PGCon в Канаде. Большая команда разработчиков Postgres Professional принимает участие в этой конференции и готова рассказать все последние новости прямо с PGCon.
Параллельное исполнение запросов, новые стораджи, неутихающая тема Postgres vs key-value storage, распределенный Postgres, высокая доступность, многочисленные улучшения производительности, планы и интриги разработчиков — вот основные темы этой конференции.
Я остановлюсь подробнее на нашем вкладе в ожидаемый релиз 9.6 и планах на, возможно, релиз 10.0.
4. Разработка ядра PostgreSQL:
ЖЕСТЬ !
● Идея должна быть понятной сообществу и одобрена
(«правильный» use-case)
● Методы и подходы должны быть обсуждены (PR, поиск
спонсоров)
● Вы должны успеть подать на коммитфест до “feature freeze”
● Реализация должна пройти коммитфест
● Всегда найдется “умник”, которому не понравится
● Вид вашего кода – отступы, trailing white-spaces
● Названия переменных и функций
● Отсутствие должного количества комментариев, документации
● Ваша медленная реакция на замечания
5. История разработки KNN
●
Начало проекта - Sep 8, 2007 at 7:54 PM
date Sat, Sep 8, 2007 at 7:54 PM
subject Chat with Sergey V. Karpov
7:36 PM me: я тут knn-search занимаюсь, масса интересного. Все
думаю, как в постгресе это поиметь
Sergey: а что это такое?
7:37 PM me: k-nearest соседей - супер важная задача
найти 5 ближайших точек
7:38 PM Sergey: ближайших к чему?
me: к заданной точке
7:39 PM Sergey: в какой системе координат?
me: в любой, в n-мерном пространстве. В простом варианте - хотя
бы на земле/небе
7:40 PM это нужно для поиска похожих картинок, например.
навиный вариант повторять запросы - не катит
6. История разработки KNN
● TODO (http://www.sai.msu.su/~megera/wiki/TODO)
начало 2008 года, уже есть понимание что делать
● 25 июня 2009 года – письмо Paul Ramsey (POSTGIS)
● 10 июля 2009 года – контракт Open Planning Project Inc.
● 20 ноября 2009 года – патч KNNGiST v.0.1 (модуль расш)
● Commitfest nightmare
– 22 июля 2010 – KNNGiST (v.0.8), commitfest
– 13 сентября 2010 – KNNGiST (v.0.9)
– 03 декабря 2010 – Tom Lane committed for 9.1 !
– 21 января 2011 – contrib/btree_gist committed !
7. История разработки KNN
● Итого: На проект ушло больше 3 лет !
● Реальное программирование заняло несколько месяцев
● Основные причины:
– Отсутствие поддержки
● Слабая информационная связь разработчиков и заказчиков
– Занятость разработчиков
– Усложнение процедуры рассмотрения проектов в сообществе
8. Расписание CommitFest'ов и
релизов
https://commitfest.postgresql.org/
● 1-30 сентября 2015 : CF 1
● 1-30 ноября 2015 : CF 2
● 2 января — 8 февраля 2016 : CF 3
● 7 января 2016 : 9.5 Release
● 1-31 марта 2016 : Финальный CF для 9.6
● 8 апреля : Feature Freeze
● Июнь 2016 : 9.6 beta
● Сентябрь 2016 : 9.6 release
● 1-30 сентября 2016 : CF 1 для 9.7 ….
9. Что в PostgreSQL 9.5 ?
● Table Sample (SQL:2003)
● Grouping sets (многоуровневая группировка)
● BRIN-индексы
● UPSERT
● Row-Level Security
● Функции для JSONB
● SKIP LOCKED
● Параллельный VACUUM
● GiST Index Only Scans
● Abbreviated keys (ускорение сортировки)
Этоневсё
10. Table Sample
● Задача: получить выборку, достаточную для статистики.
SELECT avg(salary) FROM emp TABLESAMPLE SYSTEM (50);
SELECT avg(salary) FROM emp TABLESAMPLE BERNOULLI (50);
SELECT avg(salary) FROM emp TABLESAMPLE BERNOULLI (50)
REPEATABLE(100);
Агрегация выполняется не по всей таблице, а по 50%.
SYSTEM- постранично, Бернулли — по записям.
DELETE FROM emp TABLESAMPLE BERNOULLI (50);
11. Grouping Sets
Несколько группировок
за один запрос.
SELECT brand, size, sum(sales)
FROM items_sold
GROUP BY GROUPING SETS
((brand), (size), ());
brand | size | sum
---------------+------+-----
Большевичка | | 30
Трехгорная М | | 20
| L | 15
| M | 35
| | 50
(5 rows)
13. BRIN (Block Range) - индексы
Lossy!CREATE INDEX brin_index_test ON test_data
USING brin(id)
WITH (pages_per_range = 128);
● Индексируются не записи, а страницы. Внутри страницы —
sequence scan
● Хорошо подходит для append-only таблиц
● Быстро строится и занимает очень
мало места
● Ищет медленнее, чем B-Tree
15. UPSERT (MERGE)
INSERT … ON CONFLICT ….
CREATE TABLE x (y INT PRIMARY KEY);
INSERT INTO x VALUES (1);
INSERT INTO x VALUES (1)
ON CONFLICT DO NOTHING;
INSERT INTO x VALUES (1)
ON CONFLICT DO UPDATE SET y=2;
16. UPSERT (MERGE)
CREATE TABLE x (id INT PRIMARY KEY, name TEXT);
INSERT INTO x VALUES (1, 'Веники');
INSERT INTO x VALUES (1, 'Вареники')
ON CONFLICT DO UPDATE SET name=EXCLUDED.name;
17. Row-Level Security
В postgresql.conf
row_security = on
CREATE TABLE orders (id INT, data TEXT, owner TEXT);
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY order_access ON orders FOR ALL TO PUBLIC
USING (owner = CURRENT_USER);
GRANT ALL ON TABLE orders TO PUBLIC;
Каждый пользователь увидит
только свои записи
18. Операторы и функции для JSONB
SELECT '{"x":2, "y":3}'::JSONB || '{"x":10}'::JSONB;
UPDATE t SET data = data || '{"key":"value"}'::JSONB;
?column?
-------------------
{"x": 10, "y": 3}
(1 row)
19. SKIP LOCKED
SELECT * FROM tasks FOR UPDATE;
--- Ждать
SELECT * FROM tasks FOR UPDATE NOWAIT;
--- Не ждать; ошибка, если есть блокировки
SELECT * FROM tasks FOR UPDATE SKIP LOCKED;
--- Не ждать; получить только незаблокированные
20. Ускорение сортировки
● Проблема: Сравнение в постгресе для типа text очень медленное,
используется strcoll(), которая учитывает локаль, но в 1000 раз
медленнее, чем сравнение целых чисел.
● Abbreviated keys (укороченные ключи) для сортировки character(n),
bytea, uuid, numeric (Peter Geoghegan):
– ГРУБО: Строки преобразуются в бинарные ключи
strxfrm()),сравниваются первые 8 байт как целые числа, если
эти 8 байт одинаковые, то вызываем strcoll()
● Великолепный доклад Greg Stark «Sorting through the ages»
https://pgconf.ru/media/2016/02/19/9%20%D0%A1%D1%82%D0%B
0%D1%80%D0%BA.pdf
23. Ускорение сортировки
● Однако, не все так просто. В некоторых версиях glibc strcoll() не «матчит» strxfrm(),
поэтому использование abbreviated keys может приводить к проблемам, например, к
«битым» индексам.
● Например, проблема есть в
– Debian 6.0.1
– CentOS release 6.7 (Final)
● Описание проблемы
http://www.postgresql.org/message-id/111D0E27-A8F3-4A84-A4E0-B0FB703863DF@s24
.com
24. commit 8aa6e97805a79eb30ac9c36acb1126280c2ffbdfESC[m
Author: Robert Haas <rhaas@postgresql.org>
Date: Wed Mar 23 15:58:34 2016 -0400
Disable abbreviated keys for string-sorting in non-C locales.
Unfortunately, every version of glibc thus far tested has bugs whereby
strcoll() ordering does not match strxfrm() ordering as required by
the standard. This can result in, for example, corrupted indexes.
Disabling abbreviated keys in these cases slows down non-C-collation
string sorting considerably, but there seems to be no practical
alternative. Users who are confident that their libc implementations
are solid in this regard can re-enable the optimization by compiling
with TRUST_STRXFRM.
Users who have built indexes using PostgreSQL 9.5 or PostgreSQL 9.5.1
should REINDEX if there is a possibility that they may have been
affected by this problem.
Report by Marc-Olaf Jaschke. Investigation mostly by Tom Lane, with
help from Peter Geoghegan, Noah Misch, Stephen Frost, and me. Patch
by me, reviewed by Peter Geoghegan and Tom Lane.
25. Ускорение сортировки
● Что же делать нам с нашей локалью !!??
● Postgres Pro имеет поддержку ICU (--with-icu) для обеспечения системо-
независимой локали (важно для 1С, в частности). ICU быстрее и обеспечивает
корректную работу abbreviated keys.
● Пример Роберта Хааса из
http://www.postgresql.org/message-id/CA+TgmoaTiYy9aaMRe7m71Z=mrNZ_aPqepspQ
HtSNHq8Wiafjow@mail.gmail.com
26. Ускорение сортировки
create table stuff as select random()::text as a, 'filler
filler filler'::text as b, g as c from generate_series(1, 1000000) g;
create index on stuff (a);
Pgpro 9.5.0.1 (--with icu) Vanilla REL9_5_STABLE (no abbrev.)
2.3 sec 30 sec
Эффект abbreviated keys не должен быть заметен:
create table stuff as select 'aaaaaaaa' || random()::text as
a, 'filler filler filler'::text as b, g as c from generate_series(1,
1000000) g;
Pgpro 9.5.0.1 (--with icu) Vanilla REL9_5_STABLE (no abbrev.)
11.4 sec 32 sec
28. Что такое Postgres Pro ?
1.Российский форк PostgreSQL, вошедший в Реестр
Российского ПО
2.Наши разработки ядра PostgreSQL, которые ещё не успели
войти в релиз, но закоммичены в апстрим
3.Бэкпорты из 9.6, которые мы считаем полезными
4.Полезные расширения (не только наши)
5.Возможность оперативно реагировать на запросы клиентов
Postgres Pro предоставляет доступ к новой функциональности и улучшениям
раньше, и позволяет быстрее реагировать на запросы клиентов
29. Что еще есть в Postgres Pro ?
● Увеличение производительности на многоядерных системах:
● Улучшение полнотекстового поиска:
поиск фраз, словарь=extension,
словари в shared memory
● Покрывающие индексы. Поддержка конструкции INCLUDES в
CREATE INDEX. https://pgconf.ru/2016/89847
● Переносимость: ICU
● Модуль pg_trgm: нечеткий поиск подстроки
● Модуль pageinspect: доступ к внутреннему представлению данных
● Модуль sr_plan: сохранение планов запросов
● Модуль dump_stat: дамп и восстановление статистики
● Модуль JSQuery
● Мониторинг ожиданий (WAIT-мониторинг с сэмплингом)
● Libpq с поддержкой failover
30. Скоро в Postgres Pro (9.5.*)
● Секционирование таблиц без накладных расходов
● Инкрементальный бэкап на уровне блоков
● Компрессия B-Tree индексов
● Миллисекундный полнотекстовый поиск (на основе CREATE
ACCESS METHOD и Custom WAL)
https://wiki.postgresql.org/images/2/25/Full-text_search_in_PostgreSQL_in_milliseconds
-extended-version.pdf
● Мониторинг ожиданий
http://akorotkov.github.io/blog/2016/08/26/wait_monitoring_9_6/ ,
http://www.postgresql.org/docs/devel/static/monitoring-stats.html#WAIT-EVENT-TABLE
32. Секционирование
Уже сделано в Postgres Pro (расширение pathman):
● Хранение метаданных секций
● Бинарный поиск по ним при планировании запроса
● RANGE partitioning
До сих пор:
● Делается через наследование таблиц (мега-костыль ?)
● Работает неэффективно
33. Секционирование (планы на 9.6)
● Выбор секций во время выполнения запроса
● Упорядоченная выдача выборок из секций для
ускорения Merge join и сортировки.
● Оптимизация Hash join при секционировании по
ключу JOIN
● LIST-partitioning
● HASH-partitioning
● Поддержка декларативного синтаксиса
36. Планы Postgres Pro
● Компрессия данных
● Система управления кластером СУБД
● Упрощение миграции с Oracle
● Пакеты, автономные транзакции, глобальные переменные
● Улучшение мониторинга
● Частичный бэкап и восстановление
● JIT-компиляция SQL-запросов. Использование GPU.
● InMemory и колоночные хранилища
● Совершенствование кластера
37. Что ждёт нас «завтра» (9.6)?
● Параллельное исполнение запроса
– Seqscan
– Join
– Aggregates
– Explain analyze показывает информацию по каждому
воркеру
– Parallel create GIN index ?
– FDW pushdown
40. Завтра (9.6). Расширяемость
● Create access method
● Custom WAL records ?
Можно будет создавать полноценные методы доступа
как расширения !
41. Завтра (9.6). DBA
● Немного счастья для DBA
– VACUUM FREEZE не будет трогать уже «замороженные»
блоки — сильное облегчение для больших и нагруженных
проектов
– idle_in_transaction_session_timeout - решает проблему «idle in
transaction"
– a generic command progress reporting facility
– simple VACUUM progress reporting — можно следить за
выполнением вакуума pg_stat_progress_vacuum.
44. Завтра (9.6) ….
● ev — редактирование представлений
● sv — показ
● KNN для CUBE
● TSVECTOR EDITING FUNCTIONS
convert tsvector to/from text array, set weight for given lexemes, delete
lexeme(s), unnest, filter lexemes with given weights
● Улучшена поддержка словарей
● Поиск фраз ?
● Covering indexes ?
● Btree-compression ?
● Масштабирование на большое количество ядер ?
45. Что будет в «10.0» (в работе)
● BDR — двунаправленная репликация
http://2ndquadrant.com/en/resources/bdr/
● Pglogical (5x быстрее slony, londiste3)
http://2ndquadrant.com/en/resources/pglogical/
● Declarative partitioning (+pg_pathman)
● Highly Available multi-master
● Инкрементальный бэкап
● Миллисекундный полнотекстовый поиск
● In-memory
47. 50 способов помочь сообществу
Ядро
Разработка, review, тестирование, reporting
bugs
Экосистема
Расширения, драйверы, ORM, средства
мониторинга… поддержка Pg в
прикладном ПО
Создание дистрибутивов, пакетирование
Документация
Улучшение, перевод, публикация статей,
книг, учебных, маркетинговых
материалов…блоггинг!
Расскажите о своей истории с PostgreSQL!
Общение, образование
Создание локальных
сообществ
Проведение конференций,
митапов, семинаров, учебных
курсов.
Внедрите PostgreSQL!
В Вашей компании. Запустите
учебный курс в Вашем ВУЗе
Спонсорство
Спонсируйте разработку
нужной Вам
функциональности.
Спонсируйте мероприятие.
48. СПАСИБО ЗА ВНИМАНИЕ !
info@postgrespro.ru
jobs@postgrespro.ru
sales@postgrespro.ru
www.postgrespro.ru