Каждые 10 минут в русскоязычном эфире Twitch и VK Видео Live в среднем 7 200 каналов. Писать их как есть - больше миллиона строк в сутки. Я храню агрегаты, и за четыре недели вышло 2 млн строк. Расскажу, как это устроено и где я три недели искал проблему не там.

Я Максим, разработчик, вечерами пишу LanolStream - инструменты для стримеров, которые мы делаем вместе со стримершей lanolkid. Стримеры часто спрашивают «во сколько лучше стримить» и «много ли у меня зрителей для моей игры». Чтобы отвечать цифрами, а не ощущениями, нужен весь рынок, а не только наши каналы.

Один и тот же набор из десяти заказов, а p90 получается от 3900 до 12 500 рублей. В ноутбуке аналитика одна цифра, на дашборде другая, и даже повторный запуск запроса иногда меняет результат. Причина может скрываться в самой функции расчёта перцентиля — разберёмся, как разные инструменты выбирают значения и какой метод использовать, чтобы метрики можно было сравнивать.

Обычно стек для RAG‑систем и AI‑агентов строится вокруг облачных API (OpenAI, Anthropic) и управляемых векторных баз. Но для ряда задач критически важна полная автономность: устойчивость к санкциям и независимость от внешних провайдеров.

В этой статье я расскажу, как спроектировал и собрал аналитическую систему, которая за две недели работы агрегировала более 12 000 новостей: от сбора RSS‑лент до умного агента, который сам вызывает инструменты. Мы пройдем путь от архитектуры до граблей, на которые я наступил.

Стек: Python 3.12, FastAPI, PostgreSQL + pgvector, Celery, LangGraph, Ollama (Qwen 2.5 14B, BGE‑M3), Streamlit, Langfuse, Docker.

Привет, Хабр! На связи Михаил Витко, менеджер PaaS-продуктов Рег.облака. Представим ситуацию. После восстановления ИИ-помощник принимает запросы и отвечает без ошибок. Но на вопрос о сроке возврата товара называет 14 дней вместо 30: база уже знает о новой редакции регламента, а поиск работает по старому индексу. Проверка доступности сервиса такую поломку не обнаружит.

В статье подробно разберем, как резервировать RAG-помощника по корпоративным документам и восстанавливать его части в согласованном состоянии. Тема обширная, поэтому мы разделили материал на две части. В первой поговорим о том, какие данные нужно сохранять, что можно пересоздать после сбоя и как организовать резервное копирование в S3, PostgreSQL и Kubernetes. А во второй обсудим, как восстановить приложение без рассогласования данных и проверить, что оно корректно работает после сбоя. 

Я Java-разработчик (по крайне мере, пытаюсь им остаться). Пришла в профессию без классического IT-бэкграунда, прошла очень много всяких разных курсов, пробовала изучать разные языки и парадигмы, и вот однажды мне повезло, и я нашла работу. Там приходилось доучиваться на ходу, через боль, Stack Overflow и фразу «а почему это работает?». Но в целом, я думала, будет гораздо сложнее, потому что вроде как почти со всеми задачами я справлялась легко. То есть, получается, что у меня получилось. На моём предыдущем проекте я разобралась в высоконагруженной системе, написала весомую часть бизнес-логики и, внимание, ничего не сломала. Я чувствовала себя вполне уверенно. Я понимала, куда и откуда текут данные, где точка входа, почему упал тест. Это было счастье (которое не ценилось, как всегда бывает).

А потом проект закончился. И я перешла в другую команду. В аналитический контур. В команду по работе с данными.

Я думала: ну, данные, трансформации, ETL. Логично. Интересно. Справлюсь.

Я не справляюсь. Я в шоке. И сейчас расскажу, почему.

IT драма с элементами комедии

Фриланс манит свободой — к черту офис! Теперь ты сам себе начальник! Однако свобода эта обманчива. Вот вроде сидишь ты, работаешь дома, тебе тепло и сухо, и начальства над тобой нет, и никто не мешает, ты один... совсем один. И отвечаешь за все ты. А время уже далеко за полночь, А код выкидывает исключения, а Django ORM отказывается вывозить нагрузку, а все варианты архитектуры сулят скорее минусы, а таймер биржи неумолимо тикает. Тик‑тик‑тик... И нужно уже что‑то решать, но помочь некому — психов нет.

Как поддерживать PostgreSQL и MSSQL в одном приложении, сохраняя единую кодовую базу?

На примере iLocks Online разбираем выбор провайдера в EF Core, отдельные наборы миграций, различия в последовательностях, типах данных и именовании объектов. Рассказываем, что необходимо проверять на обеих СУБД и почему подключения двух провайдеров недостаточно для полноценной совместимости.

Представим: в отчёт добавили новые регистрации, и общий D30 retention снизился с 20% до 10%. При этом ни один из пользователей, для которых D30 уже наступил, не изменил своё поведение. Ошибка может оказаться в знаменателе: туда попали люди, чей тридцатый день ещё впереди.

Разберём эту ситуацию на условных данных и воспроизведём расчёт в SQLite. Отдельно проверим три случая: пользователь вернулся, пользователь не вернулся и результат пока нельзя измерить.

