Для приготовления асинхронных уведомлений из PostgreSQL в websocket нам понадобится сам nginx и его плагины postgres, push-stream, set-misc. (Я дал ссылки на свои форки, т.к. делал некоторые изменения, которые пока не удалось пропихнуть в оригинальные репозитории. Можно также воспользоваться готовым образом.)
Автономное будущее СУБД
25 мин
Как вы думаете, кто лучше настроит PostgreSQL — DBA или ML алгоритм? И если второй, то пора ли нам задуматься, чем заняться, когда нас заменят машины. Или до этого не дойдет, и важные решения все-таки должен принимать человек. Наверное, уровень изоляции и требования к устойчивости транзакций должны оставаться в ведении администратора. Но индексы уже скоро можно будет доверить машине определять самостоятельно.
Энди Павло на HighLoad++ рассказал про СУБД будущего, которые можно «потрогать» уже сейчас. Если пропустили это выступление или предпочитаете получать информацию на русском языке — под катом перевод выступления.
Речь пойдет о проекте университета Карнеги-Меллона, посвященном созданию автономных СУБД. Под термином «автономный» подразумевается система, которая может автоматически развертывать, настраивать, конфигурировать себя без какого-либо вмешательства человека. Возможно, потребуется около десяти лет, чтобы разработать что-то подобное, но именно этим заняты Энди и его студенты. Конечно, для создания автономной СУБД необходимы алгоритмы машинного обучения, однако, в этой статье сосредоточимся только на инженерной стороне темы. Рассмотрим, как проектировать программное обеспечение, чтобы сделать его автономным.
Энди Павло на HighLoad++ рассказал про СУБД будущего, которые можно «потрогать» уже сейчас. Если пропустили это выступление или предпочитаете получать информацию на русском языке — под катом перевод выступления.
Речь пойдет о проекте университета Карнеги-Меллона, посвященном созданию автономных СУБД. Под термином «автономный» подразумевается система, которая может автоматически развертывать, настраивать, конфигурировать себя без какого-либо вмешательства человека. Возможно, потребуется около десяти лет, чтобы разработать что-то подобное, но именно этим заняты Энди и его студенты. Конечно, для создания автономной СУБД необходимы алгоритмы машинного обучения, однако, в этой статье сосредоточимся только на инженерной стороне темы. Рассмотрим, как проектировать программное обеспечение, чтобы сделать его автономным.
MVCC в PostgreSQL-8. Заморозка
12 мин
Мы начали с вопросов, связанных с изоляцией, сделали отступление про организацию данных на низком уровне, подробно поговорили о версиях строк и о том, как из версий получаются снимки данных.
Затем мы рассмотрели разные виды очистки: внутристраничную (вместе с HOT-обновлениями), обычную и автоматическую.
И добрались до последней темы этого цикла. Сегодня мы поговорим о проблеме переполнения счетчика транзакций (transaction id wraparound) и заморозке.
Затем мы рассмотрели разные виды очистки: внутристраничную (вместе с HOT-обновлениями), обычную и автоматическую.
И добрались до последней темы этого цикла. Сегодня мы поговорим о проблеме переполнения счетчика транзакций (transaction id wraparound) и заморозке.
Игра в прятки с оптимизатором. Гейм овер, это CTE PostgreSQL 12
6 мин
Эта статья — продолжение рассказа о новом в PostgreSQL 12. Мы уже разобрали SQL/JSON (патч JSONPath) в статье «Что заморозили на feature freeze 2019. Часть I. JSONPath», теперь очередь CTE.
CTE
CTE это Common Table Expression — общие табличные выражения, их еще называют конструкциями с WITH. Фактически это создание временных таблиц, но существующих только для одного запроса, а не для сессии. К ним можно обращаться внутри этого запроса. Такой запрос хорошо читается, он понятен, его легко видоизменять, если потребуется. Это очень востребованная вещь, и она в PostgreSQL давно.
Но удобства могут обойтись дорого. Проблемы связаны с материализацией выражения после AS внутри конструкции WITH… AS (). Его еще называют внутренним выражением и вычисляют перед тем, как начать вычисление остального, его нельзя встроить в запрос верхнего уровня (no inlining). Планирование этого выражения происходит без учета остальной части запроса. Такое поведение называют барьером для оптимизации, или fencing. Кроме того, сама материализация требует под себя work_mem. И если выборка большая, то начинаются проблемы (об этом, например, есть в докладе Ивана Фролкова на PGConf 2019).
История одного SQL расследования
8 мин
Перевод
В декабре прошлого года я получил интересный отчет об ошибке от команды поддержки VWO. Время загрузки одного из аналитических отчетов для крупного корпоративного клиента казалось непомерно большим. А так как это сфера моей ответственности, я тут же сосредоточился на решении проблемы.
Предыстория
Чтобы было понятно о чём речь, я расскажу совсем немного о VWO. Это платформа, с помощью которой можно запускать разные таргетированные кампании на своих сайтах: проводить A/B эксперименты, отслеживать посетителей и конверсии, делать анализ воронки продаж, отображать тепловые карты и проигрывать записи визитов.
Но самое главное в платформе — составление отчетов. Все вышеперечисленные функции связаны между собой. И для корпоративных клиентов, огромный массив из информации был бы просто бесполезен без мощной платформы, представляющей их в виде для аналитики.
Используя платформу, можно сделать произвольный запрос на большом наборе данных. Вот простенький пример:
Показать все клики на странице "abc.com" ОТ <даты d1> ДО <даты d2> для людей, которые использовали Chrome ИЛИ (находились в Европе И использовали iPhone)
Обратите внимание на булевы операторы. Они доступны для клиентов в интерфейсе запроса, чтобы делать сколь угодно сложные запросы для получения выборок.
Медленный запрос
Клиент, о котором идет речь, пытался сделать что-то, что интуитивно должно работать быстро:
Покажи все записи сессий для пользователей посетивших любую страницу с урлом, где есть "/jobs"
На этом сайте было огромное количество трафика, и мы хранили более миллиона уникальных URL-адресов только для него. И они хотели найти довольно простой шаблон урла, относящегося к их бизнес-модели.
Как мы строим UI для рекламных систем
8 мин
Вместо вступления
Ранее в нашем блоге мы писали, чем занимается компания IPONWEB — мы автоматизируем показ рекламы в интернете. Наши системы принимают решения не только на основе исторических данных, но и активно используют информацию, полученную в реальном времени. В случае DSP (Demand Side Platform — рекламная платформа для рекламодателей), рекламодатель (или его представитель) должен создать и загрузить рекламный баннер (креатив) в одном из форматов (картинка, видео, интерактивный баннер, картинка+текст и т.д.), выбрать аудиторию пользователей, которым этот баннер будет показан, определить сколько раз можно показать рекламу одному пользователю, в каких странах, на каких сайтах, на каких устройствах, и отразить это (и многое другое) в настройках таргетинга рекламной кампании, а также распределить рекламные бюджеты. Для SSP (Supply Side Platform — рекламная платформа для владельцев рекламных площадок) владелец сайта (мобильного приложения, билборда, телевизионного канала) должен определить рекламные места на своем ресурсе и указать, например, какие категории рекламы он готов на них показывать. Все эти настройки делаются вручную заблаговременно (не в момент показа рекламы) с помощью пользовательского интерфейса. В этой статье я расскажу про наш подход к построению таких интерфейсов при условии, что их много, они похожи друг на друга и при этом обладают индивидуальными особенностями.
Курсоры БД в Doctrine
6 мин
Используя курсоры, вы сможете порционно получить из БД и обработать большое количество данных, не расходуя при этом память приложения. Уверен, перед каждым веб-разработчиком хотя бы раз вставала подобная задача, передо мной тоже — и не раз. В этой статье я расскажу, в каких задачах курсоры могут быть полезны, и дам готовый код по работе с ними из PHP + Doctrine на примере PostrgeSQL.
Топ ошибок со стороны разработки при работе с PostgreSQL
21 мин
HighLoad++ существует давно, и про работу с PostgreSQL мы говорим регулярно. Но у разработчиков все равно из месяца в месяц, из года в год возникают одни и те же проблемы. Когда в маленьких компаниях без DBA в штате случаются ошибки в работе с базами данных, в этом нет ничего удивительного. В крупных компаниях тоже нужны БД, и даже при отлаженных процессах все равно случаются ошибки, и базы падают. Неважно, какого размера компания — ошибки все равно бывают, БД периодически обваливаются, рушатся.
С вами такого, конечно, никогда не случится, но проверить чек-лист не трудно, а сэкономить будущих нервов он может очень прилично. Под катом перечислим топ типичных ошибок, которые совершают разработчики при работе с PostgreSQL, разберемся, почему так делать не надо, и выясним, как надо.
О спикере: Алексей Лесовский (lesovsky) начинал системным администратором Linux. От задач виртуализации и систем мониторинга постепенно пришел к PostgreSQL. Сейчас PostgreSQL DBA в Data Egret — консалтинговой компании, которая работает с большим количеством разных проектов и видит много примеров повторяющихся проблем. Это ссылка на презентацию доклада на HighLoad++ 2018.
С вами такого, конечно, никогда не случится, но проверить чек-лист не трудно, а сэкономить будущих нервов он может очень прилично. Под катом перечислим топ типичных ошибок, которые совершают разработчики при работе с PostgreSQL, разберемся, почему так делать не надо, и выясним, как надо.
О спикере: Алексей Лесовский (lesovsky) начинал системным администратором Linux. От задач виртуализации и систем мониторинга постепенно пришел к PostgreSQL. Сейчас PostgreSQL DBA в Data Egret — консалтинговой компании, которая работает с большим количеством разных проектов и видит много примеров повторяющихся проблем. Это ссылка на презентацию доклада на HighLoad++ 2018.
Сертификация администраторов баз данных и многое другое на юбилейном DevConfX (21-22 июня в Москве)
1 мин
Продолжаем голосовать за интересные доклады в секции «Хранилища данных (Storage)» на DevConfX, которая пройдет уже через неделю. Обратите внимание на доклад о сертификации специалистов PostgreSQL, оставайтесь всегда в курсе последних событий в мире баз данных.
Заявки на секцию Storage
Успей зарегистрироваться до 15 июня на юбилейной DevConfX!
Заявки на секцию Storage
- Предвкушая двенадцатый PostgreSQL (Иван Панченко)
- NoSQL + SQL = MySQL 8 Document Store! (Витторио Чиоэ)
- Tarantool 2.1. Добавляем SQL в noSQL СУБД (Кирилл Юхин)
- Хранилища данных на службе BI (Exasol и Hadoop) (Александр Крашенинников и Алексей Еремихин)
- ProxySQL 2.0 или ЗОЖ с MySQL (Владимир Федорков)
- Сертификация PostgreSQL. Вопросы и ответы (Павел Лузанов)
- Базы данных в IT индустрии сейчас и 10 лет назад (Владимир Федорков)
Успей зарегистрироваться до 15 июня на юбилейной DevConfX!
MVCC-7. Автоочистка
11 мин
Напомню, что мы начали с вопросов, связанных с изоляцией, сделали отступление про организацию данных на низком уровне, подробно поговорили о версиях строк и о том, как из версий получаются снимки данных.
Затем мы рассмотрели внутристраничную очистку (и HOT-обновления), обычную очистку, ну а сегодня посмотрим на автоматическую очистку.
Мы уже говорили о том, что обычная очистка в нормальных условиях (когда никто не удерживает надолго горизонт транзакций) должна справляться со своей работой. Вопрос в том, как часто ее вызывать.
Если очищать изменяющуюся таблицу слишком редко, она вырастет в размерах больше, чем хотелось бы. Кроме того, для очередной очистки может потребоваться несколько проходов по индексам, если изменений накопилось слишком много.
Если очищать таблицу слишком часто, то вместо полезной работы сервер будет постоянно заниматься обслуживанием — тоже нехорошо.
Заметим, что запуск обычной очистки по расписанию никак не решает проблему, потому что нагрузка может изменяться со временем. Если таблица стала обновляться активней, то и очищать ее надо чаще.
Автоматическая очистка — как раз тот самый механизм, который позволяет запускать очистку в зависимости от активности изменений в таблицах.
Затем мы рассмотрели внутристраничную очистку (и HOT-обновления), обычную очистку, ну а сегодня посмотрим на автоматическую очистку.
Автоочистка (autovacuum)
Мы уже говорили о том, что обычная очистка в нормальных условиях (когда никто не удерживает надолго горизонт транзакций) должна справляться со своей работой. Вопрос в том, как часто ее вызывать.
Если очищать изменяющуюся таблицу слишком редко, она вырастет в размерах больше, чем хотелось бы. Кроме того, для очередной очистки может потребоваться несколько проходов по индексам, если изменений накопилось слишком много.
Если очищать таблицу слишком часто, то вместо полезной работы сервер будет постоянно заниматься обслуживанием — тоже нехорошо.
Заметим, что запуск обычной очистки по расписанию никак не решает проблему, потому что нагрузка может изменяться со временем. Если таблица стала обновляться активней, то и очищать ее надо чаще.
Автоматическая очистка — как раз тот самый механизм, который позволяет запускать очистку в зависимости от активности изменений в таблицах.
Понимание джойнов сломано. Продолжение. Попытка альтернативной визуализации
2 мин
Многие из вас читали предыдущую статью про то, как неправильная визуализация для объяснения работы JOIN-ов в некоторых случаях может запутать. Круги Венна не могут полноценно проиллюстрировать некоторые моменты, например, если значения в таблице повторяются.
При подготовке к записи шестого выпуска подкаста "Цинковый прод" (где мы договорились обсудить статью) кажется удалось нащупать один интересный вариант визуализации. Кроме того, в комментариях к изначальной статье тоже предлагали похожий вариант.
Все желающие приглашаются под кат
Профессиональный Postgres
17 мин
Мы продолжаем публиковать видео и расшифровки лучших докладов с конференции PGConf.Russia 2019. Доклад Олега Бартунова на тему «Профессиональный Postgres» открывал пленарную часть конференции. В нем раскрыта история СУБД Postgres, российский вклад в разработку, особенности архитектуры.
Предыдущие материалы этой серии: «Типичные ошибки при работе с PostgreSQL» Ивана Фролкова, части 1 и 2.
Я буду рассказывать про профессиональный Postgres. Прошу не путать с компанией, которую я представляю сейчас — Postgres Professional.
Я действительно буду говорить о том, как Postgres, начинавшийся как любительская академическая разработка, стал профессиональным — таким, как мы его видим сейчас. Выскажу исключительно свое персональное мнение, оно не отражает мнение ни нашей компании, ни каких-либо групп.
Предыдущие материалы этой серии: «Типичные ошибки при работе с PostgreSQL» Ивана Фролкова, части 1 и 2.
Я буду рассказывать про профессиональный Postgres. Прошу не путать с компанией, которую я представляю сейчас — Postgres Professional.
Я действительно буду говорить о том, как Postgres, начинавшийся как любительская академическая разработка, стал профессиональным — таким, как мы его видим сейчас. Выскажу исключительно свое персональное мнение, оно не отражает мнение ни нашей компании, ни каких-либо групп.
Кастомизация Django ORM на примере ZomboDB
7 мин
Туториал
Часто при работе с Django и PostgreSQL возникает необходимость в дополнительных расширениях для базы данных. И если например с hstore или PostGIS (благодаря GeoDjango) всё достаточно удобно, то c более редкими расширениями — вроде pgRouting, ZomboDB и пр. — приходится либо писать на RawSQL, либо кастомизировать Django ORM. Чем я предлагаю, в данной статье, и заняться, используя в качестве примера ZomboDB и его getting started tutorial. И заодно рассмотрим как можно подключить ZomboDB к проекту на Django.
Ближайшие события
Как перестать забывать про индексы и начать проверять execution plan в тестах
9 мин
Какое-то время назад, приключилась со мной неприятная история, которая послужила триггером для небольшого проекта на гитхабе и вылилась в эту статью.
Обычный день, обычный релиз: все задачи вдоль и поперек проверены нашим QA-инженером, поэтому со спокойствием священной коровы «закатываем» на stage. Приложение ведет себя хорошо, в логах — тишина. Принимаем решение делать switch (stage <-> prod). Переключаем, смотрим на приборы…
Проходит пару минут, полет стабильный. QA-инженер делает smoke-тест, замечает, что приложение как-то неестественно подтормаживает. Списываем на прогрев кешей.
Проходит еще пару минут, первая жалоба из первой линии: у клиентов очень долго загружаются данные, приложение тормозит, долго отвечает и т.д. Начинаем беспокоиться… смотрим логи, ищем возможные причины.
MVCC-6. Очистка
13 мин
Мы начали с вопросов, связанных с изоляцией, сделали отступление про организацию данных на низком уровне, затем подробно поговорили о версиях строк и о том, как из версий получаются снимки данных.
В прошлый раз мы поговорили о HOT-обновлениях и внутристраничной очистке, а сегодня займемся всем известной обычной очисткой, vacuum vulgaris. Да, про нее написано уже столько всего, что вряд ли я скажу что-то новое, но полнота картины требует жертв. Терпите.
Внутристраничная очистка выполняется быстро, но освобождает только часть места. Она работает в пределах одной табличной страницы и не затрагивает индексы.
Основная, «обычная» очистка выполняется командой VACUUM и ее мы будем называть просто очисткой (а про автоочистку мы будем говорить отдельно).
Итак, очистка обрабатывает таблицу полностью. Она вычищает не только ненужные версии строк, но и ссылки на них из всех индексов.
Обработка происходит параллельно с другой активностью в системе. Таблица и индексы при этом могут использоваться обычным образом и для чтения, и для изменения (однако одновременное выполнение таких команд, как CREATE INDEX, ALTER TABLE и некоторых других будет невозможно).
В таблице просматриваются только те страницы, в которых происходила какая-то активность. Для этого используется карта видимости (напомню, что в ней отмечены страницы, содержащие только достаточно старые версии строк, которые гарантированно видимы во всех снимках данных). Обрабатываются только страницы, не отмеченные в карте, а сама карта при этом обновляется.
В процессе работы обновляется и карта свободного пространства, чтобы отразить появившееся свободное места в страницах.
В прошлый раз мы поговорили о HOT-обновлениях и внутристраничной очистке, а сегодня займемся всем известной обычной очисткой, vacuum vulgaris. Да, про нее написано уже столько всего, что вряд ли я скажу что-то новое, но полнота картины требует жертв. Терпите.
Обычная очистка (vacuum)
Что делает очистка
Внутристраничная очистка выполняется быстро, но освобождает только часть места. Она работает в пределах одной табличной страницы и не затрагивает индексы.
Основная, «обычная» очистка выполняется командой VACUUM и ее мы будем называть просто очисткой (а про автоочистку мы будем говорить отдельно).
Итак, очистка обрабатывает таблицу полностью. Она вычищает не только ненужные версии строк, но и ссылки на них из всех индексов.
Обработка происходит параллельно с другой активностью в системе. Таблица и индексы при этом могут использоваться обычным образом и для чтения, и для изменения (однако одновременное выполнение таких команд, как CREATE INDEX, ALTER TABLE и некоторых других будет невозможно).
В таблице просматриваются только те страницы, в которых происходила какая-то активность. Для этого используется карта видимости (напомню, что в ней отмечены страницы, содержащие только достаточно старые версии строк, которые гарантированно видимы во всех снимках данных). Обрабатываются только страницы, не отмеченные в карте, а сама карта при этом обновляется.
В процессе работы обновляется и карта свободного пространства, чтобы отразить появившееся свободное места в страницах.
Используем все возможности индексов в PostgreSQL
8 мин
Туториал
Перевод
В мире Postgres индексы крайне важны для эффективной навигации по хранилищу базы данных (его называют «куча», heap). Postgres не поддерживает для него кластеризацию, и архитектура MVCC приводит к тому, что у вас накапливается много версий одного и того же кортежа. Поэтому очень важно уметь создавать и сопровождать эффективные индексы для поддержки приложений.
Предлагаю вашему вниманию несколько советов по оптимизации и улучшению использования индексов.
Примечание: показанные ниже запросы работают на не модифицированном образце базы данных pagila.
Что заморозили на feature freeze 2019. Часть I. JSONPath
9 мин
После комитфеста 2019-03 произошла заморозка функциональности (feature freeze). У нас это почти традиционная рубрика: о прошлогодней заморозке мы уже писали. Теперь итоги 2019: что из нового войдет в PostgreSQL 12. В этой части обзора, посвященной JSONPath, используются в том числе примеры и фрагменты из доклада «Postgres 12 в этюдах», который прочитал Олег Бартунов на Saint Highload++ в СПБ 9 апреля сего года.
Блокировки в Postgres: 7 советов по работе с блокировками
6 мин
Перевод
И снова здравствуйте! Уже в следующий вторник стартует новый поток по курсу «Реляционные СУБД», поэтому мы продолжаем публиковать полезный материал по теме. Поехали.
На прошлой неделе я писал о конкурентном доступе в Postgres, какие команды блокируют друг друга, и как вы можете диагностировать заблокированные команды. Конечно, после постановки диагноза вам может потребоваться и лечение. С Postgres можно выстрелить себе в ногу, но Postgres также предлагает вам способы не сбить наводку. Вот некоторые из важных советов о том, как стоит и как не стоит делать, которые мы сочли полезными при работе с пользователями по переходу с их единой базы данных Postgres на Citus или при создании новых приложений аналитики в реальном времени.
На прошлой неделе я писал о конкурентном доступе в Postgres, какие команды блокируют друг друга, и как вы можете диагностировать заблокированные команды. Конечно, после постановки диагноза вам может потребоваться и лечение. С Postgres можно выстрелить себе в ногу, но Postgres также предлагает вам способы не сбить наводку. Вот некоторые из важных советов о том, как стоит и как не стоит делать, которые мы сочли полезными при работе с пользователями по переходу с их единой базы данных Postgres на Citus или при создании новых приложений аналитики в реальном времени.
Как мы построили надёжный кластер PostgreSQL на Patroni
9 мин
На сегодняшний день высокая доступность сервисов требуется всегда и везде, не только в крупных дорогих проектах. Временно недоступные сайты с сообщением «Извините, проводится техническое обслуживание» ещё встречаются, но обычно вызывают снисходительную улыбку. Прибавим к этому жизнь в облаках, когда для запуска дополнительного сервера нужен лишь один вызов к API, причем думать о «железной» эксплуатации не надо. И уже не остается оправданий, почему критичная система не была сделана надежно с использованием кластерных технологий и резервирования.
Мы расскажем, какие решения мы рассматривали для обеспечения надёжности баз данных в своих сервисах и к чему пришли. Плюс демо с далеко идущими выводами.
SQL: задача о рабочем времени
3 мин
Здравствуйте, в эфире снова Радио SQL! Разминайте ганглии, расправляйте псевдоподии (или наоборот?) и настраивайтесь на нашу гравитационную волну!
