Базы данных *

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

Несмотря на самостоятельность этой публикации, она раскрывает некоторые вопросы, поднятые ранее в статье "Как пройти… к третьей нормальной форме?"

Векторные базы данных в serverless-модели обычно обещают простую вещь: не требуется развёртывание и настройка, а провайдер берёт на себя управление хранилищем, масштабирование и обеспечение доступности. turbopuffer - один из лучших примеров этого класса: быстрый движок векторного поиска, использующий object storage в качестве хранилища, которым пользуются Cursor, Notion, Linear и другие.

Такой подход действительно снижает операционную нагрузку на команду, но он не бесплатен. Поэтому возникает закономерный вопрос: какая часть этих преимуществ нужна небольшому, четко определенному сценарию, и во что обойдется та же нагрузка на двух недорогих VPS с Manticore Search - по цене и по производительности?

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

В аналитике больших данных системы массивных параллельных вычислений часто находятся под постоянной нагрузкой в режиме 24/7. Из десятков и сотен тысяч запросов в день многие исполняются одновременно и конкурируют за ограниченные ресурсы вычислительного кластера. Чем рациональнее каждый отдельный запрос их использует, тем больше запросов система сможет обслуживать параллельно. Соответственно, выше пропускная способность за конкретный отрезок времени. Как правило, проблема нехватки ресурсов остро ощущается в пиковые часы нагрузки. Можно бесконечно до совершенства настраивать и править параметры сессии на каждый запрос индивидуально вручную, но нам — команде разработки платформы данных Data Ocean Nova — всегда хочется иметь более системный подход.

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

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

Мне это мешало достаточно, чтобы потратить вечер и вытащить данные напрямую из Reports API в Google-таблицу: один лист — весь аккаунт по неделям, рядом разрезы по площадкам и по каждой кампании, плюс подневное скользящее окно. Обновляется само через Apps Script. Ниже разберу, как это устроено под капотом, где у конструкции стенки (их хватает) и почему свои боевые дашборды я в итоге всё равно унёс в DataLens. Таблица — пустой шаблон, отдаю по ссылке в конце, можно скопировать и распотрошить.

Адресат — те, кто сам копается в Директе и аналитике. Написали такой инструмент — будет с чем сверить решения; только думаете — сэкономите вечер на граблях.

У каждого релиза Postgres свой характер.

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

В Postgres 19 есть улучшения на любой вкус. Встроенная команда REPACK CONCURRENTLY упрощает обслуживание крупных рабочих баз данных. SQL-запросы к графам свойств наверняка привлекут много внимания. Логическая репликация становится полноценнее.

Разработчики также улучшили VACUUM, EXPLAIN, COPY, секционирование, мониторинг и планировщик. Эти изменения не так заметны, но упрощают эксплуатацию рабочих систем.

До финального релиза детали могут измениться. Но бета-версия Postgres 19 уже позволяет оценить новые возможности и понять, как они повлияют на разработку и эксплуатацию систем.

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

Сначала туда попадают предсказуемые вещи: CRM, ERP и внутренняя отчетность. Но потом добавляются документы, записи разговоров, данные для ML, генеративный ИИ и еще десяток сценариев, о которых никто не думал, когда проектировал DWH десять лет назад.

Что тогда делать? Сейчас расскажу.

18–21 ноября 2026 года в Непале пройдёт PGConf.Nepal 2026 — четвёртая PostgreSQL-конференция в стране. Предыдущие конференции состоялись в 2018, 2023 и в 2025 годах. В этом году конференция должна стать шире по составу участников, организаций и стран.

Этот материал подготовил автор решения Database Compression Tool (DCT), представленного на Инфостарт Маркетплейс. Мы публикуем его от имени компании, чтобы поделиться практической экспертизой наших авторов. В статье разработчик DCT рассказывает, как устроена свертка больших баз 1С, какие ошибки могут привести к нарушению учета и что необходимо учитывать при работе с базами объемом в сотни гигабайт и несколько терабайт. Мнение, выводы и практические рекомендации в материале принадлежат автору решения.

