PostgreSQL *

В этой статье я расскажу о том, как создал шаблон (cookiecutter) и настроил окружение для написания REST API сервиса на С++ с использованием docker/docker-compose и пакетного менеджера conan.

Во время очередного хакатона, в котором я участвовал в качестве бекенд-разработчика, встал вопрос о том, на чем писать очередной микросервис. Все что было написано на текущий момент, писалось мной и моим товарищем на языке Python, так как мой коллега был специалистом в этой области и профессионально занимался разработкой бекендов, в то время как я вообще являлся разработчиком под встроенные системы и писал на великом и ужасном С++, а Python просто подучил в университете.

Так вот, перед нами встала задача написать высоконагруженный сервис, основной задачей которого был препроцессинг поступающих к нему данных и запись их в БД. И после очередного перекура товарищ предложил мне, как С++ разработчику, написать этот сервис на плюсах. Аргументируя это тем, что так будет быстрее, производительнее, да и вообще, жюри будут в восторге от того, как мы умеем распоряжаться ресурсами команды. На что я ответил, что никогда не занимался такими вещами на С++ и с легкостью могу оставшиеся 20+ часов посвятить поиску, компиляции и компоновке подходящих библиотек. Проще говоря, я струсил. На том и порешили и спокойно дописали все на Python.

Предлагаю ознакомиться с расшифровкой доклада начала 2016 года Андрея Сальникова "Типовые ошибки в приложениях, которые ведут к bloat в postgresql"

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

Всем, привет!

В статье я хотел бы рассказать об одном из подходов к логированию приложения, который сильно помогал мне и коллегам при отладке, поиске ошибок и анализе проблем производительности. Про необходимость логирования было написано множество хороших статей в том числе и на Хабре, поэтому здесь нет большого смысла повторяться. Я начинал карьеру в IT с Oracle и изучал эту БД по книгам главного эксперта — Тома Кайта. Мне запомнилась его фраза по поводу логирования из книги "Effective Oracle by Design":

Instrumentation is not overhead. Overhead is something you can remove without losing much benefit. Removing (or not having) instrumentation takes away considerable functionality. You wouldn’t need to do this if your systems never break, never need diagnostics, and never suffer from performance issues. If that is true, you don’t need to instrument your system (and send me your email address, because I have a job offer for you).

С работой над Oracle проектами всё и началось.

В последнее время я опять вижу, что усилился хайп вокруг реактивного программирования в общем, и реактивной работе с Базами данных — в частности. У меня есть пара фраз, которые я бы хотел сказать по этому поводу.

Первые 70% курса по SQL кажутся довольно простыми. Сложности начинаются на остальных 30%.

С 2015 по 2019 годы я прошёл четыре цикла собеседований на должность аналитика данных и специалиста по анализу данных в более чем десятке компаний. После очередного неудачного интервью в 2017 году — когда я запутался в сложных вопросах по SQL — я начал составлять задачник с вопросами по SQL средней и высокой сложности, чтобы лучше готовиться к собеседованиям. Этот справочник очень пригодился в последнем цикле собеседований 2019 года. За последний год я поделился этим руководством с парой друзей, а благодаря дополнительному свободному времени из-за пандемии отшлифовал его — и составил этот документ.

Есть множество отличных руководств по SQL для начинающих. Мои любимые — это интерактивные курсы Codecademy по SQL и Select Star SQL от Цзы Чон Као. Но в реальности первые 70% из курса SQL довольно просты, а настоящие сложности начинаются в остальных 30%, которые не освещаются в руководствах для начинающих. Так вот, на собеседованиях для аналитиков данных и специалистов по анализу данных в технологических компаниях часто задают вопросы именно по этим 30%.

Удивительно, но я не нашёл исчерпывающего источника по таким вопросам среднего уровня сложности, поэтому составил данное руководство.

Предлагаю ознакомиться с расшифровкой доклада начала 2016 года Владимира Ситникова "PostgreSQL и JDBC выжимаем все соки"

Эффект раздувания таблиц и индексов (bloat) широко известен и присутствует не только в Postgres. Есть способы борьбы с ним “из коробки” вроде VACUUM FULL или CLUSTER, но они блокируют таблицы во время работы и поэтому не всегда могут быть использованы.

В статье будет немного теории о том, как возникает bloat, как с ним можно бороться, о deferred constraints и о проблемах, которые они привносят в использование расширения pg_repack.

Предлагаю ознакомиться с расшифровкой доклада начала 2019 года Андрея Сальникова "Управление нагрузкой на PostgreSQL, когда одного сервера уже мало"

