Базы данных *

С 2017 года я слежу за экосистемой вокруг PostgreSQL для выполнения аналитических запросов и использования ее в качестве хранилища данных. И раньше в своей работе использовал AWS Redshift со всем его недостатками и неудобствами для разработчика как форка старой версии PostgreSQL. По моему мнению идеальное решение на основе PostgreSQL должно быть на последней доступной версии СУБД, реализовано в виде расширения, с возможностью запускать для тестов локально в контейнере и позволять использовать существующие расширения последних версий PostGIS / pgvector итп.

Citus казался ближе всех к тому что нужно, но его нельзя считать полноценным Massively Parallel Processing решением, скорее это шардирование данных для OLTP нагрузки.

Greenplum как MPP форк всем хорош и много кто его эксплуатирует в реальных задачах, но версия PostgreSQL, на основе которой он создан, отстает от текущей. Я решил сделать Apache Cloudberry, как самую свежую open source версию Greenplum, в виде расширения для PostgreSQL 19. Пока что это личный эксперимент, а не апстрим релиз Apache Cloudberry. Более 90% кода проекта удалось портировать с помощью LLM и 59% его тестов исходного проекта стало выполняться на его новой версии. У меня на это ушло 12 дней…

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

В статье разбираем, какие метрики помогают оценивать качество данных и как построить такие проверки с помощью Apache Airflow.

Привет, Хабр! Меня зовут Даниил Пасечник, в RWB я отвечаю за архитектуру управления пользовательского доступа в базы данных. В этой статье расскажу, как мы прошли путь от разрозненной, неконтролируемой выдачи доступов к БД до единого корпоративного процесса на базе Trino и Open Policy Agent — и почему это получилось не просто техническим решением, а полноценной кросс-департаментной архитектурой.

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

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

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

На wine.co.za данные хранятся в MariaDB, раз в день копируются в Manticore, а сайт обращается к поиску через библиотеку для .NET. Разбираем, как устроен поиск по архиву из примерно 145 тысяч записей и что изменилось для посетителей и небольшой ИТ-команды.

TL;DR: Мы портировали игровую логику и рендерер первого Doom на SQL и запустили его внутри базы данных. На моём ноутбуке игровой цикл исполняется на исходных 35 FPS, а рендерер генерирует полный буфер кадров 320x200 с частотой от 60 Гц и выше. Python только обрабатывает тайминги, считывает клавиатуру и отображает получаемую им битовую карту. Многопользовательский режим тоже работает.

Можете сыграть прямо сейчас: Deathmatch, четыре слота, обслуживание в порядке очереди.

SQLDoom на EU-серверах

SQLDoom на US-серверах

Это shareware-версия первого эпизода. Если все места заняты, вы попадаете в очередь. Если очередь заполнена, то в процессе ожидания вы всё равно можете запрашивать состояние игры через SQL.

С 1 сентября 2026 года офисное ПО не попадает в реестр без совместимости с двумя доверенными ОС. Срок полного перехода КИИ, который наступал в январе 2025-го, в мае разложили на три: 2028, 2031 и 2036. А реестр доверенного ПО снова перенесли, теперь на конец года.

За этими новостями стоит реальная карта замещения, и она не похожа на отчёты. Windows уходит не один, а вместе с Active Directory, SQL Server и Exchange: 33 кейса замены Windows это 33 замены стека. На каждом закрытом слое один победитель с долей от 57 до 74 процентов, и одна и та же лицензия покупается с разбросом цен до 44 раз. А нижние слои пусты: средства разработки замещены на четверть.

Внутри: что на что меняют по 139 кейсам, пять гипотез с фактурой 2026 года и где пройдёт фронт 2027-2028.

Каждый день в 18:00 клиентам становится доступна отчётность по продажам, и многие одновременно нажимают кнопку «Загрузить отчёт». Это может быть детализированный отчёт по списаниям, юридическая отчётность, аналитическая выгрузка или API, используя который клиент получает данные для дальнейшей обработки. В этот момент даже хорошо подобранное хранилище может стать узким местом.

В моей практике разработки часто встречаются сценарии, когда необходимо предоставить доступ к большому количеству данных по HTTP. На первый взгляд задача выглядит простой: берём подходящее хранилище, пишем endpoint, выполняем запрос и отдаём результат пользователю. Но на практике такая схема быстро упирается в ограничения.

24 сентября вышла PostgreSQL 19 Beta 4. До release candidate осталось совсем немного, и на этом этапе уже интереснее смотреть не на длинный список новых возможностей, а на те изменения, которые реально способны поменять повседневную работу backend-команды.

В релизе есть заметные вещи вроде REPACK, нового WAIT FOR LSN, параллельного autovacuum, репликации sequence и pg_plan_advice. Но почти у каждой из них есть важное «да, но». REPACK (CONCURRENTLY) не означает «VACUUM FULL без блокировок». WAIT FOR LSN не превращает асинхронную реплику в синхронную. Планировщик теперь можно подталкивать, но это не делает hint-ы хорошей идеей по умолчанию.

Именно поэтому вместо обзора «50 новых фич PostgreSQL 19» я выбрал пять изменений, которые стоит прогнать на собственном staging до GA. Не чтобы немедленно включить их в production, а чтобы заранее понять, какие старые костыли после обновления можно будет убрать, а где появятся новые точки контроля.

DISCLAIMER: Это неофициальный форк. Но, по моим сведениям, и в официальный pony эти фичи скоро подъедут в каком‑то виде.

Некоторое время назад, я решил испробовать программирование с помощью ИИ‑агентов и решил выбрать pony в качестве пет‑проекта. О pony я уже писал в предыдущей статье. Теперь хочу поделиться результатами своего недельного спринта.

