Базы данных *

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

В современном поиске всё чаще используется поиск «по смыслу» с помощью векторных эмбеддингов. Вместо привычного анализа текста по словам мы представляем документы и запросы в виде многомерных векторов и ищем ближайших соседей по евклидовому или косинусному расстоянию. Это позволяет, например, находить документы, схожие по смыслу, а не только по точному совпадению слов. В Elasticsearch поддержка такого поиска реализована через поле dense_vector и алгоритм HNSW (Hierarchical Navigable Small World) для быстрого приближённого поиска ближайших соседей.

В этой статье разберём, как настроить индекс с векторным полем, добавить документы с векторами и выполнять запросы kNN с возможностью фильтрации по дополнительным атрибутам.

В статье рассматривается логирование соединений с базами данных кластера PostgreSQL. Системы мониторинга создают сессии для сбора метрик и проверки доступности экземпляра. Это создаёт большое число записей в диагностическом журнале кластера, затрудняя его анализ. Администраторы ищут возможность отключения логирования для сессий мониторинга. Такая возможность есть только у параметра log_disconnections. Приводится пример, как с его помощью отключить логирование при создании сессии. Также рассматриваются особенности использования расширений pgaudit и pgaudittofile, которые позволяют выводить логирование соединений в отдельный файл аудита.

Герой обзора - утилита espanso, позволяющая на лету заменять текстовые фрагменты.
Опять прога на Rust. И опять впечатление "ух ты!", как от ruff и uv.

На imcdb.org энтузиасты уже два десятка лет отмечают автомобили в фильмах: кадры, марки, модели. Верифицируют находки на форуме, спорят о деталях. В итоге появилась крупнейшая база «машин‑актёров» в кино: 1,75 млн страниц с кадрами и описаниями транспорта из фильмов разных стран. Я собрал всё это в один датасет.

Привет, Хабр! Я Илья Назаров, старший инженер в разработке сервисов направления эксплуатации инфраструктуры данных DataPlatform Т-Банка. В работе я часто соприкасаюсь с движками баз данных. Первым и основным движком волею судеб стал Greenplum. Расскажу о своем длинном пути взаимодействия с «Зеленой сливой», как из хаоса и невежества я дошел до истины и гармонии.

В начале карьеры меня много чего удивляло. Тогда я еще не знал, что такое Greenplum,и плохо понимал, что такое MPP. Позднее коллеги на пальцах объяснили мне, что это «постгрес курильщика» и «постгрес поверх кучи постгресов». 

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

В целом ситуация выглядела страшно интересно: скрипты, процессы деплоя и работы над задачами — все было в новинку. С одной стороны, большой багаж исторически сформированных до меня решений, с другой — большой уровень свободы и минимум ограничений, что как раз и способствовало постоянному росту энтропии и хаоса. Практически сразу я ощутил желание навести во всем порядок. А что из этого получилось — читайте в статье 😉

Привет! С вами Кабанов Олег — ведущий ML-инженер Flocktory.

В этой статье расскажу об опыте внедрения YandexDB в качестве хранилища для ML Online Feature Store. А также о том, как нам удалось ускорить загрузку данных в 40 раз и убрать влияние на скорость чтения данных при обновлении.

Регулярные выражения (или regex) — это особые текстовые строки, используемые для описания поискового шаблона. В PostgreSQL regex становится незаменимым инструментом, особенно при работе с большими объёмами неструктурированных строковых данных.

Возможно, у кого‑то есть вопрос: «А для чего нам регулярные выражения в БД?» И мы вам ответим:

Регулярные выражения (regex) позволяют описать сложные текстовые шаблоны компактно и гибко.

Привет, Habr! На связи эксперты команды сервиса WatchDog — Дмитрий Коновалов и Геннадий Переломов.

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

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

