Базы данных *

Если вы хоть раз пользовались LLM, то почти наверняка сталкивались с двумя ее классическими болячками: галлюцинациями и устаревшими знаниями. А когда дело доходит до рабочих задач, появляется еще одна проблема — как использовать внутренние документы компании, не выкладывая их в открытый доступ. 

В этой статье разберем метод RAG (Retrieval-Augmented Generation) и подробно посмотрим на один из самых интересных open-source инструментов для его реализации — RAGFlow. Попробуем понять, насколько он подходит для внутреннего использования.

Работаю в конторе, которая обслуживает госзаказчиков, и последние месяцы у меня одна большая головная боль: перевод старой оракловой схемы на Postgres Pro. Контур закрытый, интернета нет, лицензии на Enterprise нет, проприетарной ora2pgpro тоже нет. То есть из автоматики только опенсорсный ora2pg, и всё.

Штука рабочая, кто пользовался, тот знает. По разным оценкам тянет процентов восемьдесят перевода PL/SQL в PL/pgSQL. Для инструмента, который пилят несколько человек в свободное время против СУБД с тридцатилетней историей, это вообще‑то дофига )

Схема не маленькая, под сотню пакетов и триггеров, плюс куча legacy, которое живёт ещё с нулевых. И когда я первый раз прогнал её через ora2pg и увидел зелёный SHOW_REPORT, я на секунду выдохнул. Рано выдохнул, как выяснилось;)

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

Добавил DuckDB в sqlize.online и загрузил реальный датасет NYC Yellow Taxi — миллионы строк прямо в песочнице. Рассказываю, как всё работает, почему Parquet оказался удобным, и что даёт аналитический движок DuckDB в онлайн‑SQL песочнице.

Эта статья о том, как я написал 200-строчную обертку над SQLModel, которая закрывает все реальные задачи с базой. В подарок идет непрошенное мнение об излишней сложности ORM.

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

Три независимые попытки сделать для PostgreSQL быстрый точный десятичный тип расширением заглохли. Но не потому, что не получилось ускорить арифметику, — арифметику как раз каждое из них ускоряло. Тогда в чём же дело? Здесь я разбираю технические решения в устройстве numeric, которые приводят к высокой стоимости использования этого типа данных. Изучение провожу в сравнении с устройством типа decimal в DuckDB - будучи OLAP СУБД, он свободен от некоторых ограничений PostgreSQL, и гонясь за производительностью, выбирал другой путь развития.

Эндпоинт отдавался за 380–510 мс и 811 КБ. Я думал, что причина одна – тяжёлый запрос. Разобрался: причин было три, и они лежали одна под другой. Пока не убираешь верхнюю, следующую просто не видно. Индексы, обход ORM и внезапно – gzip, который не был включён вообще.

Привет, Хабр! Меня зовут Семён, я разработчик приложений в экосистеме ИТ-продуктов «Лукоморье». До этого я работал дежурным инженером у телеком-оператора: принимал звонки, регистрировал аварии и раскладывал их по пяти Excel-таблицам. В плохие дни через двух операторов проходило до сотни инцидентов, а раз в месяц кто-то тратил полдня, чтобы собрать из этого зоопарка один отчёт для руководства.

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

Потом я сменил работу, а задача меня догнала: уже в «Лукоморье» мне прилетело ТЗ на похожую учётную систему, только для диспетчерской службы из другого региона. На этот раз я собрал работающую систему за неделю, не написав ни строчки кода.

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

Статья написана на основе интервью с Василием Можаровым, старшим менеджером направления Техническая политика, управление знаниями и бенчмаркинг.

«Сибур-Нефтехим» сократил остановочный ремонт на восемь суток и заработал на этом 160 миллионов рублей.

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

В прошлой статье мы упоминали основные SQL‑антипаттерны, способные замедлять работу базы данных. Продолжаем тему — на этот раз про CTE. 

Common Table Expressions (CTE), или конструкции WITH, — привычный инструмент SQL-разработчика. Чем сложнее запрос, тем выше шанс встретить в нём WITH: код становится чище, а запутанная логика разбивается на понятные блоки. CTE используют как альтернативу вложенным запросам и временным таблицам. Однако за внешней простотой и читаемостью скрываются риски снижения производительности, которые не всегда удаётся предвидеть.

Такие запросы на первый взгляд выглядят правильными, но работают неэффективно, и проблема вылезает только в EXPLAIN ANALYZE (инструмент разбирали в прошлом гайде). Разберём четыре антипаттерна CTE, посмотрим планы выполнения и покажем, как переписать запрос. В конце — короткий чек-лист диагностики.

Эта статья может быть полезна начинающим разработчикам и аналитикам, которые уже полюбили синтаксис CTE, но хотят понять, что на самом деле происходит «под капотом» в PostgreSQL.

Мы (ну ладно, я) ждали этого больше десяти лет: в PostgreSQL 19 наконец-то завезли штатную онлайн-перепаковку таблиц. Команда REPACK в ядре и теперь больше никаких сторонних расширений и бесконечных согласований с ИБ. Да? Или нет? Эпоха pg_repack подошла к концу? Спойлер: не спешите удалять старые скрипты и утилиты. На моих тестах новая встроенная команда под нагрузкой заблокировала таблицу на три с лишним минуты, в то время как "старичок" pg_repack уложился в 0.6 секунды.