Заявка выглядит буднично: ERP размером 2,3 терабайта, бэкап перестал влезать в ночное окно, место в СХД заканчивается быстрее, чем согласовывается его закупка. Диски можно докупать до бесконечности, но в какой-то момент кто-то произносит слово «свёртка». И тут выясняется, что удалить из работающей учётной системы две трети строк и ничего при этом не сломать заметно сложнее, чем звучит.

Первый профессиональный навигатор по качественным исследованиям в бизнесе – который увлекает, объясняет сложное на конкретных примерах и помогает увереннее ориентироваться в мире исследований.  Авторы – исследователи-практики с профильным образованием: социальный психолог Константин Ефимов и Анастасия Жичкина, кандидат психологических наук.

Полностью книга называется: «Качественные исследования в бизнесе. Практическое руководство для исследователей, дизайнеров, продактов и стратегов». Объем: 392 страницы. Вес – 1 килограмм.

Основная проблема с литературой про исследования – в том, что ее нет. Нет признанных источников, к которым можно адресовать человека, желающего разобраться в теме, если не считать AI. Есть масса статей с описаниями конкретных практик и кейсов, но они касаются каких-то частных случаев: кто-то сделал фишечку, получилось прикольно. До сих пор очень не хватало текста – или текстов – которые объединяли бы эти фишечки в систему и который можно было бы читать как роман – с началом, сюжетом и завершением.

Такого источника нет не только на русском языке, но и на английском – существующие руководства либо слишком академические, либо совсем простые. Не хватало насыщенного описания процесса исследований, со сложностями и подводными камнями. Гладко все бывает только в мануале и в отчете, а в реальности, как правило, происходит непонятно что. Эта книга показывает, как обрабатывать это «непонятно что» - как исследования помогают в принятии решений в бизнесе, со всеми сложностями этого процесса, на конкретных примерах. Масса интересных кейсов разных бизнес-решений, в том числе провальных.

SSB — «мы стояли на „плоскости“»

Предлагаемый текст представляет опыт ознакомления автора с тестом SSB в свете обычных прикладных вопросов BI‑проекта умеренного размаха. Автор пытается бросить пытливый взгляд на спектр перспективных возможностей, обеспечиваемых доступностью и масштабируемостью теста SSB.

Как ускорить Hash Join в PostgreSQL, отбросив 99% строк ещё до самого соединения? Рассказываем о фильтре Блума в СУБД Tantor Postgres на живых и синтетических примерах.

Меня заинтересовал новый плагин DB Client, который идёт в составе OpenIDE. Давайте посмотрим, может ли он уже на текущий момент стать достойной альтернативой платному DataGrip? Я не предъявляю каких-то узкоспециальных требований к таким инструментам. В основном требуется писать и оптимизировать sql-запросы, просматривать структуру таблиц и диаграмму связей между ними, просматривать актуальный DDL, выполнять мелкие правки данных “на лету”, а также делать импорт и экспорт данных в различных форматах. Давайте по этим пунктам и пройдёмся.

PostgreSQL 19 добавляет SQL/PGQ (Property Graph Queries, запросы к графам свойств) на основе стандарта SQL:2023. Графовые структуры можно определить поверх уже существующих реляционных таблиц и запрашивать их синтаксисом сопоставления с образцом. Не нужны новый движок хранения, расширения или миграция данных.

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

История других отраслей показывает, что происходит дальше. До Uber цену поездки знал только таксист, и пассажир зависел от его решения. Как только маршрут и стоимость стали видны на экране, преимущество водителя исчезло. Booking сделал прозрачными цены на отели, маркетплейсы - на товары, Google Maps - на логистику. Строительство пока остаётся одним из немногих крупных рынков, устроенных «как такси до Uber»: полной картиной по стоимости и срокам владеет только одна сторона, а вторая оплачивает эту асимметрию перерасходами.