Запрос тормозит, а EXPLAIN ANALYZE выдаёт простыню узлов, в которой непонятно, на чём остановиться. Postgres Professional выпустила бесплатную книгу «PostgreSQL 18. Оптимизация запросов» на основе курса QPT. Она объясняет, как планировщик оценивает кардинальность и стоимость, как читать планы и какие приёмы работают для OLTP и OLAP. Читать можно хоть в метро: результаты запросов уже вплетены в текст, терминал не нужен.

У многих дома лежит папка с сотнями книг в FB2 — и почти ни одного удобного способа читать их где угодно. Десктопные читалки не синхронизируют прогресс, онлайн-сервисы требуют подписку и не принимают «свои» файлы, а связка Calibre с облаком — конструктор для энтузиаста. Рассказываем, как эту проблему решили браузером, PostgreSQL и открытым кодом — и почему в итоге всё свелось к скучному и предсказуемому стеку.

Но обо всём по порядку.

Привет, Хабр! На связи системный аналитик Илья Глазунов и разработчик Кирилл Дунаев. Мы работаем с платформой аналитического карточного хранилища Т-Банка. Попутно открываем все новые грани одного из главных компонентов нашего детища — Apache Cassandra. 

Мы уже изучили тонну материалов, сами стали носителями знаний, делимся ими в команде и на Хабре. Но не перестаем натыкаться на интересные механики и особенности Cassandra, которые приходится разбирать по принципу «с миру по нитке». 

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

В статье разберем, почему утверждение «Cassandra — колоночная БД» частично верное. Приоткроем занавес, как база данных работает с мета-данными и объединением неизменяемых файлов при высокой пишущей нагрузке. А еще подискутируем на тему понятия атомарности операций во вселенной Apache Cassandra и разберемся, причем же тут UDT и frozen UDT. 

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

Возьмём PostgreSQL-базу объёмом 1 ТБ и сравним, во сколько обойдётся её размещение в AWS и на выделенном сервере. Заодно рассмотрим варианты переноса данных и расходы, которые стоит учесть помимо аренды.

Память агентов в тренде с того момента как они появились, чтобы бороться с галюцинациями и давать ответы и решения LLM на собственной информации. Как лучше запрашивать информацию из таблиц или из графа часто решается на вере, начитавшись постов в интернет без своих экспериментов и измерений. В исследовании Sequeda и соавторов GPT-4 отвечал на вопросы по корпоративной SQL базе верно в 16% случаев, а по графу знаний поверх этой же базы в 54%, где у графа была онтология с описанием, а у SQL схемы только DDL типы и названия таблиц/колонок.

В моем GraphRAG одна и та же информация представлена в двух разных формах. Данные из статьи “Мой PostgreSQL быстрее твоего и почти догнал ClickHouse” извлек в 34 таблицы PostgreSQL, а в граф это превратил с помощью отображения R2RML. Подключил обе формы представления знаний к агенту по MCP и задал ему 15 вопросов о статье: через SQL, через SPARQL и дал еще выбор агенту из двух этих видов сразу. В моем эксперименте агент по очереди запускался на трех LLM с открытыми весами. Их можно развернуть на своей инфраструктуре или ноутбуке и данные и вопросы не уйдут провайдеру в логи или агрегатору между вами и LLM.

Таже я проверил и рассчитал что лучше для векторного хранения и семантического поиска: lance или pgvector. Поделюсь своими измерениями на современных моделях как лучше искать и в чем хранить знания.

Обнаружил в эксперименте как DeepSeek придумал SQL-инъекцию чтобы ответить на мой вопрос.

Три часа ночи, API отвечает 500, и рука сама набирает systemctl restart. Иногда это помогает, но есть инциденты, где рестарт добивает то, что ещё работало, и стирает улики. Пять таких: битый конфиг, OOM killer, retry storm, CrashLoopBackOff и диск, забитый логом, — с командами, которые находят настоящую причину, и шпаргалкой на одну таблицу.

Вы когда-нибудь читали такое сообщение от кодинг-агента? Мне не приходилось, а жаль.

Каждый раз, когда я довожу код, сгенерированный AI по моему ТЗ, я прогоняю его через ревью несколькими агентами с разными ролями и точками зрения — что-то вроде взгляда нескольких людей с разным опытом. И почти всегда получаю пачку разнокалиберных замечаний, от мелких до критических. Казалось бы, что сложного: открой новую сессию, скорми ей замечания, дай исправить, прогони ревью снова.

У этой замечательной стратегии, однако, есть одно слабое место: а мы уверены, что такой процесс сходится?

Клиент отправил платёж, не дождался ответа и повторил запрос. На сервере предусмотрен Idempotency-Key, тесты проходят, но деньги всё равно списываются дважды. Проблема возникает, когда второй запрос приходит до завершения первого: оба обработчика успевают проверить ключ и запустить оплату.

Разберём, как закрыть эту гонку с помощью PostgreSQL, что делать при падении процесса и почему даже правильно реализованная идемпотентность внутри сервиса не всегда спасает от повторного списания.