Выяснил: как устроен новый REPACK под капотом, почему он ломает привычный MVCC и в каких сценариях попытка использовать штатный инструмент на проде станет фатальной ошибкой.

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

Разберём, откуда PostgreSQL берёт статистику, как ANALYZE её собирает и по каким признакам понять, что проблема действительно в оценках планировщика.

Объектное хранилище с типами, деревьями и настоящим SQL прямо в вашей PostgreSQL/MS SQL/SQLite. FK на объекты, EF и Dapper рядом. redb против Mongo и Raven.

Чтобы хранить объекты, графы и деревья с типами, индексами и полноценными запросами, вам не нужна ещё одна база данных. Нужна та, что у вас уже есть.

redb превращает PostgreSQL, MS SQL или SQLite в типизированное объектное хранилище, не отнимая ни SQL, ни EF Core, ни Dapper. Это принципиально другой разговор, чем «MongoDB против RavenDB»: там вы выбираете отдельный движок и живёте с ним отдельно; здесь объекты ложатся в базу, которая у вас уже крутится в проде. Ниже чем это выигрывает у документных баз, с кодом, и где у redb честные границы.

Чтобы не спорить с чучелами: MongoDB  зрелая серверная документная база с горизонтальным масштабированием и огромной экосистемой, и мультидокументные ACID-транзакции у неё есть с версии 4.0 (2018). RavenDB  .NET-native документная база, полностью ACID, с типизированным LINQ и автоиндексами. Обе хорошие продукты. redb просто играет на другом поле и на этом поле у него сильные карты.

И учить, по сути ...

В распределённой СУБД YDB (читается вай‑ди‑би) векторный поиск по kmeans‑tree индексу раскрывался оптимизатором в цепочку из нескольких стадий StreamLookup. Это работало, но порождало большие планы запросов и существенно затрудняло оптимизации самого поиска. Я заменил эту цепочку одним специализированным read‑актором TKqpVectorSearchActor, который берёт всю логику обхода индекса под свой контроль, а не размазывает её по независимым стадиям.

Большинство материалов о компрессии в PostgreSQL отвечают на вопрос «во сколько раз удалось уменьшить базу». Мы предлагаем посмотреть на проблему с другой стороны: какой ценой достигается эта экономия? В статье разбираем архитектурные компромиссы различных подходов к компрессии страниц, объясняем, почему при разработке CSM в Tantor Postgres отказались от погони за максимальным коэффициентом сжатия, и показываем результаты нагрузочных испытаний на реальных базах 1С.

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

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

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

Статья в первую очередь будет полезна разработчикам, интеграторам и архитекторам, которые работают с ESB, ETL и реляционными базами данных. Даже если вы не используете FESB, описанный подход с контрольной точкой и инкрементальной загрузкой можно адаптировать для других интеграционных платформ.

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

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

Привет, Хаброжители! Искусственный интеллект стремительно развивается, и именно большие языковые модели (LLM) задают направление всей индустрии. Погрузитесь в процесс проектирования, обучения и развертывания LLM в реальных бизнес-задачах, опираясь на лучшие практики MLOps. Авторы шаг за шагом показывают, как создать экономичную, масштабируемую и модульную систему на основе LLM. Вместо простых экспериментов в изолированных блокнотах Jupyter научитесь строить комплексные системы, готовые к полноценной эксплуатации.

Полный self-hosted стек observability (Go-приложение + PostgreSQL + ClickHouse) живёт на VPS с 2 ядрами и 2 ГБ RAM. Но сначала стоковый ClickHouse занял 12 ГБ диска при 543 КБ полезных данных, держал 900 МБ памяти и мержил 11 миллионов строк каждые 30 секунд. Разбор с реальными замерами: куда всё ушло, какая гипотеза не подтвердилась, какая ошибка уронила прод и какие настройки в итоге вернули две трети памяти.

Агрегаты в PostgreSQL не очень-то эффективны. Это особенно заметно в сравнении с SQL Server в сценарии, где частичная агрегация не помогает: когда агрегация только подготавливает данные для запроса, обрабатывая большой поток строк и на выходе получая ненамного меньший набор групп и посчитанных по ним агрегатов. Хуже всего приходится типам переменной длины. И здесь характерный пример — SUM(numeric). Встроенные агрегаты обязаны обрабатывать значения в самом общем виде, тогда как на практике данные часто ограничены: например, в БД 1С все numeric имеют фиксированный масштаб.

Отсюда возникает идея оптимизировать агрегаты, подстроив их под конкретные условия эксплуатации. Раньше это было возможно только в форке PostgreSQL. Однако недавно David Rowley добавил в ядро любопытный инструмент расширения SupportRequestSimplifyAggref (коммит 42473b3b31, PostgreSQL 19): теперь можно предоставить планнеру кастомную логику трансформации агрегата через механизм функций поддержки планнера (prosupport). Сам механизм существует ещё с PostgreSQL 12, но до агрегатов добрался только сейчас. В ядре новый запрос применяется скромно: заменяет COUNT(1) и COUNT(col) по NOT NULL-колонке на COUNT(*). А вот расширению он позволяет сделать с агрегатом во время планирования практически что угодно. Это открывает пространство для интересных технических решений.

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

Про асинхронный ввод-вывод в PostgreSQL за последний год написали многие:

Механизм появился в 18-й версии, в 19-й его докрутили и в релиз-нотах он числится среди главных улучшений производительности.

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