Вольный перевод статьи «7 Best Practice Tips for PostgreSQL Bulk Data Loading»

Иногда возникает необходимость в несколько простых шагов загрузить в БД PostgreSQL большой объём данных. Данная практика обычно называется массовым импортом, когда в качестве источника данных служит один или несколько больших файлов. Данный процесс иногда может проходить неприемлемо медленно. Существует несколько причин такой низкой производительности. Вызывать задержки могут индексы, триггеры, внешние и первичные ключи или даже запись WAL – файлов.

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

Решение на базе Docker, которое позволит создать на локальном компьютере универсальную среду разработки на PHP за 30 - 40 минут. Несколько версий PHP — 7.3 и 7.1 с набором наиболее востребованных расширений. Готовый к работе монитор процессов Supervisor. Предварительно сконфигурированный веб-сервер Nginx. Базы данных: MySQL 5.7, MySQL 8, PostgreSQL, MongoDB 4.2, Redis. Настройка основных параметров окружения через файл .env. Возможность модификации сервисов через docker-compose.yml.

Это цитата одного из моих знакомых который когда-то давно обращался ко мне с вопросом про Postgres. Тогда мы за пару дней порешали его проблему и поблагодарив меня он добавил: "Хорошо, когда есть знакомый DBA".

Но что делать если нет знакомого DBA? Вариантов ответа может быть довольно много, начиная от поискать среди друзей друзей и заканчивая до изучить вопрос самостоятельно. Но какой бы ответ не пришел к вам в голову, у меня для вас хорошая новость. В тестовом режиме мы запустили сервис рекомендаций для Postgres'ов и всего что вокруг них.

При разработке приложений иногда возникает потребность в сравнении двух баз данных (например prod и dev).

Существует ряд подходов для решения этого вопроса - от создания dump-файла со структурой db и последующим использованием diff, до использования специализированных платных решений типа dbForge или RedGate.

Одним из таких решений, сочетающих бесплатность и удобство использования, является Compalex.

Публикация основана на докладе тренера и инженера технической поддержки Zabbix Александра Петрова-Гаврилова.

Многих волнует вопрос о том как мигрировать с MySQL на PostgreSQL и воспользоваться преимуществами TimescaleDB.

Зачем мигрировать

Первый вопрос, который обычно возникает, — зачем мигрировать с MySQL на PostgreSQL при использовании Zabbix.

Вариантов не так много, особенно если система уже работает и работает неплохо. Возможные причины для миграции:

• Команда лучше разбирается в PostgeSQL.
• Желание попробовать TimescaleDB, учитывая обещанное повышение производительности и экономию места.
• Документация на русском языке
• Преимущества PostgreSQL Pro.

 
За основную часть перехода информационных систем с Oracle на PostgreSQL часто отвечают инструменты автоматической конвертации. Но среди гигантского объёма кода, покрываемого такими решениями, есть и исключительные истории, с которыми приходится импровизировать. В таких случаях первым делом, конечно, необходимо локализовать проблему, установить её причину и, чтобы подобрать правильное решение, подумать, нет ли аналогичных реальных или вымышленных ситуаций, которые могли бы иметь похожую природу. После этого обычно приходится рефакторить оригинальный код на Oracle, дорабатывать процессы конвертации и грамматику или реализовывать на PostgreSQL не имеющую аналогов функциональность Oracle. Однажды нам бросил вызов, на первый взгляд, примитивный запрос с ошибкой, для решения которой пришлось проводить целое расследование.

В этой статье мы научимся шифровать бэкапы, загружать их в S3-совместимое хранилище (вместо второго сервера-репозитория), восстанавливаться на чистый кластер и, наконец, восстанавливаться на определенный момент времени (point in time recovery, PITR).

Вы только что установили PostgreSQL и запустили ваш первый кластер, создали несколько таблиц, загрузили данные, и даже немного подкрутили конфигурацию PostgreSQL для улучшения производительности. Теперь вы думаете о том, как сделать ваш кластер высокодоступным. К сожалению, PostgreSQL не умеет сам выполнять автоматическое переключение при недоступности мастера, но, к счастью для нас, этого можно достичь с помощью сторонних утилит. Задача ясна, и вы начинаете изучать преимущества и недостатки всех утилит, чтобы выбрать лучшую. И… вы уже на неправильном пути, потому что в первую очередь вы должны определиться со значениями SLA, RTO и RPO. В этом докладе я планирую рассказать о ряде ошибок, которые допускают администраторы баз данных при настройке и эксплуатации высокодоступного кластера Постгреса с автоматическим переключением.

Релизы

Вот и меня посетило желание что-нибудь написать для читателей Хабра. Чем же ещё заняться в отпуске?

Казалось бы, про пейджинг уже написано всё, что только можно было. И этот текст тоже на уникальность и открытия не претендует. Но, по крайней мере, лично мне не попадалось таких текстов, чтобы тема пейджинга в реляционных базах была раскрыта не отдельными аспектами, а последовательно и подробно. Поэтому я всё-таки попробую и буду надеяться, что хотя бы одна-две детали в этом тексте покажутся читателю интересными.

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

Введение

Некоторое время назад передо мной поставили задачу разработать отказоустойчивый кластер для PostgreSQL, работающий в нескольких дата-центрах, объединенных оптоволокном в рамках одного города, и способный выдержать отказ (например, обесточивание) одного дата-центра. В качестве софта, который отвечает за отказоустойчивость, выбрал Pacemaker, потому что это официальное решение от RedHat для создания отказоустойчивых кластеров. Оно хорошо тем, что RedHat обеспечивает его поддержку, и тем, что это решение универсальное (модульное). С его помощью можно будет обеспечить отказоустойчивость не только PostgreSQL, но и других сервисов, либо используя стандартные модули, либо создавая их под конкретные нужды.

К этому решению возник резонный вопрос: насколько отказоустойчивым будет отказоустойчивый кластер? Чтобы это исследовать, я разработал тестовый стенд, который имитирует различные отказы на узлах кластера, ожидает восстановления работоспособности, восстанавливает отказавший узел и продолжает тестирование в цикле. Изначально этот проект назывался hapgsql, но со временем мне наскучило название, в котором только одна гласная. Поэтому отказоустойчивые базы данных (и float IP, на них указывающие) я стал именовать krogan (персонаж из компьютерной игры, у которого все важные органы дублированы), а узлы, кластеры и сам проект — tuchanka (планета, где живут кроганы).

Сейчас руководство разрешило открыть проект для open source-сообщества под лицензией MIT. README в скором времени будет переведен на английский язык (потому что ожидается, что основными потребителями будут разработчики Pacemaker и PostgreSQL), а старый русский вариант README я решил оформить (частично) в виде этой статьи.

Intro

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

Более полно о принципах работы сервиса можно посмотреть в видео доклада и прочитать в статье «Массовая оптимизация запросов PostgreSQL».