Подборка бесплатных обучающих материалов о PostgreSQL
Привет, Хабр! Новая пятница — новая порция обучающих статей. Сегодня собрал публикации, которые помогут тем, кто хочет лучше разобраться в PostgreSQL. По классике: все бесплатно. Чтобы прочитать подборки, даже регистрироваться нигде не нужно. Бонусом в конце поста будет ссылка на курс. Он тоже не стоит ни копейки, но там все же нужно зарегистрироваться. Итак, поехали.
PostgreSQL для новичков
В подборке 14 статей на два с половиной часа чтения. Здесь база: установка и настройка PostgreSQL, нюансы управления, резервного копирования и репликации. Для ленивых — что делать, если администрировать самим БД не хочется.
Средний уровень
В девяти статьях за полтора с небольшим часа рассматриваем настройку PostgreSQL в Docker и для работы с 1С. Вы разберетесь в командах, триггерах, индексах и организации мониторинга.
PostgreSQL на максималках: практикум по расширениям
Пять статей и чуть больше часа на их изучение. Эта подборка — ваш гид по расширениям PostgreSQL: от безопасности и оптимизации до работы с геоданными. Вы познакомитесь со всеми этими pgcrypto, jsquery и т. д., а заодно научитесь применять их без лишней теории.
Бонус. Бесплатный онлайн-курс для новичков «Погружение в PostgreSQL»
В семи уроках вы освоите основы SQL, научитесь создавать и связывать таблицы, выполнять базовые операции с данными. Эти знания станут хорошим стартом для дальнейшего изучения PostgreSQL. Курс подойдет начинающим администраторам баз данных, разработчикам, DevOps-инженерам и аналитикам.
Дарим 35 000 рублей, чтобы протестировать сервисы Evolution Data Platform 🎁
Переходите по ссылке, чтобы получить 35 000 рублей и попробовать сервисы для работы с Big Data и машинным обучением. Оцените интерактивную аналитику, постройте ETL-пайплайны и Data Lakehouse-решения для вашего бизнеса.
Какие сервисы можно протестировать с бонусными рублями?
Evolution Managed Trino — аналитический SQL-движок Trino, чтобы облегчить обработку больших объемов данных с помощью распределенных запросов.
Evolution Managed Spark позволит развернуть кластерный вычислительный сервис, создать и конфигурировать инстансы Spark.
Evolution Managed BI — облачный сервис для удобной визуализации и анализа данных. Собирайте информацию из MySQL, Oracle, PostgreSQL и других источников — и стройте на их основе графики, таблицы и диаграммы.
Evolution Managed Airflow позволяет обрабатывать данные по принципу ETL, объединять задачи в пайплайны, планировать и запускать их по расписанию.
Тратьте бонусные рубли прозрачно: 1 бонус = 1 рубль. Получить подарок можно до конца года, а действовать он будет 60 дней с момента активации.
🚀 Объём корпоративных данных растёт на десятки процентов в год, а специалистов всё так же не хватает. В статье для VC.RU мы вместе с Екатериной Ризановой рассказали, как ИИ-агенты помогают решать эту проблему: берут на себя рутинные задачи в хранилищах данных и BI-системах, ускоряют работу команд и экономят компаниям миллионы рублей в год.
ИИ-агент — это не чат-бот. Он сам выполняет действия: анализирует код витрин, строит lineage, генерирует SQL, находит инсайты и помогает сотрудникам сосредоточиться на действительно важных задачах.
Если вы изучаете базы данных или давно не работали с ними и хотите проверить знания, приглашаем пройти наш новый квиз. Ответьте на несколько теоретических вопросов и попробуйте расшифровать SQL-запросы — в конце получите промокод на 1000 бонусов в панели Selectel.
# transform.py
def calculate_age(birth_date, row_data, table):
from datetime import datetime
if not birth_date:
return None
birth = datetime.strptime(birth_date, '%Y-%m-%d')
return (datetime.now() - birth).days // 365
def format_phone(phone, row_data, table):
if not phone:
return None
# 79991234567 -> +7 (999) 123-45-67
return f"+7 ({phone[1:4]}) {phone[4:7]}-{phone[7:9]}-{phone[9:11]}"
Запуск
# Установка с GitHub
pip install git+https://github.com/tumurzakov/myrepetl.git
# Или клонировать и установить локально
git clone https://github.com/tumurzakov/myrepetl.git
cd myrepetl
pip install -e .
# Запуск с конфигом
myrepetl run config.json
# Или через Docker
docker run -v ./config.json:/app/config.json myrepetl:latest
Чтение данных выполняется посредством функций Get() и All(). Возвращаемые ими Ptrsz указывают на внутренние структуры MemDb. Они остаются валидными пока не завершена транзакция и не было вызовов Set() и Del(), инвалидирующих указатели.
Изменение данных выполняется посредством функций Set() и Del(). MemDb копирует себе байты, на которые указывают key и val.
Функции DependVal() и DependDel() устанавливают зависимости. Их проверяет Commit().
Функции Commit() и Rollback() завершают транзакцию. Завершают, но не закрывают! Мы ОБЯЗАНЫ вызвать Close()!!
Просто Close() означает Rollback().
------------------8<------------------
Вот, кстати, полный текст статьи, но там почти что невозможно обнаружить ссылку на исходники... Ага, не раз такое видел в комментариях!
Приглашаем на Java Jam — бесплатный митап ЮMoney для Java-разработчиков
Спикеры из ЮMoney и главный эксперт по технологиям Сбера расскажут о своём опыте и пообщаются с аудиторией. Вот какие темы будут на митапе:
🟣 Как мы уменьшали нагрузку на базы данных в очередях задач. Расскажем, как реализовать надёжное асинхронное и отложенное исполнение задач.
🟣 Советы по производительному коду. Поговорим про время выполнения программ, работу со строками и коллекциями, вещественную и битовую арифметику, алгоритмические трюки и многое другое.
🟣 Уязвимости не пройдут. Обсудим, как повысить безопасность разработки с помощью SAST и SCA.
25 сентября, в четверг, в 18:30 (мск) — приходите на митап в Санкт-Петербурге или подключайтесь онлайн!
Митап от разработчика СУБД Tantor Postgres и машин баз данных Tantor XData пройдет в Москве. Это отличный повод встретиться для всех, кто интересуется развитием российских СУБД и будущим сферы управления корпоративными данными.
Новая версия платформы Tantor — ведущего enterprise-решения для администрирования и мониторинга любых БД на основе PostgreSQL;
Новинки СУБД Tantor Postgres для более высокой производительности и защищённости данных;
Инструментарий для управления интеграциями и загрузкой данных, осуществления миграций с минимумом даунтайма;
Особое внимание будет уделено Tantor XData — первой российской машине баз данных от вендора СУБД, созданной для самых сложных промышленных задач, высоконагруженных защищённых систем и крупномасштабной аналитики в стратегически важных отраслях.
Митап пройдет 19 сентября 2025 г. на 40-м этаже башни Mercury Space по адресу: Москва, 1-й Красногвардейский проезд, 15. Регистрация участников стартует в 12.00.
Может ли кто-нибудь создать Википедию Вселенной, других цивилизаций?
По стилю - современная Википедия (или похоже), но разных миров и как будто с информацией из условного 100к-ого года нашей эры, где человечество выжило и знает намного больше о Вселенной. Например, чтобы Проксима b была с картой, историей и т.д.
Да, есть много фантастики, но целая фантастическая Википедия - этого у нас пока нет. Есть множество Вики по различным сюжетам, но это не то же самое. В "Википедии Вселенной" может быть надпись, которую видят все новые пользователи: "Что, если бы мы знали намного больше о Вселенной? Если бы у нас были Википедии других цивилизаций? Этот проект - фантазия людей и ИИ на тему", а дальше или случайная генерация одной из "Википедий будущего", или несколько на выбор, или одна.
Лутаем Open Source #24. Они наконец-то починили MongoDB! Перенеся его на PostgreSQL...
DocumentDB – БД от Microsoft, которая состоит из 3-х частей:
PG расширение, добавляющее BSON формат (написанный, на С)
CRUD API поверх него (С)
Сервис трансляции Mongo Query в SQL (Rust)
GitHub - documentdb/documentdb: MongoDB-compatible database engine for cloud-native and open-source workloads. Built for scalability, performance, and developer productivity.
И вроде как: "PG – классная база, а MongoDB Query + BSON популярные технологии" – и можно было бы поразмышлять чем это круто, но сначала важно ответить на один туманный вопрос: "кому такая БД может быть нужна?"
Классический PG
Сначала рассмотрим кейс, когда мы накладываем DocumentDB на обычный PostgreSQL.
Те, кто используют MongoDB если попробуют переехать на такой сэтап столкутся с тем, что:
Там нет шардинга (и насколько бы он не был сложно реализован в MongoDB, он есть и им активно пользуются)
Придется использовать двойной тулинг: Compas, чтобы наблюдать за корректностью данных с MongoDB Query, и SQL если надо посмотреть что там внутри
MongoDB поддерживает Uncommitted Read и Write Majority, что странно накладывается на PG: если разраб достаточно продвинутый и намеренно использовал Uncommitted, то с PG он потеряет скорость и Availability из-за PG Committed, а если он использовал Write Majority, то PG не совсем дает такую гарантию (обвал диска при WAL репликации – менее надежен, чем Write Majority)
А самое главное: когда ты работаешь с MongoDB ты можешь открывать 1000 коннекшенов и он вполне себе все это сожрет, потому что (1) коннекшен это тред, (2) при запросах нет никакой проверки реляционной целостности, да и в целом проверка сильно проще, чем в PG, а значит придется потанцевать с пуллерами и даже менять где-то запросы, чтобы не упасть по скорости
То есть, у mongo-юзеров это заберет все особенные фичи MongoDB и при этом не даст фишки PostgreSQL.
Distributed PG-like
А что, если мы положим DocumentDB на что-нибудь из серии CockroachDB, YugabyteDB, AWS Aurora, Citus или Neon?
Все 3 проблемы решаются:
Шардинг из коробки
Достаточно высокая скорость записи и чтения
Отсутствие проблем с коннектами
В такой ситуации DocumentDB начинает играть новыми красками.
Но если в Neon и Citus (и может YugabyteDB) еще есть шанс добавить текущий DocumentDB BSON плагин, то в для других представителей придется писать его с нуля (причем под каждый свой, потому что они построены каждый на своем KV хранилище).
Переезд в Linux Foundation
А еще они сейчас в процессе переезда из Microsoft в Linux Foundation, из плюсов они будут полностью под MIT лицензией и пейвола, за который будут прятать полезные фичи, из минусов, Microsoft могут и забросить, а никто другой не подхватить.
Итоги
Неоднозначная технология, пока имеет смысл в каких-то тонких кейсах, но в общем и целом, не вижу пока где тут middle-ground, может, вы что-то подскажете?
Как правильно откатывать миграции? Если коротко, то никак.
В продакшене миграции могут идти только вперед. Какого? Откат миграции во время ролбека (при неудачном деплое) во-первых сильно усложняет всю процедуру, во-вторых, в теории, может ее некисло замедлить, уже не говоря про потенциальные локи на время отката. На фоне этого возможны ошибки, которые приведут всю систему в неконсистентное состояние.
Ролбек, в идеале, это просто переключение с одной версии кода на другую. Но ведь тогда возможны ошибки связанные с изменениями в базе? Если делать через жопу, то возможны. При правильном подходе, база всегда обратно совместима как минимум на одну версию. Только в этом случае мы можем обеспечить и бесшовный деплой (zero downtime deploy) и практически моментальный откат.
А это значит, что нельзя менять тип у колонок (если тип сужается), нельзя менять именования таблиц и полей. Если это все таки нужно, то существует немало техник, позволяющих сделать переход через создание новых сущностей и синхронизацией либо через код либо через саму базу (например с помощью триггеров). По этой теме даже написали целую книгу "Refactoring Databases: Evolutionary Database Design".
Получается, что любые ошибки в базе будут только накапливаться? Не совсем. Обратная совместимость обычно нужна только на текущую и следующую версию. Если у нас не коробка, а облачное решение, то одновременно могут работать только две версии. В таком случае, мы без проблем можем писать любые миграции, которые удаляют и меняют все что угодно, что уже не используется. Заметьте, это не откат, а новые миграции.
А вот в разработке откат миграции конечно же удобен. Пока код еще не слит в основную ветку или лежит только локально, то мы без проблем можем откатить и удалить миграции, которые сами же недавно создали, но в процессе проработки поняли что они нам не нужны или их нужно переделать.
Снятся ли управляемым СУБД быстрые NVME-oF RDMA-диски — тема доклада на IT-конференции GoCloud Tech 2025 ☁️
Мы задались вопросом улучшения производительности управляемой PostgreSQL и хотим рассказать, что из этого получилось. По ходу доклада обсудим:
- почему IO Latency имеет значение, а bandwidth нет;
- причем тут подключаемые диски NVME-oF;
- почему offloading — не панацея, а RDMA полезен лишь в малых дозах;
- как провести full-scale эксперименты в целой AZ и остаться вменяемым человеком.
Трек: Data&Analytics — обсудим тренды и возможности облачных сервисов, методы их интеграции с AI-агентами, а также инструменты для быстрого и эффективного решения задач хранения, обработки и анализа данных.
Тренды в мире данных: куда стремятся СУБД и как их сравнивать в новых реалиях — тема доклада на IT-конференции GoCloud Tech 2025 ☁️
Приглашаем обсудить современные тенденции в мире данных. На встрече поговорим о стремлении СУБД к «облачности» и HTAP-универсальности, а еще разберем нововведения в бенчмарках — почему классических решений недостаточно и что с этим делать.
Трек: Data&Analytics — обсудим тренды и возможности облачных сервисов, методы их интеграции с AI-агентами, а также инструменты для быстрого и эффективного решения задач хранения, обработки и анализа данных.
Три способа сформировать идентификатор пользователя.
Привет, меня зовут Рамис и я работаю дата-аналитиком в Garage Eight. Так как аналитики довольно часто (почти всегда) используют id пользователя для объединения таблиц, я хочу рассказать о различных способах формирования идентификатора пользователя (user_id, id, account_id и пр.).
Первый способ, который приходит на ум — это инкрементальное увеличение id пользователя, также известный как последовательный или автоинкрементный ID. То есть самый первый пользователь будет иметь id = 1, следующая регистрация 2 и так далее. Вроде бы идеально?
Плюсы:
Уникальность.
Порядок регистрации.
Простота реализации.
Минусы:
Требуют централизованного управления, что может замедлять работу при масштабировании.
Предсказуемы (идут по порядку), что может быть небезопасно, ведь злоумышленники могут угадать ID. Для генерации нового ID часто нужно обращаться к базе данных (БД), что увеличивает нагрузку.
В шардированных или реплицированных БД могут возникать конфликты и задержки в генерации ID. Невозможно встроить дополнительную информацию (например, временные метки или идентификаторы сервисов).
Кстати, проблему шардирования можно частично решить следующим образом: id увеличивается не на 1, а на число k, равное количеству используемых БД.
Второй способ — UUID, или универсально уникальный идентификатор (Universally Unique Identifier), — это 128-битное число.
Плюсы:
Уникальный, почти никогда не повторяется.
Генерится где угодно, не нужна база данных.
Не угадать, особенно, v4 и v7.
Для больших систем, так что хорошо подходит для микросервисов.
Третий способ — Twitter snowflake id (теперь X) — это система генерации уникальных 64-битных идентификаторов для объектов, таких как твиты, личные сообщения, пользователи и списки.
Бит знака — всегда равно 0 и зарезервировано на будущее.
Временная метка — количество миллисекунд, прошедших с начала эпохи UNIX.
ID ЦОД дает нам 2 ^ 5 = 32 центра обработки данных.
ID компьютера дает нам еще 2 ^ 5 = 32 компьютера в каждом ЦОД.
Номер последовательности.
При генерации каждого id на отдельно взятом компьютере или процессе номер последовательности инкрементируется на 1, каждую миллисекунду этот инкремент обнуляется.
Плюсы:
Уникальность.
Распределенная генерация.
Можно сортировать.
Эффективность. 64-битный формат обеспечивает достаточную ёмкость для идентификаторов, а также эффективную обработку данных.
Простота. Логика генерации Snowflake довольно проста для понимания и реализации.
Популярность. Идентификаторы Snowflake широко используются, что облегчает интеграцию с различными системами и библиотеками.
Минусы:
Ограничение по времени. Максимальная точность Snowflake — миллисекунды, что может быть недостаточно для некоторых приложений, требующих большей точности.
Риск переполнения. При очень высокой скорости генерации идентификаторов существует риск переполнения порядкового номера, что может привести к потере уникальности.
Зависимость от синхронизации времени. Точность временной метки зависит от синхронизации времени на серверах.
Сложность в распределенных системах. При неправильной настройке распределенной системы могут возникать проблемы с уникальностью идентификаторов.
Необходимость управления идентификаторами машин. Каждой машине, генерирующей идентификаторы, необходимо присваивать уникальный идентификатор.
На этом все, но это неполный список, есть еще сервер тикетов и прочие.
Информацию взял из книги «System Design. Подготовка к сложному интервью», Алекс Сюй.
🎬 21 августа в 16:00 (Мск)«От идеи до продакшена: какой Kafka-клиент упростит вам жизнь?» — практический вебинар: какие высокоуровневые клиенты Kafka выбрать для Spring Boot, .NET и NestJS. Разберём ключевые отличия, реальные примеры использования и лучшие практики.
Ни для кого не секрет, что клиент‑серверный вариант 1С изначально затачивался под MS SQL. Вспоминаю год 2017-й и точно помню, что в тот момент Postgres ставили в основном те компании, которые хотели сэкономить. Плевались, но использовали. Чуть более или менее серьезная нагрузка — и всё.
Помню, как мы для «Управления IT‑отделом 8» написали расчет SLA по графикам техподдержки. На файловой базе и в MS SQL все работало прекрасно. Выпустили обновление, но один клиент на Postgres начал жаловаться. Долго выясняли, в чем дело. В конечном итоге я подключился к нему на тестовый сервер, прошелся отладчиком и… бинго! Действительно наша ошибка: не указали сортировку в одном из вложенных запросов. На файловой и на MS SQL такой запрос, повторю, работал отлично. Postgres в этом деле оказался строже — сказано в документации, что выборка не гарантирует порядок? Будьте добры предусмотрите это.
Эта история из прошлого отлично иллюстрирует те же проблемы, с которыми бизнес сталкивается сегодня, когда переход стал практически неизбежным.
Если коротко, то вот главные грабли, на которые наступают при миграции 1С на PostgreSQL:
Проблема № 1: Деградация производительности. Миграция «в лоб» почти всегда приводит к проблемам с блокировками и работой планировщика запросов. Приходится переписывать код и оптимизировать его под PostgreSQL. Возможно, даже менять что‑то в самой платформе.
Проблема № 2: Кадры. Найти опытного DBA по Postgres, который глубоко понимает специфику 1С, значительно сложнее и дороже. С MS SQL всё было проще: установил, клик, клик — готово. Даже без тонких настроек многое работало «из коробки».
Ну и самое главное: миграция — это не просто смена СУБД. Это полноценный проект, требующий тестирования, переписывания узких мест в коде и, возможно, обучения команды. Экономия на лицензиях может быть полностью съедена затратами на внедрение и поддержку (да и не сказал бы, что тот же Postgres Pro дешевый).
А теперь о том, почему этот разговор вообще имеет смысл.
Раньше мы всегда советовали клиентам MS SQL как надежную и проверенную СУБД. Да, в 2015-м появился платный Postgres Pro, но, честно сказать, мы его всерьез не рассматривали. Зачем, если есть деньги на проверенный MS SQL? А если хотелось сэкономить — был бесплатный Postgres со всеми его тогдашними особенностями.
Но потом пришел 2022-й год, санкции вендоров и постепенная миграция стала трендом. А сейчас это уже не вопрос выбора, а вопрос времени.
Уже в 2024 году на новые продажи зарубежного ПО пришлось всего ~10% рынка. Прогноз до 2031 года следующий: российские решения для работы с базами данных могут занять до 99% новых продаж (!) Процесс импортозамещения будет идти, а если мы берем 1С, то тут в выигрыше PostgreSQL/Postgres Pro. Причины понятны: уход западных вендоров, требования регуляторов и развитие отечественных продуктов.
Для компаний использующих 1С это означает полный стратегический переход на Postgres в ближайшие годы. Но, как показывает практика, делать это нужно с умом.
У меня вопрос. Планируете переход на PostgreSQL или, как и мы, пока живете на старом софте?
‑-
Понравилась эта аналитика? В моем блоге Код ИТ‑директора я гораздо чаще делюсь мыслями, короткими кейсами и полезными инструментами, которые не всегда доходят до формата большой статьи.
Внедрение ИИ в работу контакт‑центров уже не обсуждается. Сегодня это необходимость. Но мы переходим на следующую эволюционную ступень развития - это внедрение генеративного интеллекта (генИИ). Мы изучили исследование и в этой публикации - самый сок!
Итак, исследование «Тренды использования генеративного ИИ в клиентском сервисе» проводилось Национальной Ассоциацией Контактных Центров (НАКЦ) в партнёрстве с компанией BSS. В результате выяснилось - 30% клиентских служб уже активно использует генИИ. Ещё 42% используют, но только в некоторых процессах.
Какой была выборка? В исследовании приняли во внимание ответы 465 респондентов из России, Беларуси, Казахстана, Узбекистана и др. стран. Это были представители банковской и финансовой сфер, телекоммуникационных компаний, сервис‑провайдеров, розничной торговли, аутсорсинговых контакт‑центров.
72% опрошенных подтвердили, что активно или частично используют генИИ для обслуживания клиентов. Ещё 24% планируют внедрение данной технологии
Что же хотят от генеративного ИИ? С помощью генИИ компании стремятся создать уникальный и персонализированный клиентский опыт. ИИ способен учитывать множество факторов и данных, что помогает прогнозировать потребности клиентов и проактивно предлагать свои услуги и продукты.
Респонденты заинтересованы в гиперперсонализированных рекомендациях, когда ИИ предлагает индивидуальные товары, услуги, цены или контент на основе истории покупок, предпочтений или поведения пользователя.
Первичная задача использования генИИ — автоматизация клиентского обслуживания с помощью текстовых и голосовых роботов: «Это даёт наиболее быстрый и измеримый эффект: затраты на обслуживание падают, скорость обслуживания растёт»
И все же ключевым трендом и генеральной линией дальнейшего развития генИИ в перспективе ближайших лет эксперты считают мультиагентность. Это как определённая совокупность ботов на генИИ, которые смогут взаимодействовать между собой.
«Мультиагентность предполагает объединение отдельных агентов генИИ в некий "коллектив“ AI‑агентов. И в этом „сообществе“ каждый AI‑агент решает не только свои задачи, но и действует совместно с прочими - они делегируют задачи друг другу»
А вы рассматриваете нанять коллектив генИЕВ в рабочие процессы?
Нулевое время восстановления после сбоя в РЕД Базе Данных
Простой системы - это всегда потери. В отличие от других решений, РЕД База Данных предлагает уникальную на рынке гарантию мгновенного восстановления работоспособности.
Как это реализовано в других СУБД?
В большинстве СУБД надежность обеспечивается с помощью журнала предварительной записи транзакций. При завершении транзакции изменения записываются сначала в журнал и лишь через некоторое время - в саму базу данных. При рестарте системы после аварийного завершения работы это приводит к необходимости синхронизации состояния базы данных с журналом транзакций, что занимает время.
Как сделано в РЕД Базе Данных?
В нашей архитектуре используется иной подход - при подтверждении транзакции измененные страницы записываются на диск в строго определенном порядке, гарантирующем целостность базы данных в любой промежуточный момент времени. Это позволяет продолжить работу сразу после перезапуска системы без дополнительных процедур восстановления.
Для кого важно?
Это особенно важно в средах, где критична максимальная доступность: системы управления инфраструктурой, реального времени и другие сценарии, где даже минимальный простой недопустим.
Выбирайте РЕД Базу Данных, если для вашего проекта важна гарантированная целостность данных и отсутствие задержек при восстановлении.
Представлен открытый редактор таблиц NanoCell, который обрабатывает большие объёмы данных. При этом не нужно знать формулы и макросы. Проект помогает править документы от объёмных датасетов и финансовых данных до небольших формул для построения графиков и поиска одного значения в таблице. Решение разработал аналитик и датасайентист с многолетним стажем. Интерфейс у сервиса максимально простой и понятный. Данные сохраняется, включая все сведения и значения датасета на статическом сервере.