Всем привет! Меня зовут Андрей, я бэкенд‑разработчик ядра Яндекс Диска. В индустрии я уже около 15 лет и повидал некоторое ПО. Последние три года занимаюсь ядром файловой системы — всем, что связано с метаданными о файлах.

Однажды мы в Диске переносили общие данные из шардированного MongoDB в шардированный же PostgreSQL. После переноса пользовательских данных у нас осталась часть данных про общие папки.Их было сложно изолировать внутри шарда пользователя, и они остались в общей БД на MongoDB, которую мы так и назвали — CommonDB. Спустя время мы заметили, что общая БД не справляется с нагрузкой: все запросы перед выполнением должны были сначала получить информацию об общих папках, и только после этого они начинали работать. Поэтому надо было дублировать информацию ближе к другим данным пользователей — на их шарды.

Однако при дублировании важно было избежать распределённых транзакций, так как они снижают общую производительность. Также проблемой был сам процесс перехода: у нас сотни миллионов пользователей, которые не должны были ощущать процесс перехода и потерять доступ к своим данным. При этом надо было выкатывать изменения не сразу на 100%, а частично, с возможностью в любой момент отключить функциональность. При выкатке также нельзя было допустить даунтайм.

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

Добрый день, коллеги!

Недавно мы столкнулись со следующей проблемой при тестировании СУБД PostgresPro под высокой нагрузкой: процесс представлял собой массированную многопоточную заливку данных на протяжении многих часов,а данных было около 20 ТБ, потоков — 75.

В процессе загрузки наблюдалось следующее явление: через некоторое время процесс checkpointer переставал делать контрольные точки в зависимости от других параметров БД либо сразу, либо через 2-3 часа.

Привет! Это Илья, руководитель проектов в Webest. Расскажу о том, как мы построили обмен между интернет-магазином и 1С. Реализовали двусторонний обмен через очереди, ввели приоритеты для разных типов данных и сделали прозрачный мониторинг в админке Orchid.

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

Что известно про Greenplum?
Это MPP система на базе PostgreSQL, которая нужна, чтобы работать с большими объемами данных и делать OLAP. Отлично, но лично меня не устраивает это поверхностное знание, хочется узнать, что внутри. Какие алгоритмы использует Greenplum в своих процессах. Я хочу начать с дистрибуции, и приглашаю вас с собой в это путешествие.

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

Самое интересное из предыдущих коммитфестов версии можно прочитать здесь: 2024-07, 2024-09, 2024-11, 2025-01.

Клиентские и серверные приложения

pg_dump[all]/pg_restore: выгрузка и восстановление статистики
Сбор статистики после обновления сервера
pg_upgrade --swap: перемещение каталогов из старого кластера в новый
pg_combinebackup --link или жесткие ссылки вместо копирования файлов
pg_dump[all], pg_restore: --no-policies
pg_createsubscriber: включение параметра two_phase для всех подписок
pg_createsubscriber: удаление публикаций на подписчике
pg_createsubscriber: создание подписок для всех баз данных сервера публикации
psql: конвейерный режим работы
psql: информация о текущем подключении
psql: настройка умолчания для интервала времени в команде \watch
psql: \dx показывает версию расширения по умолчанию

Мониторинг

NUMA: инструменты мониторинга систем с архитектурой неоднородного доступа к памяти
pg_stat_get_backend_wal: статистика WAL для отдельного процесса
EXPLAIN: фактическое число строк с точностью до двух знаков после запятой
EXPLAIN: интерфейс для добавления команде новых параметров
Журналирование неудачных попыток захватить блокировку
Журналирование времени на подключение нового сеанса
log_line_prefix: IP-адрес локального сервера
pg_stat_statements: нормализация команд со списками констант в IN
Дополнительные инструменты мониторинга переполнения буфера WAL
Отслеживание времени простоя при выполнении очистки и анализа

[Авто]очистка и анализ

