PostgreSQL *

Сегодня будет рассказ про избыточные группировки и сортировки в SQL-запросах - как они возникают, по каким признакам их можно потом вычислить и как избавиться от них.

Привет, Хабр! Меня зовут Иван Чувашов, я сертифицированный администратор PostgreSQL с 13-летним опытом работы с БД. Хочу поговорить на весьма актуальную в последнее время тему — о миграции на PostgreSQL с Oracle. Расскажу, зачем вообще тратить время и деньги на миграцию, какие для этого понадобятся компетенции, какие есть варианты миграции, как этот процесс можно организовать и избежать типичных ошибок.

Для работы бывает полезно иметь несколько копий одной реальной базы для экспериментов, фикстур или просто тестовых приложений. База растет и время копирования через разворачивание дампа или с помощью шаблона также возрастает до утомительных величин. Для решения этого кейса уже описаны варианты использования файловой системы с поддержкой CoW - Btrfs. В интернете находил  такие инструкции, они сводятся к тому, что делается снепшот всего сервера. И для работы второго "скопированного" нужно перегенерировать pid и сменить порт для предотвращения конфликтов. Этот способ довольно универсальный относительно конфигурации баз на сервере, но кажется имеет ограничение для неопределенного кол-ва параллельных снепшотов серверов.

В этой статье предлагаю свой вариант реализации снепшотов на одном экземпляре сервера postgres и одной базы, на произвольное кол-во копий.

Инструкция linux only, про поддержку CoW файловых систем на Windows не в курсе.

Самый больной вопрос для любого разработчика, которому приходится вычитывать данные из базы: "Как сделать мой запрос быстрее?". Классический ответ - необходимо создать подходящий индекс. Но куда именно его стоит "накатывать", да и как вообще он должен выглядеть?..

Мы научили наш сервис визуализации планов PostgreSQL отвечать на эти вопросы, и под катом расскажем, чем именно он руководствуется в своих рекомендациях.

Feature Freeze

SQL/JSON

Пингвины для привлечения внимания. Как поднять Apache Superset, подключить к нему локальный Postgres и чтобы потом на вас коллеги не смотрели косо.

Вчера Hubert 'depesz' Lubaczewski закрыл доступ с российских IP ко всем своим сайтам, включая широко известный визуализатор планов PostgreSQL-запросов explain.depesz.com.

Но это не беда, потому что в компании "Тензор" мы разработали сервис explain.tensor.ru, функционал которого гораздо обширнее, и которым можете воспользоваться и вы.

Существует великое множество статей об оптимизации PostgreSQL — эта «кроличья нора» весьма глубока. Когда несколько лет назад я начал разрабатывать бэкэнд аналитического сервиса, у меня уже был опыт работы с другими СУБД, такими как MySQL и SQL Server. Тем не менее, раньше мне не приходилось так фокусироваться на производительности. В прошлых проектах, над которыми я работал, либо не было жестких требований к времени обработки (DS/ML), либо не требовалось обрабатывать много строк одновременно (обыкновенные веб-приложения). Однако в этот раз мои запросы:

• состояли из 3-10 JOIN-ов по коррелирующим запросам;

• уielded от 10 до 1,000,000 строк;

• должны были выполняться в течение времени, определенного UX-ом;

• не могли быть hinted — пока Cloud SQL, управляемый PostgreSQL в Google Cloud, не стал поддерживать pg_hint_plan в конце 2021 года;

• запрещали прямой доступ к серверному процессу, чтобы, например, хакнуть некоторые perf — потому что PostgreSQL был managed.

Получение целого миллиона строк в одном API endpoint сигнализирует о проблеме в алгоритме или архитектуре. Конечно, все можно переписать и перепроектировать, но за это нужно платить.

У нас не нашлось «заклинания», которое решило бы все проблемы с производительностью SQL. Тем не менее, я упомяну здесь несколько дельных предложений, которые помогли нам и, надеюсь, смогут помочь читателю. Разумеется, это не какие-то сакральные знания. Но когда мы начинали оптимизацию, я был бы рад их прочитать или услышать.