Основные тезисы:
1) Стандартные практики распределения нагрузки в PostgreSQL. Сначала мы обсудим причины возникновения высокой нагрузки на базу данных. Следующим этапом рассмотрим те методы распределения нагрузки.
2) Будут рассмотрены вопросы того, как устроена репликация в PostgreSQL, какие есть различия между синхронными и асинхронными репликами, как правильно настраивать реплики.

Сегодня не будет никаких сложных кейсов и мудреных алгоритмов на SQL. Все будет очень просто, на уровне Капитана Очевидность — делаем просмотр реестра событий с сортировкой по времени.

То есть вот лежит в базе табличка events, а у нее поле ts — ровно то самое время, по которому мы хотим эти записи упорядоченно показывать:

CREATE TABLE events(
  id
    serial
      PRIMARY KEY
, ts
    timestamp
, data
    json
);

CREATE INDEX ON events(ts DESC);

Понятно, что записей у нас там будет не десяток, поэтому нам потребуется в каком-то виде постраничная навигация.

#0. «Я у мамы погроммист»

cur.execute("SELECT * FROM events;")
rows = cur.fetchall();
rows.sort(key=lambda row: row.ts, reverse=True);
limit = 26
print(rows[offset:offset+limit]);

Даже почти не шутка — редко, но встречается в дикой природе. Иногда после работы с ORM бывает тяжело перестроиться на «прямую» работу с SQL.

Но давайте перейдем к более распространенным и менее очевидным проблемам.

Микросервисная архитектура, как и все в этом мире, имеет свои плюсы и свои минусы. Одни процессы с ней становятся проще, другие — сложнее. И в угоду скорости изменений и лучшей масштабируемости нужно приносить свои жертвы. Одна из них — усложнение аналитики. Если в монолите всю оперативную аналитику можно свести к SQL запросам к аналитической реплике, то в мультисервисной архитектуре у каждого сервиса своя база и, кажется, что одним запросом не обойтись (а может обойтись?). Для тех, кому интересно, как мы решили проблему оперативной аналитики у себя в компании и как научились жить с этим решением — welcome.


Меня зовут Павел Сиваш, в ДомКлике я работаю в команде, которая отвечает за сопровождение аналитического хранилища данных. Условно нашу деятельность можно отнести к дата инженерии, но, на самом деле, спектр задач гораздо шире. Есть стандартные для дата инженерии ETL/ELT, поддержка и адаптация инструментов для анализа данных и разработка своих инструментов. В частности, для оперативной отчетности мы решили «притвориться», что у нас монолит и дать аналитикам одну базу, в которой будут все необходимые им данные.

Привет, Хабр!

Мы продолжаем исследовать тему Java и Spring, в том числе, на уровне баз данных. Сегодня предлагаем почитать о том, почему при проектировании больших приложений именно структура базы данных, а не код Java, должна иметь определяющее значение, как это делается, и какие исключения есть из этого правила.

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

Речь пойдет про настройки TOAST и выравнивание данных. «В среднем» эти способы позволят сэкономить не слишком много ресурсов, зато — вообще без модификации кода приложения.


Однако, наш опыт оказался весьма продуктивным в этом плане, поскольку хранилище почти любого мониторинга по своей природе является большей частью append-only с точки зрения записываемых данных. И если вам интересно, как можно научить базу писать на диск вместо 200MB/s вдвое меньше — прошу под кат.

Предлагаю ознакомиться с расшифровкой доклада начала 2020 года Георгия Рылова "WAL-G: новые возможности и расширение сообщества"

У меинтейнеров open-source возникает множество проблем по мере их роста. Как писать все больше требуемых фич, чинить все больше issues'ов и успевать смотреть все больше pull request'ов? На примере WAL-G(backup-tool for PostgreSQL) расскажу про то, как мы решали эти проблемы, запустив курс по Open-source разработке в университете, чего мы добились и куда будем двигаться дальше.

Доброго дня, коллеги и хаброчитатели! Сегодня, хотел бы поделиться с Вами небольшой заметкой о том, как можно организовать оперативный мониторинг ошибок и событий появляющихся в журнале PostgreSQL используя Prometheus и экспортер метрик grok_exporter.

Сразу оговорюсь, что это конечно же частный случай использования данного экспортера. Так для чего это нужно и кому это может быть интересно?

Предлагаю ознакомиться с расшифровкой доклада начала 2020 года Андрея Бородина "Odyssey: архитектура, настройка, мониторинг"

Совсем недавно мы выпустили версию 1.0 нашего пулера соединений Odyssey. Он призван решить проблемы управления соединениям высоконагруженных инсталляций PostgreSQL. В этом докладе я хотел бы рассказать об архитектуре и эксплуатации Одиссея. Также будут затронуты проблемы, которые были решены в достаточно длинном переходе между 1.0rc и 1.0.