vacuum_truncate: управление обрезанием пустых страниц в конце таблицы
Более частая автоочистка «мертвых» строк в больших таблицах
Более частая автоочистка после вставки новых строк
Нетерпеливая заморозка в помощь агрессивной очистке

Производительность

Асинхронный ввод/вывод
io_combine_limit: максимальный размер увеличен до 1МБ
[Применение интер

Когда я работал Reddit и отвечал там за инфраструктуру, самой важной поддерживаемой системой для меня была Postgres, а на втором месте стоял брокер сообщений RabbitMQ. Он был необходим для работы Reddit — перед сохранением в базу данных все данные поступали в распределённую очередь. Например, если пользователь лайкал пост, то это записывалось в очередь и кэш, а затем пользователю передавалось сообщение об успешном выполнении. Затем программа обработки очереди брала этот элемент и пыталась записать его в базу данных, а также создать новую рабочую операцию для пересчёта всех списков, на которые влияет этот лайк.

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

Привет, Хабр! Писать статьи — дело приятное, но только если нет на плечах релиза. Релиз оказался марафоном на месяцы, где каждый день мы жили задачами и доработками. Мы делились на три фронта: кто-то закрывал критические баги («баг-фиксеры»), кто-то добивал бизнес-логику («бизнес-логеры»), а кто-то всерьез отрабатывал план «Б» — ставил свечи за успешный релиз («молитвенники за прод»). Играли мы на разных уровнях, но финальный босс у всех был один: система, которую мы героически толкали в ПРОД, как кота в переноску: и он не хочет, и нам страшно.

Но как бы там ни было, сегодня на ПРОДе живет большая система. Прям такая, что, если бы она была организмом, у нее были бы печень, почки и амбулаторная карта в Сфере Знания. 

Пользователи — сотни сотрудников. Система — новая, кнопки — непонятные, интерфейс — как квартира после переезда: ты вроде дома, но даже чайник включить страшно.

И вот представьте: в этой «квартире» все двери распахнуты настежь. Любой может зайти куда угодно, нажать любую кнопку, открыть любой экран. Кнопки, которые лучше не трогать, экраны, куда и разработчик-то без инструктажа не сунется… Получился цифровой «чулан Моники» — хаос, который мы срочно должны были привести в порядок. 

Решение было очевидным: нужна ролевая модель.

По плану ролевую модель — разграничение видимости интерфейсов и данных на стороне БД — мы должны были выкатить через пару недель после запуска. Но в мире, где перечень техдолгов меняется быстрее, чем погода в Калининграде, пришлось действовать иначе. В итоге, бочком-бочком, мы затолкали ее в боевой релиз буквально на финишной прямой.

HistoryHelper - плагин для DBeaver

Зачем и почему?

Работая с БД часто приходится вручную писать SQL для создания history-таблиц, которые хранят "историю" о каждой записи из таблицы. То есть, если запись создана/изменена/удалена, для неё создается новая запись в таблице с окончанием "_hist" или "_history".

Задача знакомая, но крайне рутинная: для каждой таблицы нужно вручную писать SQL, проверять, чтобы все колонки были учтены, тип колонок был корректным, и не было опечаток.

Поэтому, я решил сделать небольшой плагин для DBeaver, который предоставляет удобное меню выбора колонок и событий.

После нескольких выходных дней получилась минимальная реализация, которой хочу с вами поделиться.

В данный момент реализован самый простой функционал.

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

Собственники и топ‑менеджеры МСБ часто сталкиваются с парадоксом: обороты растут, а прибыль тает. Причина не в рынке и не в ценах, а в хаосе внутри компании.

Отчёты собираются вручную, ключевые показатели никто не считает, решения принимаются на интуиции, без опоры на цифры.

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

Рассказываем, какие задачи решают оркестраторы в проектах внедрения корпоративных хранилищ данных. Выясняем, в чем разница между инструментами, и почему Dagster становится все популярнее в DWH-проектах, чем Airflow.