В pony добавилось:
— поддержка асинхронности
— поддержка миграций
— разные улучшения из серии quality‑of‑life

Так что, фреймворк pony теперь чрезвычайно важен и сердит — что можно понять по этой картинке. Всё — благодаря DeepSeek 4.1 Flash и Kimi K3 (последняя — умная, но дорогая — она делала ревью).

Привет, Хабр! Это четвёртая статья цикла про R&D‑исследование для небольшой команды DBA.

Мы начали с того, что решили упростить мониторинг парка из более чем 800 экземпляров нашей СУБД Platform V Pangolin DB (реляционная СУБД на базе PostgreSQL) с помощью доработки postgres_exporter. А потом и вовсе собрали автономный агент, который сам обрабатывает тикеты: очищает дисковое пространство, выполняет VACUUM/ANALYZE и планирует остановки БД.

В этой статье расскажу, как мы продолжили тестировать гипотезу с агентом: перевели его в режим второй линии поддержки и замеряли реальные результаты. Будут числа, примеры, использование LLM для анализа паттернов, миграция задач из Pipeliner и планы по дальнейшему R&D и превращению агента в полноценную вторую линию поддержки.

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

На демо все выглядит безобидно: загружаем документы, строим эмбеддинги, подключаем векторный поиск — и RAG уже отвечает на вопросы. А потом поиск тормозит, после фильтрации пропадают результаты, а команда внезапно тратит все силы на систему, которая слишком велика для проекта.

Разберу, когда для векторного поиска достаточно PostgreSQL с pgvector, зачем выносить его в Qdrant и в каких случаях сложная архитектура Milvus действительно оправдана.

Обычно задача «создать базу знаний из сайта» звучит просто: взять HTML, извлечь текст, разбить его на фрагменты, построить embeddings и отправить всё в RAG.

На современных сайтах этот подход всё чаще перестаёт работать.

Главная причина — сайт может практически не содержать данных в исходном HTML. Пользователь открывает страницу, браузер загружает JavaScript, JavaScript обращается к API, а уже API возвращает услуги, товары, объекты, статьи, цены и другие данные.

Именно с такой проблемой мы столкнулись при разработке новой возможности в LLMCOD.

Теперь система умеет работать не только с обычными страницами, но и с SPA-сайтами и доступными открытыми API.

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

Отечественный рынок решений Data Lakehouse активно развивается: после периода пилотных проектов наблюдается массовый переход к промышленным внедрениям. Растущий спрос на такие платформы обусловлен необходимостью обрабатывать разнородные данные в условиях строгих требований к информационной безопасности.

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

В статье расскажем, как именно реализована наша Data Lakehouse платформа для аналитики и ML — VK Data Platform от VK Tech. 

Привет, Хабр! На связи Саша Михеев, ML-инженер Центра гибридного интеллекта в Рунити. В прошлой статье мы рассказывали, как строим корпоративного RAG-ассистента. На небольшой выгрузке Confluence поиск выглядел вполне прилично. Но когда корпус вырос почти до 35 тысяч страниц и 80 тысяч чанков, наверх всё чаще стали попадать документы, похожие по теме, но не отвечающие на конкретный вопрос.

Мы пошли проверять привычные гипотезы: поменяли способ выгрузки Confluence, усложнили чанкирование, вынесли код в отдельные вектора, попробовали более крупную embedding-модель и добавили структурный граф. Почти ничего из этого не решило проблему. Главная подсказка пришла из метрик: нужный материал в большинстве случаев уже находился, но стоял слишком низко. В итоге лучший прирост дал не еще один retrieval-канал, а reranker.

У меня было объяснение, почему ora2pg теряет внешние ключи при переносе схемы в PostgreSQL. Я его опроверг, придумал новое и опроверг ещё раз. Настоящая причина оказалась в одной проверке exists() в Perl-коде, а чинится всё одной строкой в конфиге.

Чем сложнее бизнес-процессы, тем сильнее размывается логика связей: она оседает в каскадах SQL-джойнов, коде микросервисов и витринах, а LLM поверх плоских таблиц начинают галлюцинировать. Альтернатива — перенести доменные правила, сущности и роли на уровень схемы с помощью семантического слоя. Команда Neoflex протестировала этот подход на TypeDB — СУБД с нативными n-арными отношениями и встроенным логическим выводом. На сквозном датасете из 65 752 заказов и 470 000 веб-событий мы на практике сопоставили классический SQL и TypeQL: сравнили декларативные ролевые паттерны с каскадами JOIN и декартовым раздуванием строк, замерили реальную скорость выполнения и упаковали структурированный контекст для ИИ-агента без мусорных дубликатов. В статье на Хабре — методология декомпозиции схемы, замеры производительности и честный разбор того, в каких сценариях гиперграфы дают преимущество, а где привычные реляционные и графовые базы остаются незаменимыми.

Если вы используете n8n на своем сервере для обработки заявок клиентов, отправлять их персональные данные напрямую в OpenAI или Claude нельзя из‑за 152-ФЗ. Логичнее всего использовать в качестве санитайзера отечественный GigaChat, но в Docker n8n сразу падает с ошибкой проверки SSL‑сертификатов. Показываю, как за 5 минут пробросить корневые сертификаты Минцифры в контейнер и настроить безопасную связку.

Бонусом будет история про галлюцинацию, из‑за которой GigaChat начал называть всех клиентов «Иваном».

Привет, Хаброжители! Познакомьтесь с полным практическим руководством по подготовке к собеседованиям на одну из самых востребованных и высокооплачиваемых позиций в ИТ.

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