Жизнь продолжается. Продолжаем знакомить вас с самыми интересными новостями PostgreSQL

Главная новость

Feature Freeze
Функциональность 13-й версии PostgreSQL заморожена. Теперь только доработки и исправления багов. Список нового, вопреки многим ожиданиям, довольно обширный. Читайте нашу статью
Много ли нового в «Чёртовой дюжине», где много примеров. Но и в разделе Статьи Postgresso есть ссылки на статьи, посвященные отдельным фичам.

Релизы

Postgres Pro Enterprise 12.2.1

В этой версии совмещены новшества PostgreSQL 12 и особенности ветки Enterprise.
Расширение multimaster: как и в 11.x, и в других версиях Enterprise, рекомендуется использовать в конфигурации 2+1, когда один из узлов рефери. Подробнее в документации. А ещё теперь можно проверить согласованность данных на узлах кластера, используя функцию mtm.check_query().

В CFS теперь можно выбирать алгоритмы сжатия. Поддерживаются zstd (по умолчанию), zlib и pglz, но можно добавить другие алгоритмы.

Ещё одна ударная фича Enterprise — механизм PTRACK, необходимый для эффективной работы нашего приложения pg_probackup, — был основательно переработан и получил новый внешний API. Чтобы резервные копии, уже созданные с PTRACK в pg_probackup, работали в Postgres Pro Enterprise 12.x, нужно обновить pg_probackup до версии 2.2.6 или выше и настроить копирование PTRACK заново.

Важный патч дедупликации индексов B-tree (автор Анастасия Лубенникова, Postgres Professional) в PostgreSQL 13, но его функциональность уже есть в Enterprise 12.2.1. Причем исключение дубликатов можно отключить для создаваемых индексов, воспользовавшись параметром deduplicate_items команды CREATE INDEX. Об этом есть здесь.

Предлагаю ознакомиться с расшифровкой доклада Николая Самохвалова "Промышленный подход к тюнингу PostgreSQL: эксперименты над базами данных"

Shared_buffers = 25% – это много или мало? Или в самый раз? Как понять, подходит ли эта – довольно устаревшая – рекомендация в вашем конкретном случае?

Пришло время подойти к вопросу подбора параметров postgresql.conf "по-взрослому". Не с помощью слепых "автотюнеров" или устаревших советов из статей и блогов, а на основе:

1. строго выверенных экспериментов на БД, производимых автоматизированно, в больших количествах и в условиях, максимально приближенных к "боевым",
2. глубокого понимания особенностей работы СУБД и ОС.

Используя Nancy CLI (https://gitlab.com/postgres.ai/nancy), мы рассмотрим конкретный пример – пресловутые shared_buffers – в разных ситуациях, в разных проектах и попробуем разобраться, как же подобрать оптимальную настройку для нашей инфраструктуры, БД и нагрузки.

Эту статью написал еще пару лет назад, и не знал куда ее можно было бы выложить, а потом и забыл.

Смысл использования языка С при разработке расширений для PostgreSQL по сравнению с интерпретируемыми (скриптовыми) языками можно свести к двум положениям: производительность и функциональность. Ну а по простому, код написанный на С будет работать намного быстрее, например, если функция вызывается миллион раз в запросе на каждую запись. А более конкретно, некоторые возможности PostgreSQL и вовсе нельзя сделать кроме как на С, например, в других языках не поддерживаются типы (особенно если возвращать значение из функции) ANYELEMENT, ANYARRAY и особенно важный VARIADIC.

28 февраля прошел митап @Databases, организованный Mail.ru Cloud Solutions. Более 300 участников собрались в Mail.ru Group, чтобы обсудить актуальные проблемы современных производительных баз данных.

Под катом видео выступлений: как «Газинформсервис» готовит безопасные СУБД без потери производительности; Arenadata рассказывает, что лежит в основе Greenplum — мощной массивно-параллельной СУБД для аналитических задач; а Mail.ru Cloud Solutions — как и на чем строили свою платформу интернета вещей (спойлер: не обошлось без Tarantool).

Недавно я рассказал, как с помощью типовых рецептов увеличить производительность SQL-запросов «на чтение» из PostgreSQL-базы. Сегодня же речь пойдет о том, как можно сделать более эффективной запись в БД без использования каких-либо «крутилок» в конфиге — просто правильно организовав потоки данных.

#1. Секционирование

Статья про то, как и зачем стоит организовывать прикладное секционирование «в теории» уже была, здесь же речь пойдет о практике применения некоторых подходов в рамках нашего сервиса мониторинга сотен PostgreSQL-серверов.