#RuPostgresLive 4: как писать и читать сложные SQL-запросыNikolay Samokhvalov
Онлайн-опросы неизменно показывают — всех нас очень интересуют две вещи: а) как писать наиболее эффективные SQL-запросы, б) как «читать» такие запросы, а точнее, как понимать, что именно делает или будет делать СУБД при их выполнении.
Эти две неразрывно связанные друг с другом темы чрезвычайно обширны, SQL-искусству можно (и нужно) учиться годами. Во время нашей очередной встречи в прямом эфире мы затронем некоторые аспекты обеих.
ЧАСТЬ 1: EXPLAIN
Алексей Ермаков. Как читать и интерпретировать вывод команды EXPLAIN
Команда EXPLAIN — основной инструмент анализа запросов, позволяющий разобраться, каким образом запрос будет выполняться и как можно его ускорить. Для сложных запросов вывод может быть довольно громоздким и его становится сложно читать. Я расскажу, из каких частей состоит план запроса, на какие «маркеры» в нём следует обращать внимание в первую очередь и как на это реагировать.
ЧАСТЬ 2: ADVANCED SQL
Николай Самохвалов. SQL современный и «продвинутый»
«Я не волшебник, я только учусь». Продвинутому SQL нас постоянно учат такие видные гуру как Markus Winand и Макс Богук. Рекурсивные CTE, LATERAL JOIN, виртуозная работа с массивами и строками, window functions и прочие модные штучки, которые помогут вам в дрессировке вашего Постгреса, — я постараюсь сделать хороший обзор, а если вдруг тема покажется интересной, то в следующих сеансах группового Постгреса мы обязательно пригласим настоящих гуру :)
Оптимизация работы с данными в мобильных приложениях / Святослав Иванов, Артё...Ontico
Общие принципы оптимизации производительности мобильных приложений:
- работа с длинными списками — таблицы, коллекции;
- графика — загрузка из сети, кэширование;
- ленивая загрузка частей приложения.
Работа с периодически обновляемыми структурированными данными.
- как передавать данные с сервера на клиент: запросы, объем, формат, десериализация;
- как хранить полученные данные на клиенте — виды хранилищ: от плоских файлов до NoSQL.
Практический кейс. "Едадил": как мы ускоряли работу приложения для Android.
Долгожданный релиз pg_pathman 1.0 / Александр Коротков, Дмитрий Иванов (Post...Ontico
Механизм секционирования в Postgres имеет ряд ограничений, которые не позволяют использовать концепцию секционирования в полной мере. Среди таких ограничений можно выделить неэффективность планирования запросов для секционированных таблиц (линейный рост времени планирования при увеличении количества секций), отсутствие HASH-секционирования, необходимость ручного управления секциями.
В нашем докладе мы расскажем про расширение pg_pathman, которое позволяет обойти эти ограничения. pg_pathman реализует RANGE и HASH секционирования с логарифмическим и константным временами планирования соответственно. В pg_pathman поддерживается определение секции на этапе выполнения, конкурентное секционирование.
pg_pathman долго находился в стадии beta-тестирования, но теперь мы рады, наконец, сообщить о релизе 1.0. В докладе мы расскажем как про детали внутреннего устройства, так и про приёмы практического использования.
Мониторинг ожиданий в PostgreSQL / Курбангалиев Ильдус (Postgres Professional)Ontico
В многоядерных высоконагруженных системах с высокой конкурентностью часто бывает сложно определить, чем занят отдельный процесс PostgreSQL. Он может находиться в ожидании локов высокого уровня, таких как локи таблиц, внутренних локов, используемых для синхронизации процессов, ввода-вывода и многих других.
В настоящий момент среди всех событий ожидания мониторить можно только локи высокого уровня с помощью представлений PostgreSQL. Другие типы ожиданий требуют использования низкоуровневых утилит типа perf, systemtap и других. Эти утилиты требуют специальных знаний и могут быть платформозависимыми. В то же время другие enterprise базы данных уже включают в себя инструменты для мониторинга ожиданий.
Мы разработали патч, который реализует мониторинг ожиданий в PostgreSQL. С минимальной настройкой (несколько конфигурационных параметров) этот патч показывает полную информацию о текущих ожиданиях в режиме реального времени и с небольшим оверхедом на всю систему. Этот патч уже работает на продакшен серверах Яндекса и показал свою полезность.
#RuPostgresLive 4: как писать и читать сложные SQL-запросыNikolay Samokhvalov
Онлайн-опросы неизменно показывают — всех нас очень интересуют две вещи: а) как писать наиболее эффективные SQL-запросы, б) как «читать» такие запросы, а точнее, как понимать, что именно делает или будет делать СУБД при их выполнении.
Эти две неразрывно связанные друг с другом темы чрезвычайно обширны, SQL-искусству можно (и нужно) учиться годами. Во время нашей очередной встречи в прямом эфире мы затронем некоторые аспекты обеих.
ЧАСТЬ 1: EXPLAIN
Алексей Ермаков. Как читать и интерпретировать вывод команды EXPLAIN
Команда EXPLAIN — основной инструмент анализа запросов, позволяющий разобраться, каким образом запрос будет выполняться и как можно его ускорить. Для сложных запросов вывод может быть довольно громоздким и его становится сложно читать. Я расскажу, из каких частей состоит план запроса, на какие «маркеры» в нём следует обращать внимание в первую очередь и как на это реагировать.
ЧАСТЬ 2: ADVANCED SQL
Николай Самохвалов. SQL современный и «продвинутый»
«Я не волшебник, я только учусь». Продвинутому SQL нас постоянно учат такие видные гуру как Markus Winand и Макс Богук. Рекурсивные CTE, LATERAL JOIN, виртуозная работа с массивами и строками, window functions и прочие модные штучки, которые помогут вам в дрессировке вашего Постгреса, — я постараюсь сделать хороший обзор, а если вдруг тема покажется интересной, то в следующих сеансах группового Постгреса мы обязательно пригласим настоящих гуру :)
Оптимизация работы с данными в мобильных приложениях / Святослав Иванов, Артё...Ontico
Общие принципы оптимизации производительности мобильных приложений:
- работа с длинными списками — таблицы, коллекции;
- графика — загрузка из сети, кэширование;
- ленивая загрузка частей приложения.
Работа с периодически обновляемыми структурированными данными.
- как передавать данные с сервера на клиент: запросы, объем, формат, десериализация;
- как хранить полученные данные на клиенте — виды хранилищ: от плоских файлов до NoSQL.
Практический кейс. "Едадил": как мы ускоряли работу приложения для Android.
Долгожданный релиз pg_pathman 1.0 / Александр Коротков, Дмитрий Иванов (Post...Ontico
Механизм секционирования в Postgres имеет ряд ограничений, которые не позволяют использовать концепцию секционирования в полной мере. Среди таких ограничений можно выделить неэффективность планирования запросов для секционированных таблиц (линейный рост времени планирования при увеличении количества секций), отсутствие HASH-секционирования, необходимость ручного управления секциями.
В нашем докладе мы расскажем про расширение pg_pathman, которое позволяет обойти эти ограничения. pg_pathman реализует RANGE и HASH секционирования с логарифмическим и константным временами планирования соответственно. В pg_pathman поддерживается определение секции на этапе выполнения, конкурентное секционирование.
pg_pathman долго находился в стадии beta-тестирования, но теперь мы рады, наконец, сообщить о релизе 1.0. В докладе мы расскажем как про детали внутреннего устройства, так и про приёмы практического использования.
Мониторинг ожиданий в PostgreSQL / Курбангалиев Ильдус (Postgres Professional)Ontico
В многоядерных высоконагруженных системах с высокой конкурентностью часто бывает сложно определить, чем занят отдельный процесс PostgreSQL. Он может находиться в ожидании локов высокого уровня, таких как локи таблиц, внутренних локов, используемых для синхронизации процессов, ввода-вывода и многих других.
В настоящий момент среди всех событий ожидания мониторить можно только локи высокого уровня с помощью представлений PostgreSQL. Другие типы ожиданий требуют использования низкоуровневых утилит типа perf, systemtap и других. Эти утилиты требуют специальных знаний и могут быть платформозависимыми. В то же время другие enterprise базы данных уже включают в себя инструменты для мониторинга ожиданий.
Мы разработали патч, который реализует мониторинг ожиданий в PostgreSQL. С минимальной настройкой (несколько конфигурационных параметров) этот патч показывает полную информацию о текущих ожиданиях в режиме реального времени и с небольшим оверхедом на всю систему. Этот патч уже работает на продакшен серверах Яндекса и показал свою полезность.
Структуры данных в разделяемой памяти,
про алгоритмы замещения страниц в буфере и блокировки, которые используются на разных уровнях взаимодействия.
А также средства мониторинга памяти, уже существующие и те, которые ещё только в процессе разработки.
Техносфера Mail.ru Group, МГУ им. М.В. Ломоносова.
Курс "Методы распределенной обработки больших объемов данных в Hadoop"
Видео лекции курса https://www.youtube.com/playlist?list=PLrCZzMib1e9rPxMIgPri9YnOpvyDAL9HD
Отладка и устранение проблем в PostgreSQL Streaming Replication.Alexey Lesovsky
Потоковая репликация, которая появилась в 2010 году, стала одной из прорывных фич постгреса и в настоящее время практически ни одна инсталляция не обходится без использования потоковой репликации. Она надежна, легка в настройке, нетребовательна к ресурсам. Однако при всех своих положительных качествах, при её эксплуатации могут возникать различные проблемы и неприятные ситуации. Для диагностики и решения проблем, связанных с потоковой репликацией, есть множество инструментов, как встроенных в PostgreSQL, так и сторонних.
В этом докладе я сделаю обзор доступных инструментов и расскажу, как с помощью этих средств диагностировать различные типы проблем и как устранять их. Рассматривая методы решения, мы также рассмотрим проблемы, которые возникают при эксплуатации потоковой репликации.
Доклад будет полезен DBA и системным администраторам.
Докладчик:
Владимир Донец (kwimba.ru)
Описание: Слышали про магию в Python? Одно из магических заклинаний называется дескрипторы. Мощная фича языка, которая позволяет определять свое поведение атрибута объекта при доступе к этому атрибуту.
Сложно звучит? А вы знали, что дескрипторами уже наверняка пользовались, если хотя бы раз писали на Python. Я расскажу о том, что такое дескрипторы и как их осознанно можно применять в собственном коде.
Докладчик:
Александр Сапронов
Описание:
Мы рассмотрим популярные библиотеки для функционального программирования на Python — fn.py, functools, itertools, funcy, hask, Toolz. Узнаем возможности каждой из библиотеки, а также как в динамическом язык имитировать мощную систему типов. Затронем характеристики функционального программирования и проверим помогают ли библиотеки выполнить.
FrontTalks: Михаил Давыдов (Яндекс), «Promise – это не больно»Yandex
Асинхронность в JavaScript-приложениях – обычное дело. Любой обмен данными – асинхронный, что HTTP, что чтение файла, что БД. Все просто, если запрос один – callback, и все дела. Если логика сложнее, то приложение в худшем случае превращается в «Callback Pyramid of Doom» или обрастает разной магией. Promise – это подход, который выпрямляет вложенные запросы, превращает «асинхронную лапшу» в структурированный код и делает ваше приложение лучше. Вы всё еще боитесь использовать Promise? Тогда приходите на мой доклад.
Сравнение форматов и библиотек сериализации / Антон Рыжов (Qrator Labs)Ontico
В эпоху распределённых архитектур и микросервисов как никогда актуальными становятся вопросы — как эффективно сериализовать и передать данные. Большинство решает данный вопрос просто — используют стандартный, универсальный и всем понятный формат JSON. Другие же, ориентируясь на производительность, ищут в интернете бенчмарки и выбирают protobuf или msgpack.
Мы протестировали разные реализации статически (thrift, protocol buffers) и динамически (json, msgpack) типизированных протоколов для python; сравнили их производительность в разных сценариях, возможности, внутреннее устройство, удобство разработки.
Я расскажу о результатах нашего исследования, особенностях "приготовления" библиотек и выявленных подводных камнях.
Презентация доклада о B-tree индексах для российской конференции по PostgreSQL pgconf.ru. В презентации рассмотрены особенности архитектуры, важные для оптимального использования btree индексов. Кроме того, представлены улучшения функциональности B-tree в PostgreSQL, которые войдут в релиз 9.6. Это компрессия дубликатов и новые возможности использования покрывающих (covering) индексов.
Доклад Антона Поварова на Tarantool Meetup. "Tarantool в Badoo: хранение исто...Badoo Development
Каждый день на badoo.com пользователи просматривают порядка 100 миллионов профилей других юзеров. Мы храним счетчики и полную историю посещений за последние 90 дней, с некоторой агрегацией - это около 5 миллиардов ивентов. Система обрабатывающая этот поток данных создана давно и пережила несколько инкарнаций, становясь все ближе к базе данных.
В какой-то момент мы решили перестать изобретать велосипед, отказались от демонов на C+sqlite, не стали делать на mysql-ях, редисах и мемкешах, а взяли и запилили на Tarantool.
Рассказываем почему Tarantool, как шардим, реплицируем (все просто) и как плавно это дело внедрили на живой системе без downtime.
Структуры данных в разделяемой памяти,
про алгоритмы замещения страниц в буфере и блокировки, которые используются на разных уровнях взаимодействия.
А также средства мониторинга памяти, уже существующие и те, которые ещё только в процессе разработки.
Техносфера Mail.ru Group, МГУ им. М.В. Ломоносова.
Курс "Методы распределенной обработки больших объемов данных в Hadoop"
Видео лекции курса https://www.youtube.com/playlist?list=PLrCZzMib1e9rPxMIgPri9YnOpvyDAL9HD
Отладка и устранение проблем в PostgreSQL Streaming Replication.Alexey Lesovsky
Потоковая репликация, которая появилась в 2010 году, стала одной из прорывных фич постгреса и в настоящее время практически ни одна инсталляция не обходится без использования потоковой репликации. Она надежна, легка в настройке, нетребовательна к ресурсам. Однако при всех своих положительных качествах, при её эксплуатации могут возникать различные проблемы и неприятные ситуации. Для диагностики и решения проблем, связанных с потоковой репликацией, есть множество инструментов, как встроенных в PostgreSQL, так и сторонних.
В этом докладе я сделаю обзор доступных инструментов и расскажу, как с помощью этих средств диагностировать различные типы проблем и как устранять их. Рассматривая методы решения, мы также рассмотрим проблемы, которые возникают при эксплуатации потоковой репликации.
Доклад будет полезен DBA и системным администраторам.
Докладчик:
Владимир Донец (kwimba.ru)
Описание: Слышали про магию в Python? Одно из магических заклинаний называется дескрипторы. Мощная фича языка, которая позволяет определять свое поведение атрибута объекта при доступе к этому атрибуту.
Сложно звучит? А вы знали, что дескрипторами уже наверняка пользовались, если хотя бы раз писали на Python. Я расскажу о том, что такое дескрипторы и как их осознанно можно применять в собственном коде.
Докладчик:
Александр Сапронов
Описание:
Мы рассмотрим популярные библиотеки для функционального программирования на Python — fn.py, functools, itertools, funcy, hask, Toolz. Узнаем возможности каждой из библиотеки, а также как в динамическом язык имитировать мощную систему типов. Затронем характеристики функционального программирования и проверим помогают ли библиотеки выполнить.
FrontTalks: Михаил Давыдов (Яндекс), «Promise – это не больно»Yandex
Асинхронность в JavaScript-приложениях – обычное дело. Любой обмен данными – асинхронный, что HTTP, что чтение файла, что БД. Все просто, если запрос один – callback, и все дела. Если логика сложнее, то приложение в худшем случае превращается в «Callback Pyramid of Doom» или обрастает разной магией. Promise – это подход, который выпрямляет вложенные запросы, превращает «асинхронную лапшу» в структурированный код и делает ваше приложение лучше. Вы всё еще боитесь использовать Promise? Тогда приходите на мой доклад.
Сравнение форматов и библиотек сериализации / Антон Рыжов (Qrator Labs)Ontico
В эпоху распределённых архитектур и микросервисов как никогда актуальными становятся вопросы — как эффективно сериализовать и передать данные. Большинство решает данный вопрос просто — используют стандартный, универсальный и всем понятный формат JSON. Другие же, ориентируясь на производительность, ищут в интернете бенчмарки и выбирают protobuf или msgpack.
Мы протестировали разные реализации статически (thrift, protocol buffers) и динамически (json, msgpack) типизированных протоколов для python; сравнили их производительность в разных сценариях, возможности, внутреннее устройство, удобство разработки.
Я расскажу о результатах нашего исследования, особенностях "приготовления" библиотек и выявленных подводных камнях.
Презентация доклада о B-tree индексах для российской конференции по PostgreSQL pgconf.ru. В презентации рассмотрены особенности архитектуры, важные для оптимального использования btree индексов. Кроме того, представлены улучшения функциональности B-tree в PostgreSQL, которые войдут в релиз 9.6. Это компрессия дубликатов и новые возможности использования покрывающих (covering) индексов.
Доклад Антона Поварова на Tarantool Meetup. "Tarantool в Badoo: хранение исто...Badoo Development
Каждый день на badoo.com пользователи просматривают порядка 100 миллионов профилей других юзеров. Мы храним счетчики и полную историю посещений за последние 90 дней, с некоторой агрегацией - это около 5 миллиардов ивентов. Система обрабатывающая этот поток данных создана давно и пережила несколько инкарнаций, становясь все ближе к базе данных.
В какой-то момент мы решили перестать изобретать велосипед, отказались от демонов на C+sqlite, не стали делать на mysql-ях, редисах и мемкешах, а взяли и запилили на Tarantool.
Рассказываем почему Tarantool, как шардим, реплицируем (все просто) и как плавно это дело внедрили на живой системе без downtime.
Доклад от Parallels:
Методики тестировния производительности database-centric приложений
Описание: При работе над сложными продуктами в database-centric приложениях изменения в коде и тем более в SQL запросах к базе данных могут приводить к неожиданным падениям производительности или же деградации производительности приложения с ростом размера базы данных. Поэтому важно уметь как можно быстрее отлавливать и исправлять причины таких деградаций.
Доклад о том, как устроен процесс мониторинга производительности продукта автоматизации хостинга и облачных сервисов Parallels Automation, для которого определяющим фактором является производительность базы данных.
Компания покажет, как анализирует планы исполнения SQL запросов внутри PostgreSQL, как проверяет насколько быстро и эффективно в целом работают SQL запросы, как определяет стратегию дальнейшей оптимизации.
Monitoring driven эксплуатация / Николай Сивко (HeadHunter)Ontico
Огромная часть работы службы эксплуатации, так или иначе, связана с мониторингом существующей инфраструктуры.
Если система мониторинга настроена хорошо, она позволяет сократить время простоя, какие-то проблемы показать на ранней стадии, формализовать рабочие процессы команды админов.
То есть она является носителем знания о нашей инфраструктуре и о том, как именно работают админы.
Можно ли извлечь дополнительную пользу из этого?
В hh.ru мы используем систему мониторинга ещё и как check list для повседневных задач админов (алерты в данном случае являются задачами для человека: сделал задачу - триггер проверил результат и погас), идея взята из TDD.
Также расскажу, как мы работаем с внештатными ситуациями: реагируем на алерты, чиним, разбираем и классифицируем.
Еще на основе разобранных инцидентов мы считаем показатели работы службы эксплуатации, из этих показателей высчитываются наши премии (данный KPI получился удачным: с ним согласен и бизнес и админы).
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
Подходы и технологии, используемые в разработке iOS-клиента Viber, Кирилл Лаш...Yandex
Рассказ об основных принципах, которых придерживается Viber в длительной разработке приложения с большой кодовой базой — если разработкой занимается распределённая команда. Мы обсудим используемые технологии, библиотеки, работу с кодом и многое другое.
Linux API с точки зрения разработчика веб-сервера / Валентин Бартенев (NGINX,...Ontico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 6 июня, 15:00
Тезисы:
http://backendconf.ru/2017/abstracts/2710.html
В данном докладе я дам обзор системных интерфейсов, которые предоставляет Linux для эффективной обработки запросов. В частности, речь пойдет о мультиплексировании ввода-вывода, отправке файлов и многопоточной обработке входящих соединений. Расскажу о нюансах и недостатках в сравнении с аналогичными интерфейсами других unix-подобных операционных систем. Личный опыт показывает, что продуманность и качество реализации интерфейса для прикладных программ — это, к сожалению, довольно слабая сторона ядра Linux.
OpenResty: превращаем NGINX в полноценный сервер приложений / Владимир Прота...Ontico
Все мы знаем, что NGINX – отличный прокси, который может качественно и эффективно распределять нагрузку между бэкендами и фильтровать запросы по определенным условиям. Но при этом часто на практике возникают задачи, которые не решаются его декларативной моделью описания конфигурации: иногда для принятия решения нам нужно сходить в базу данных (в Redis или даже в MySQL), другой сервис или произвести какую-то более сложную обработку запроса/ответа. Именно здесь к нам на помощь приходит мощь Lua и OpenResty.
Из доклада вы узнаете:
* зачем нам Lua внутри NGINX, и почему из седьмого айфона убрали разъем под наушники;
* в каких ситуациях NGINX в паре с Lua справятся с задачей лучше вашего любимого PHP/NodeJS/Ruby/Python/Visual Basic и о прелестях асинхронного ввода-вывода без callback'ов;
* как залезть к NGINX под капот, используя только высокоуровневый язык;
* при чем здесь Openresty, или как упростить себе жизнь;
* примеры бизнес-кейсов: от "умного" прокси до самостоятельного веб-приложения;
* как оно ведет себя в продакшне под большой нагрузкой.
Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)Ontico
Исторически сложилось так, что одни люди разрабатывают приложения (Dev), а другие эксплуатируют их в продакшне (Ops). И у последних есть немало проблем с тем, что невозможно понять, что происходит.
Причем это касается как собственных разработок, так и популярных open source решений.
Я расскажу, как устроена диагностика у некоторых популярных софтин:
- nginx
- postgresql
- mongodb
Мы попробуем разобраться, что там сделано хорошо, и чего не хватает для полного счастья.
Во второй части доклада мы поговорим про то, как нужно инструментировать собственное приложение для прозрачной работы в продакшне:
- что считать и зачем: ошибки, тайминги, разные состояния приложения,
- инструментарий: your_lang-metrics, your_lang-statsd-client, логи,
- как не перемудрить и не убить прод диагностикой.
Может показаться, что этот доклад про DevOps, но нет - про docker не будет ни слова :)
4. 4
Все ли у нас в порядке?
Не все метрики одинаково полезны для оценки производительности
• LA, CPU load, %diskutil, memory usage и т.п. нужны, но не всегда помогают
• Среднее время выполнения http запроса – как средняя температура по
больнице
• Быстрый ответ конечно хорошо, но только если это не 5xx ошибка
5. 5
Все ли у нас в порядке?
График количества медленных (> 333ms) http запросов в минуту
6. 6
Все ли у нас в порядке?
График распределения http запросов по времени, в % в минуту
7. 7
Все ли у нас в порядке?
График количества 4xx и 5xx ошибок в секунду
8. 8
Все ли у нас в порядке?
Прежде чем крутить гайки стоит иметь какие-то метрики для оценки
эффекта от изменений!
10. 10
Длинные транзакции
• Очень плохо для базы из-за реализации multiversion concurrency control
(MVCC)
• При каждом update строки создается ее копия
• Ненужные копии подчищаются процессом autovacuum
• Пока длинная транзакция открыта, автовакуум не может их почистить
11. 11
Длинные транзакции
• Приводят к распуханию (bloat) таблиц и индексов
• Запросы могут работать медленней из-за необходимости сканировать
неактуальные версии строк
• Освободить уже занятое место не всегда просто
12. 12
Длинные транзакции
Как бороться?
• Мониторинг длины самой долгой транзакции (на репликах с
hot_standby_feedback = on тоже!)
• Автоматически прибивать по крону (см. pg_terminate_backend(),
pg_stat_activity)
• Разграничение пользователей по допустимому времени ответа
• Модифицировать приложение
• pg_dump ⇒ pg_basebackup
13. 13
ORM
• Для сложных выборок запросы лучше писать самостоятельно
• Не вызывать запросы в циклах без сильной необходимости
• Не стоит ожидать что запрос с 20 joins будет работать быстро
• Комментарии с ip/hostname/appname/stacktrace бывают полезны
14. 14
SQL запросы это не только select и join
• [recursive]CTE
• Window functions
• Lateral join
• DISTINCT ON
• EXISTS / NOT EXISTS
• generate_series()
• Arrays
• hstore/json/jsonb
• COPY
• Materialized views
• Unlogged tables
• pl/* functions
Нет времени объяснять, надо использовать!
15. 15
SQL запросы это не только select и join
Выборка TOP N по списку
SELECT *
FROM (
VALUES (29),(68),(45),(47),(50),(41),(11),(4),(83),(60)
) AS t(category_id),
LATERAL (
SELECT * FROM posts WHERE posts.category_id = t.category_id ORDER BY created_at DESC LIMIT 5
) AS _t;
16. 16
SQL запросы это не только select и join
Одним запросом к базе можно производить почти любые вычисления
17. 17
Хватает ли сети?
Latency
• Оптимально, когда сервера подключены в один switch
• ping между приложением и базой ≈ 0.1ms
• Если приложение делает много запросов – то критичный параметр
24. 24
postgresql.conf
• work_mem – внутренняя память процесса для сортировки/hash таблицы.
по-умолчанию 1MB/4MB
• maintenance_work_mem
• effective_cache_size – подсказка планировщику о размере кэша
26. 26
postgresql.conf
WAL
• synchronous_commit = on (можно выключить, если не справляются диски, но
нужно понимать последствия)
• wal_writer_delay = 200ms..10s
• fsync = on (не выключать!)
28. 28
Как искать проблемные запросы?
• логгирование запросов вместе с временем выполнения через
log_min_duration_statement
• парсинг логов через pgfouine, pgbadger, loganalyzer
• pg_stat_statements (9.2+)
29. 29
Как искать проблемные запросы?
pgday=# select * from (select unnest(proargnames) from pg_proc where proname = ’pg_stat_statements’)
unnest
---------------------
userid
dbid
query
calls
total_time
rows
...
blk_read_time
blk_write_time
30. 30
Как искать проблемные запросы?
• track_io_timing = on (на экзотических платформах проверить overhead через
pg_test_timing)
• track_functions = (none|pl|all)
• track_activity_query_size
• pg_stat_statements.max = 10000
• pg_stat_statements.track = (top|all)
• pg_stat_statements.track_utility = off
• pg_stat_statements_reset()
31. 31
Как искать проблемные запросы?
sql/global_reports/query_stat_total.sql
total time: 82:08:45 (IO: 1.56%)
total queries: 3,366,257,532 (unique: 9,072)
report for all databases, version 0.9.3 @ PostgreSQL 9.5.2
tracking top 10000 queries, logging 100ms+ queries
==================================================================================================
pos:1 total time: 20:42:35 (25.2%, CPU: 25.6%, IO: 0.0%) calls: 1,824 (0.00%)
avg_time: 40874.96ms (IO: 0.0%)
user: bravo db: echo rows: 96,797,801,178 query:
SELECT * FROM oscar_recent WHERE id > ?
32. 32
Как ускорить запрос?
• Достаем из логов параметры запроса
• Выполняем explain analyze запроса с данными параметрами
• Смотрим на план, медитируем
• В сложных случаях смотрим на что тратится время на explain.depesz.com
• Если не хватает индексов – добавляем
• Если планировщик не прав, пробуем получить другие планы
33. 33
Как ускорить запрос?
QUERY PLAN
--------------------------------------------------------------------------------------------------
Seq Scan on oscar_recent (cost=0.00..855857.35 rows=62938380 width=42)
(actual time=0.018..9436.857 rows=63020558 loops=1)
Filter: (id > ’3244145575’::bigint)
Planning time: 0.093 ms
Execution time: 11188.941 ms
34. 34
Как ускорить запрос?
Методы получения данных
• seq scan - последовательное чтение таблицы
• index scan - random io (чтение индекса + чтение таблицы)
• index only scan (9.2+)1
• bitmap index scan - компромисс между seq scan/index scan, возможность
использования нескольких индексов в OR/AND условиях
1
https://wiki.postgresql.org/wiki/Index-only_scans
35. 35
Как ускорить запрос?
Методы соединения данных
• nested loop - оптимален для небольших наборов данных
• hash join - оптимален для больших наборов данных
• merge join - оптимален для больших наборов данных, в случае, если они
отсортированы
36. 36
Как ускорить запрос?
Какие бывают индексы?
• partial
create index concurrently ... on post using btree(domain_id, created)
where pinned = true;
• multicolumn
create index concurrently ... on events using btree(user_id, type);
• functional
create index concurrently ... on i_movement
using btree((coalesce(m_movement_id, 0)));
• btree/gin/gist/brin
37. 37
Система
• Linux: Debian/Ubuntu/CentOS/RHEL
• в kernel 3.2 есть некоторые проблемы с IO2
• I/O scheduler: noop, deadline, cfq
• ionice/renice background процессам
2
http://www.databasesoup.com/2014/09/why-you-need-to-avoid-linux-kernel-32.html
42. 42
RAM
• В один сервер можно поставить сравнительно много 128GB-256GB-...
• Хорошо, когда активно используемая часть базы помещается в память
• Для больших объемов имеет смысл включить huge pages (9.2, 9.4+)3
3
https://habrahabr.ru/post/228793/
43. 43
CPU
• Обычно не является лимитирующим фактором, но не всегда
• Для многопроцессорных систем следует выключать NUMA4:
• numa → off (node interleaving → enabled) в BIOS
• или vm.zone_reclaim_mode = 0 в sysctl.conf
4
http://frosty-postgres.blogspot.ru/2012/08/postgresql-numa-and-zone-reclaim-mode.html
44. 44
Заключение
• Нужны метрики производительности системы
• Потенциальных узких мест в системе может быть много
• Возможности по обработке данных у SQL запросов очень большие
• Для поиска проблемных запросов парсим логи или используем
pg_stat_statements
• Для оптимизации запросов нужно уметь читать вывод explain
• К выбору железа нужно подходить с умом
45. 45
Полезные ссылки
• Different Approaches for MVCC used in well known Databases
• depesz: Explaining the unexplainable
• Объясняя необъяснимое
• https://github.com/PostgreSQL-Consulting/pg-utils
• http://blog.postgresql-consulting.com/