Базы данных *

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

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

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

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

Сегодня рассмотрим open-source RAG-фреймворк HippoRAG 2. В сфере RAG главным преимуществом данного фреймворка является качество ответов, потому что принципы его работы основаны на реальном человеческом мозге. Давайте разберёмся, откуда он взялся, как устроен изнутри и как его запустить.

Меня зовут Дмитрий Кудряшов. За моими плечами 12 лет службы в структуре ФНС, из которых последние годы я занимал должность заместителя начальника отдела анализа и планирования налоговых проверок в региональном Управлении ФНС.

С недавнего времени я веду свой Telegram-канал «Налоговый инсайдер», где показываю как в действительности осуществляется налоговый контроль, отвечаю на вопросы и разбираю ситуации из комментариев. Сегодня на площадке Хабра я хочу поделиться ответом на комментарий, в котором читатель искренне усомнился в реальных возможностях баз данных ФНС и написал следующее:

Работать с Kafka в DBaaS — удобно: инфраструктура поддерживается сильно проще, пока вы фокусируетесь на логике приложения. Но есть нюанс: прямой доступ к брокерам и CLI ограничен. Это усложняет отладку, анализ данных и диагностику consumer — особенно если у вас десятки топиков и групп.

Kafka UI — это Open Source-инструмент, который решает описанную проблему: он предоставляет веб-интерфейс для просмотра топиков, сообщений и состояния consumer groups без прямого доступа к брокерам.

На связи Ксения Ершова, проектировщик интерфейсов в Selectel. В статье расскажу, как развернуть на облачном сервере Kafka UI в публичном доступе, подключить его к Kafka-кластеру в DBaaS Selectel и проверить, что все работает.

Всем привет!

На одном из проектов я настраивал дашборд в Yandex DataLens, который объединяет данные о трафике из Яндекс Метрики с данными о заказах из CRM и позволяет анализировать доход в разрезе источников трафика.

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

Привет, Хабр! Меня зовут Ян Пиле, руковожу в MAGNIT TECH направлением развития алгоритмов доступности товаров. Задача моей команды: сделать так, чтобы в магазине, куда вы зашли за своим любимым майонезом, он с большей вероятностью оказался на полке. А если не оказался — чтобы сотруднику магазина как можно быстрее прилетело задание: «проверь, почему именно этой позиции сейчас нет, и, если возможно, верни её обратно».

Мы уже дважды писали про OSA (On-Shelf Availability — уровень доступности товара на полке). В статье «Как OSA превращает пустые полки в полные корзины?» рассказывали про продуктовый контекст: зачем эта история нужна бизнесу и почему «товар числится в системе» и «товар реально лежит на полке» — это два совершенно разных утверждения. А в статье «Когда 0 в продажах — аномалия? CUSUM для поиска проблем в ритейле» мы подробно разбирали один из рабочих алгоритмов команды. В этот раз я хочу пройтись по всему стеку детекции целиком — от самых простых правил до А/Б-тестов, в которых приходится бороться с зависимыми наблюдениями.

Привет, меня зовут Юля, я дата-инженер в департаменте аналитических решений ЮMoney. Мы разрабатываем и поддерживаем ETL(ELT)-процессы загрузки данных для BI-продуктов компании: отчётов, дашбордов, витрин, API и других.

В этой статье поделюсь, как мы разрабатывали MVP для построения data lineage системы и к каким выводам пришли, — так вы сможете адаптировать подход под свои процессы.

Проблема, которая привела нас к разработке MVP, заключается в том, что в начале работы над большинством задач требуется подготовительная аналитика: восстановить путь происхождения данных, чтобы понимать, какие ETL(ELT)-процессы будут затронуты и на что повлияют изменения. Это увеличивает время выполнения задачи. Но, что ещё существеннее, процесс достаточно рутинный: каждый раз необходимо проводить статический анализ кода и изучать документацию (при её наличии). Мы решили автоматизировать эту работу, чтобы иметь под рукой инструмент для построения пути данных по точкам их обработки и применения, — то есть создать data lineage систему.