Дальше в статье - нидерландский строительный картель с двойной бухгалтерией и 1300 оштрафованных фирм; алгоритмы, которые находят следы сговора прямо в цифрах торгов; два миллиарда долларов SoftBank, сгоревшие в «кнопке Uber для стройки»; и рынок жилья, который свою уберизацию уже прошёл. Через историю и паттерны видно, какими будут инструменты уберизации строительной отрасли в следующие десятилетия.

Мы продолжаем праздновать 30-летие PostgreSQL и публикуем перевод второй фундаментальной статьи о СУБД. Перевод первого манифеста можно прочесть в этом посте.

Привет, Хаброжители! «Книга с кабанчиком» — вы наверняка слышали о ней? Бестселлер Мартина Клеппмана, изданный почти 10 лет назад, знают и любят все, кому приходится строить высоконагруженные системы, обрабатывающие огромное количество запросов.

Хотим сообщить всем заинтересованным: мы открыли предзаказ на книгу «Высоконагруженные приложения. Программирование, масштабирование, поддержка. 2-е изд.». Новое издание значительно переработано под современные реалии. Наибольшие технические изменения связаны с развитием ИИ и облачных архитектур. Хотите узнать, что в нем изменилось? Расскажем коротко.

💾 MinIO, MongoDB, PostgreSQL для хранения 25 лет истории стоимости акций

Когда строишь эмулятор для проверки торговой стратегии 20 акций на 25 лет исторических данных поминутно, выбор хранилища становится архитектурной задачей. В статье разобрал, почему попытка использовать MinIO не оправдала себя, где упирается MongoDB и как PostgreSQL с Pgpool-II и read-репликами сократил время чтения одной свечи с 40мс до 10мс

Один контрольный эксперимент — и один красивый ложный вывод, который мы чуть не опубликовали

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

«А если взять GPT или другую топовую модель — неужели она действительно не сможет ответить на вопросы по СП и ГОСТ?»

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

Аргумент понятен и звучит убедительно. Спорить с ним словами бесполезно — нужны данные. Так что считайте это исследование нашим развёрнутым ответом. Ниже — 3000 слепых оценок того, что фронтир-модели умеют на строительных нормах «из коробки», и что меняется, если поверх той же самой модели поставить доменный агентный поисковый контур.

Только не ждите вывода «наша система лучше всех LLM вообще» — его не будет. Мы показываем другое: там, где ответ обязан быть проверяемым по нормативному корпусу, агентный контур резко снижает число неподтверждённых ссылок — на одном и том же генераторе.

Заодно расскажем, как мы сами едва не попались — на методике, а не на моделях.

Giga4DQM — открытый проект, реализующий концепцию ИИ-агентов для автоматизированного расследования инцидентов с данными и построения целостной картины зависимостей в существующей БД. Система понимает вопросы на естественном языке, самостоятельно анализирует структуру базы, строит граф зависимостей и формирует диагностические запросы. Архитектура не привязана к одной СУБД: в качестве примера взята PostgreSQL, но подход может быть адаптирован к любой системе с развитым каталогом метаданных. В основе — мультиагентная архитектура на основе GigaChat и LangGraph. Код открыт, доступен для тестирования и внедрения.

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

Большинство распределенных хранилищ при заполнении примерно на 95% начинают работать в 2-3 раза медленнее. В наших тестах производительность упала всего на 4–9%. Причина в архитектуре MIND uStor. В этой статье разберем, как устроена модель хранения данных, как организован ввод-вывод и за счет чего система сохраняет производительность даже при высокой утилизации дискового пространства.

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

Здесь разберем, как устроено размещение данных, каким образом кластер сохраняет производительность при заполнении свыше 90%, как работают RF- и EC-пулы, а также почему iSCSI-таргет реализован в пространстве пользователя. Отдельно остановимся на компромиссах, которых потребовала реализация этих решений.