В процессе обучения аналитике данных у человека неизбежно возникает вопрос о миграции данных из одной среды в другую. Поскольку одним из необходимых навыков для аналитика данных является знание SQL, а одной из наиболее популярных СУБД является PostgreSQL, предлагаю рассмотреть импорт и экспорт данных на примере этой СУБД.

В своё время, столкнувшись с импортом и экспортом данных, обнаружилось, что какой-то более-менее структурированной инфы мало: этот момент обходят на всяких там курсах по аналитике, подразумевая, что это очень простые моменты, которым не следует уделять внимание.

В данной статье приведены примеры импорта в PostgreSQL непосредственно самой базы данных в формате sql, а также импорта и экспорта данных в наиболее простом и распространенном формате .csv, в котором в настоящее время хранятся множество существующих датасетов. Формат .json хоть и является также очень распространенным, рассмотрен не будет, поскольку, по моему скромному мнению, с ним все-таки лучше работать на Python, чем в SQL.

Доклад Алексея Лесовского про то, что нового есть в PostgreSQL в плане мониторинга.

Охватывать Алексей будет 13 и 14 версии. Далее от его лица.

Соблазн использовать модель EAV (Entity-Attribute-Value) при организации структуры БД весьма велик, особенно когда предметная область заранее плохо известна (или разработчик просто не хочет в нее углубляться). Это ведь так удобно - создать "универсальный" способ описания характеристик объектов, который больше не потребует доработок базы ни при появлении новых типов объектов, ни при возникновении новых атрибутов...

Однако, за любую универсальность приходится платить сложностью и производительностью запросов - так что json[b] может оказаться более эффективной заменой. Но если уж такая модификация невозможна - давайте попробуем выжать максимум производительности из доставшегося нам legacy на самом простом примере.

Во встроенном процедурном языке PL/pgSQL для СУБД PostgreSQL отсутствуют привычные операторы TRY / CATCH для для перехвата исключений возникающих в коде во время выполнения. Аналогом является оператор EXCEPTION.

Мой путь по созданию бота в Telegram.

Выкладываем запись с Ozon Tech PostgreSQL Meetup. Ранее я уже описывал нашу инфраструктуру: весь PostgreSQL основан на виртуальных машинах — 2К в тестовой среде и ~8К в проде. Это около 2К кластеров баз данных. Так как у нас микросервисная архитектура, мы придерживаемся принципа 1 сервис = 1 база. Нагрузка на базы может быть приличная: 2-2,5 млн транзакций в секунду, а WAL-трафик порядка 1.5 ГБ/c. 

Рассказали, как наша команда управляет всей этой инфраструктурой, как пришли к парадигме выдачи базы по кнопке и как воплотили её в жизнь. 

Миграция

Часто пользователи рассказывают о сбое базы данных по вине Out Of Memory Killer. Он завершает процессы PostgreSQL и остается причиной большинства отказов этой БД. Память на хост-компьютере может закончиться по нескольким причинам. Наиболее распространены из них четыре. Во-первых, может быть плохо настроена память на хост-компьютере. Во-вторых, могут быть ограничения глобальной переменной work_mem. Например, если у вас 32Гб RAM и work_mem=1Гб, то больше 32 соединений вы никогда не запустите. Каждое соединение PostgreSQL будет выделять этот размер памяти.

Третьей причиной будет большое количество подключений. Даже неактивное соединение может занимать значительный объем памяти. И наконец, другие программы тоже потребляют ресурсы, потому что для каждой из них этот компьютер является хостом.

Представляем вам перевод статьи от Jobin Augustine, который работает в Percona старшим инженером службы поддержки. Более 20-лет он был консультантом, архитектором, администратором и инструктором по PostgreSQL, Oracle и другим технологиям баз данных. Сегодня поговорим о том, как можно защититься от OOM с помощью HugePages и разберем насколько они важны и почему нужны.

Всем привет, данная статья является, своего рода моей первой, но все же постараюсь максимально просто рассказать вам о том, как создать бота, прикрутив к нему все обещанные выше свистелки-тарахтелки.

Статьи будут разделены на 2 части, первая часть - создание основного бота с оправкой логов (Kafka Producer) и записью их в БД, вторая часть - обработка всех логов (Kafka Consumer).