История о том, как превратить ИИ-агентаиз «золотой рыбки» с памятью в пределах одной сессии в полноценного цифрового сотрудника с графовым хранилищем знаний.
Здравствуйте, уважаемые читатели Хабра!
Это вторая часть (первая здесь) о создании основного функционала MVP (Minimum Value Product) системы по управлению цифровыми активами для базы данных PostGIS.
В этой публикации рассмотрим применение классического, полнотекстового и семантического поиска текста в PostgreSQL.
Разбираем на практике, как гарантировать доставку сообщений в Kafka/RabbitMQ без распределенных транзакций, используя паттерн Transactional Outbox.
В этой статье рассмотрим наиболее полную реализацию паттерна Transactional Outbox, которую можно будет легко расширять и применять в продакшне. Данная статья будет полезна как для разработчиков, которые еще не встречались с данным паттерном, так и тем, кто уже применял его в своей работе.
Эта история началась с исследования проблем производительности на высоконагруженной базе данных Postgres. Табличка, которая была предметом исследования, довольно небольшая (~100,000 записей), но очень активно используемая.
В процессе исследования я увидел, что Postgres использует индексный доступ по абсолютно неселективному критерию, фактически это был "INDEX FULL SCAN" в терминологии Oracle. Интуиция, наработанная на другой промышленной базе, вопила: "что-то здесь не так!"
Но что?
Предположим, вы построили RAG-сервис на SQL, и он отлично работает. Довольно быстро, очень точно, и очень дорого, ведь каждый запрос к сервису требует обращения к LLM для генерации ответа по чанкам, извлеченным из базы знаний. И чем больше мы извлекли таких фрагментов, тем больше входных токенов тратится на составной промпт, даже если ответ будет состоять из одного предложения.
Можно, конечно, заранее срезать количество извлекаемых чанков, но это отразится на качестве ответов.
Можно настроить кэш, который экономит на обращениях к сервису, когда приходят одинаковые вопросы. Но когда пользователь спрашивает "How to get developer support?”, и тут же другой пользователь спрашивает "How to ask development-related questions?", ваш сервис каждый раз будет генерировать ответ заново, сжигая ваши токены и заставляя пользователя ждать. Обычный кэш тут бессилен: для него эти две фразы — абсолютно разные ключи.
В этой статье я расскажу, как развернуть мощный семантический кэш на базе AlloyDB Omni (PostgreSQL от Google), используя векторный поиск ScaNN, автоматическое партиционирование и планировщик задач. Мы пройдём путь от настройки Docker-контейнера до продакшн-архитектуры.
Не так давно на моей текущей работе впервые за весь мой немногочисленный 4-летний опыт бэкендера понадобилось для нового микросервиса рассчитывать ресурсы под PostgreSQL для данного сервиса. Раньше для меня данная тема было чем-то, чем занимаются DevOps/DBA и никогда прежде не задумывался и не исследовал информацию о том, как качественно рассчитать необходимые ресурсы, чтобы бизнесу не пришлось переплачивать за очень дорогие железки лишние деньги, чтобы потом оказалось, что от купленных мощностей в реальности используется 20-40% (опыт на нескольких работах показывает, что такое случается ну очень часто).
Q: Для кого эта статья?
A: Да в целом для любых технических специалистов, которые так или иначе взаимодействуют с технической поддержкой PostgreSQL и которым впервые нужно для новой БД (например, под микросервис) и сформулировать задачу для DevOps команды на поднятие СУБД для вашего сервиса.
Q: «Зачем мне это? Ну прикину я на глаз, что здесь нужно 50ГБ диска, 64ГБ RAM и нормально поедет»
A: Очень часто в условиях микросервисной архитектуры используется парадигма database per service и в таком случае нельзя просто запросить максимально мощную виртуальную машину. Ресурсы стоят много денег, инфраструктура должна масштабироваться, а значит необходимо уметь определять, какой именно мощности ВМ требуется и какие параметры PostgreSQL следует задать на старте.
В статье вы получите пошаговый расчёт диска, RAM, CPU и базовые рекомендации по конфигу PostgreSQL, а также в подарок готовый промпт для ИИ, если захотите делегировать все расчёты нейромозгу.
tl;dr:
Каждая операция INSERT несет фиксированный overhead (в наших тестах 64–99 ms), независимо от количества строк.
Формула: Total_time = N_statements * fixed_overhead + actual_write_time — подтверждена тестами.
1000 single-row INSERT = 64 секунды (Shared-data) или 100 секунд (Shared-Nothing).
Разница не в диске и не в Docker, а в протоколе commit: TxnLog + publish через BRPC против 2PC + publish_version.
В ANALYZE PROFILE commit overhead прячется в разнице TotalTime - ExecutionTime — это FE overhead.
Батчинг нивелирует разницу: при INSERT SELECT оба режима дают ~0.25 с на 1000 строк.
Работая с MS SQL, я привык воспринимать название Ring Buffer как небольшую структура в памяти, организованную по принципу FIFO overwrite. И чаще всего в контексте Extended Events. Но как-то я встретил упоминание того же Ring Buffer в заголовке статьи про секционирование таблиц! Купился на название, прочёл статью и сохранил себе идею.
В статье описывалось, как Ring Buffer решает задачу ротации данных во времени, которую принято решать с помощью Sliding Window. И я постараюсь передать эту идею так, чтобы после прочтения у вас появился еще один способ решить обычную задачу необычным способом. Не для галочки в резюме, а для рассказов на встречах с коллегами. В моей работе этот подход позволил сделать интересной скучную задачу организации хранения статистики производительности сервера, но может быть использован и для других данных с ограниченным сроком хранения или иначе фиксированным количеством секций. Например, данных аудита.
Здравствуйте, уважаемые читателя Хабра!
В серии статей хочу рассказать о создании основного функционала MVP (Minimum Value Product) системы по управлению цифровыми активами для базы данных PostGIS. В этой публикации рассмотрим как быстро находить одинаковые и похожие по геометрии объекты среди тысячи таблиц и 300 млн записей.
В предыдущей статье рассказал, где и для чего мне понадобился биллинг.
Речь идёт о списаниях с баланса пользователей оплаты за мониторинг сайтов в моём Tg-боте. Тариф простой: 1 сайт бесплатно, каждый дополнительный — 2 рубля в сутки.
Пользователь может в любой момент включать/выключать сайты.
Задача в том, чтобы честно считать, сколько сайто-дней набежало за предыдущие сутки, и фиксировать в базе соответствующее списание.
Я сам для себя сформулировал ряд дополнительных требований, которые сильно усложнили код. А уже этот сложный код в комбинации с некоторым дальнейшими обстоятельствами привёл к сумятице в списаниях. Ниже поделюсь своим опытом и выводами.
Партиционирование (или секционирование) — это метод разделения одной большой таблицы базы данных на более мелкие, управляемые логические части (партиции) для повышения производительности запросов, упрощения администрирования и управления большими объемами данных, например, по диапазонам дат, списков или хэшам. Это позволяет системе обращаться только к нужным разделам, а не ко всей таблице, ускоряет отчеты, архивацию и другие операции, а также можно перемещать неактивные данные на медленные носители.
Привет, Хабр! 👋
В современной разработке мы привыкли решать проблемы производительности стандартным набором инструментов. "База не тянет? Поставь Redis!" — это стало почти рефлексом. Но всегда ли оправдано тащить в инфраструктуру лишний сервис, настраивать сетевые хопы и следить за инвалидацией, если ваша задача — это всего лишь быстрый доступ к небольшому справочнику?
В нашем Open Source проекте BMSTU-ITSTECH/SSO мы столкнулись именно с таким кейсом. И решение оказалось элегантнее, чем просто "поднять Redis". Рассказываю, как мы сэкономили на инфраструктуре и получили мгновенный отклик, используя скрытую мощь PostgreSQL LISTEN/NOTIFY.
Как не потеряться в сотнях графиков и найти реальные рычаги влияния на бизнес? В статье представлен подробный разбор Дерева метрик на примере FoodTech-сервиса (доставки еды). Мы уходим от простого мониторинга цифр к системной декомпозиции North Star Metric.
Как часто бизнес задает вопрос о результатах A/B-теста уже на второй день после запуска? В классической статистике основной ответ: необходимо ждать набора фиксированной выборки, иначе риск ложноположительного результата становится неконтролируемым. Однако современные подходы позволяют не только проводить мониторинг данных без риска математической ошибки, но и останавливать эксперименты значительно раньше срока. В основе такой гибкости лежит методология mSPRT, которая превращает эксперимент из закрытого процесса в прозрачный поток данных.
Вместо пассивного ожидания можно использовать концепцию доверительных последовательностей и всегда валидных p-значений. Эти инструменты сохраняют свою математическую силу независимо от того, как часто проверяются промежуточные итоги. Ключевую роль в настройке системы играет параметр смешивания тау, который помогает найти тонкий баланс между чувствительностью к минимальным изменениям и скоростью получения итогового результата.
Работа с реальным трафиком требует адаптации теории к специфике бизнеса. В статье разбирается, как метод линеаризации помогает применять последовательный анализ к сложным показателям вроде конверсии или среднего дохода на пользователя. Также рассматриваются ситуации, когда стандартная математика может давать сбои из-за экстремальных выбросов с тяжелыми хвостами распределения или изменения характеристик трафика во времени. Чтобы исключить ложные срабатывания, вводится система защитных механизмов, которая делает выводы устойчивыми к случайному шуму.
Такой метод позволяет сократить время проведения тестов на 30-50%, не жертвуя при этом достоверностью. Это способ сделать процесс проверки гипотез более гибким и быстрым, сохраняя безупречную математическую строгость в каждой точке принятия решения.
Третья статья цикла о построении CDC-пайплайна с нуля. Сегодня — самое интересное: захватываем изменения из PostgreSQL и отправляем в Kafka. И разбираемся, почему WAL может съесть весь диск, даже если данные не меняются.
Выделили из production-проекта и открыли в open-source PWA-приложение для персонального фитнес-тренера с AI.
Дисклеймер: это open source, в нем могут быть недостатки, заходите, предлагайте идеи, исправления. Публикую тут в ознакомительных и образовательных целях. Выпилил этот кусок в open source из части личного проекта, о котором писал тут. Весь код писал полностью Claude Code на Opus 4.5 с thinking режимом.
Привет Хабр! Возможно вас, как и меня, первое знакомство с функциональными зависимостями в базах данных повергло в легкий ступор. Длинные определения, которые не давались даже после третьего прочтения, излишняя абстрактность, когда на простые и понятные примеры поскупились, и прочее прелести «научного» подхода к объяснению сложных тем.
Пора раз и навсегда разобраться во всем этом. Тем не менее, я постараюсь не упускать детали и, где это уместно, углубиться в тему с головой. Без претензии на академичность, но с претензией на ясность. Начнем.
Ты изучал SQL в университете, получал пятёрки на экзаменах… а на собеседовании по Data Science сталкиваешься с вопросом про OVER() и думаешь: "Что?! Впервые такое слышу..."
В этой статье я рассказываю, как превратить университетский SQL в инструмент, который реально помогает на собеседованиях.