Мы уже рассказывали, что такое OpenSearch как сервис в Selectel и как легко и быстро начать им пользоваться. Если коротко — это managed-решение, где кластер развертывается за несколько минут, а все заботы берет на себя провайдер: обслуживает кластеры, настраивает СУБД, обеспечивает отказоустойчивость, беспокоится о бэкапах и масштабировании, предоставляет  поддержку.

Но дальше возникает вопрос — как с этим кластером работать? Как настроить мониторинг, визуализировать данные и метрики, работать с бэкапами, управлять пользователями и доступами? Можно, конечно, отправлять curl-запросы к API. Можно подключать сторонние инструменты, вроде Grafana. Но есть способ проще и удобнее — OpenSearch Dashboards.

Привет, Хабр! Меня зовут Сергей Кардапольцев, я технический писатель в Selectel. В этой статье расскажу, как можно упростить работу с кластером OpenSearch с помощью OpenSearch Dashboards.

Разберем топ вопросов на знание SQL, которые чаще всего задают на собеседованиях. Я собрала в этот топ свой опыт и опыт коллег, которые недавно проходили собеседования.

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

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

А сегодня посмотрим, как с помощью Coolify создать базу данных на своем сервере и какие преимущества это даёт.

Greenplum много лет был в опенсорсе на GitHub под лицензией Apache 2.0. Казалось бы, лицензия Apache 2.0, что может пойти не так? Осенью 2023 года репозиторий неожиданно перестал принимать наши пул‑реквесты. Все наши CLA отозвали, а новые не подтвердили без каких‑либо пояснений.

А в мае 2024-го репозиторий был закрыт. Да, к опенсорс‑проекту могут потерять интерес — и он окажется заброшен. Но здесь, по сути, присвоили наши пул‑реквесты, изменив лицензию у кода, который мы написали, просто потому, что «ничего личного, это бизнес». Обстоятельства менялись, и вот — новые правила использования БД. Твои опыт и достижения либо присваиваются корпорацией, либо обнуляются.

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

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

Я постараюсь, не углубляясь в технические дебри, в научно-популярном ключе рассказать о распределенных KV-хранилищах: что это вообще такое, где применяется и почему мы выбрали именно etcd.

Если вы администрируете системы хранения данных, наверняка сталкивались с ситуациями, когда стандартных средств Device Manager оказывается недостаточно. Может потребоваться более глубокая диагностика, сбор расширенных логов или подготовка компонента к замене. Именно для таких случаев предусмотрен режим Minisystem — специальная сервисная среда с расширенным набором команд. В этой статье в блоге ЛАНИТ мы собрали наиболее полезные из них.

Вы пришли из мира PostgreSQL, Oracle или MSSQL. Вы знаете: материализованное представление — это «замороженный» результат запроса. Удобно. Предсказуемо.

Вы открываете документацию ClickHouse. Видите знакомые слова. Радуетесь. Пишете свой первый MATERIALIZED VIEW. Запускаете. И... получаете не то, что ожидали.

Потому что в ClickHouse материализованные представления работают СОВСЕМ не так, как везде.

Привет, Хабр! Меня зовут Даша Александрова, я Java‑разработчик. Хочу поделиться опытом миграции данных из Oracle в PostgreSQL без простоя сервисов.

Причина миграции — импортозамещение.

Теперь немного про сам проект. В его основе — микросервисная архитектура на Java 11/17 и Spring Boot 2/3. В качестве основной базы данных использовалась Oracle с несколькими схемами. В коде сочетаются нативные SQL‑запросы и Hibernate, вся бизнес‑логика живет на уровне приложения — без процедур, триггеров и другой логики в базе. Идентификаторы генерируются через sequence. Проект активно развивается, регулярно выпускаются релизы. Система ориентирована на клиентские приложения — мобильное и веб, при этом нагрузка остается умеренной и не относится к highload‑сценариям.

Ключевое нефункциональное требование — выполнить миграцию без простоя системы и без заметного влияния на пользователей.

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

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

Ожидания получения BufferPin включают в себя:

1) Конфликты BufferPin на репликах (recovery conflict). Процесс на реплике startup должен получить блокировку на буфер, чтобы проиграть (replay, apply, накатить журнальную запись) HOT cleanup блока, для этого startup должен дождаться pincount=0. Быстрая очистка (HOT cleanup) выполняется на мастере серверными процессами очень часто и процесс startup, если столкнется с блоком, закреплённым запросом на реплике, полностью приостановит накат и будет ждать снятия закреплений блока. Накатом занимается только один процесс startup и в один поток. Из-за частых ожиданий BufferPin отставание реплики растёт и кажется, что startup не справляется. Мониторинг таких ситуаций затруднён, так как в представлении pg_stat_database_conflicts отражаются только конфликты, которые привели к прерыванию запросов на реплике, то есть, когда startup приостанавливал работу более, чем на max_standby_streaming_delay (по умолчению, 30 секунд), а в pg_stat_activity поймать ожидание BufferPin, которое длится доли секунды, почти невозможно. Из-за таких конфликтов, компаниии выделяют одну реплику, которая не обслуживает запросы, чтобы она только синхронизировалась и не отставала от мастера. Например, OpenAI, помимо 50 реплик, обслуживающих запросы на чтение, использует реплику, не обслуживающую никакие запросы, чтобы можно было на неё быстро переключиться (упомянута в 6 пункте в статье)

2) конфликты с автовакуумом при заморозке страниц. Такие конфликты есть и на мастере и на реплике и начинаются через 100 миллионов транзакций (по умолчанию, до 18 версии PostgreSQL). При недолгих тестированиях приложений не отлавливаются, проблемы начинаются при эксплуатации. Это одна из причин, по которой нагрузочные тесты длятся долго. Зная, как работает PostgreSQL, можно использовать недолгие тесты и оптимизировать приложение и параметры экземпляра, используя результаты недолгих тестов для обратной связи при настройке.

Конференция прошла 23-24 марта в московском Центре Международной Торговли, а на днях для участников выложили видео, презентации и фото. В этом году конференцию посетило примерно 1300 очно и 800 заочно. По сравнению с прошлой конференцией она немного подросла: на PGConf.Russia 2025 было 1120 очных, в сумме около 2 тыс. человек. Конференция претерпела лёгкий ребрендинг: PGConf.Russia => PGConf.Россия (переход плавный: PGConf.СПб 2025, а не SPb). Доклады на этот раз проходили в 4 залах (на прошлой - в 3): главный - сдвоенный и 3 зала поменьше. Один из них был отдан целиком Postgres Pro. Ещё в 2 залах проходили мастер-классы.

EXPLAIN ANALYZE часто воспринимается как инструмент, который показывает план выполнения запроса. Но если посмотреть внимательнее на блок BUFFERS, он начинает отвечать на более прикладной вопрос — где именно запрос упёрся в I/O и почему это произошло. В этой статье разберём, как читать эту статистику на уровне отдельных узлов плана, как интерпретировать hit/read в контексте нагрузки и почему сами числа почти ничего не значат без сравнения во времени.

Архитектурный принцип Lakehouse предполагает, что вы оперируете всеми данными, загруженными в систему. Но иногда нужно выполнить ad hoc анализ за ее периметром, потому что необходимых данных по каким-либо причинам нет в Lakehouse-платформе. В этом случае на помощь приходит федеративный доступ. Стандартом для такой задачи является движок Trino. Он умеет извлекать данные из внешних СУБД и даже в некоторых случаях может делать push-down определенных вычислений на сторону системы-источника. Главное, чтобы под рукой был подходящий connector для нужной СУБД, который умеет эффективно с ней работать.

Недавно в состав Data Ocean Nova был добавлен новый Trino Teradata Connector. Он позволяет пользователям «подтягивать» необходимые срезы данных из Teradata в рамках ad hoc запросов и решает задачу эффективной передачи данных: можно передавать терабайты в несколько потоков без существенного увеличения нагрузки на источник.

В данной статье разберем:
• Как организовать эффективную многопоточную работу с Teradata: где часто допускают ошибки, как должно выглядеть правильное решение;
• Какие возможности дает Nova Trino Teradata Connector: многопоточная передача, push-down оптимизации.