Базы данных *

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

Сначала туда попадают предсказуемые вещи: 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-таргет реализован в пространстве пользователя. Отдельно остановимся на компромиссах, которых потребовала реализация этих решений.

Всем привет. Меня зовут Василий Гуров, я занимаюсь задачами оптимизации в ML Research Lab MAGNIT TECH. В этом материале разберу два промышленных кейса из крупного ритейла – планирование смен сотрудников магазинов и сглаживание нагрузки на распределительные центры.

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

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

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

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

Не будем объяснять базу, но все знают, что магнитные головки HDD, прицепленные с одного конца "коромысла", приводятся в движение магнитной катушкой "Voice Coil" зажатой между двух неодимомых магнитов с другой стороны (а в современных дисках есть ещё и точный "доворот" пьезоэлементами на конце, недалеко от самих головок). Когда HDD надо переместить БМГ (Блок Магнитных Головок) на другую далёкую дорожку, он подаёт на Voice Coil резкий импульс тока, чтобы сорвать массивную металлическую конструкцию с места в нужном направлении, а потом ещё один обратный импульс тока для резкого торможения. Если посмотрите на фото БМГ, то поймёте как велика Voice Coil во всей этой конструкции и что ускорения и торможения происходят с довольно большими перегрузками. Это как если бы автомобиль весом 1.5 тонны разгонялся до 100 км/ч за 0.05...0.1 сек, а тормозил со скорости 100 км/ч на дистанции 1 метр и человек массов 80 кг потяжелел бы до 4 тонн. Если головки нужно перемещать в диапазоне до 50 дорожек, то Voice Coil не работает, достаточно пошевелить кончиком с головками с помощью пьезо-актуатора, который умеет гнуть металлический конец "коромысла" на 1...5 микрометров. И прыгать за 8 миллисекунд нужно не между тысячами дорожек, а по всей поверхности блина от края до края.

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

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

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

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

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

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

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

Что такое электронная таблица, объяснять не надо. Все знают Excel, и многие хоть раз им пользовались. История создания электронных таблиц тоже, на первый взгляд, незамысловатая и сравнительно недолгая: как только появились первые ПК, сразу началась разработка ПО для выведения на экран их монитора интерактивной таблицы, которая сильно облегчила бы работу бухгалтеров и менеджеров. IT-инженеры уложились в 15 лет, с конца 60-х до середины 80-х, чтобы создать электронную таблицу от начала и до конца – от разработки самого принципа ее программирования до появления первых электронных таблиц (от VisiCalc до Excel) на экране ПК, сильно порадовав тем самым белых воротничков (и не только их). Дальше шло лишь усовершенствование электронных таблиц.

С чего вдруг IT-инженеры и изобретатели озаботились бухгалтерскими проблемами, тоже понятно. Люди старшего поколения помнят, что можно было делать на первых ПК 70-х и 80-х годов, еще до эпохи интернета. Если оставить в стороне возможность самостоятельно заняться программированием и обмениваться файлами с такими же энтузиастами, что сейчас часто ставят в заслугу первым ПК (для этого все-таки надо было в душе быть айтишником), то на этих ПК можно было играть в интерактивные игры (правда, на игровых приставках к телевизору это обходилось дешевле) и можно было использовать ПК как пишущую машинку, при пользовании которой не надо было замазывать белилами ошибки и ждать, когда те высохнут, чтобы напечатать поверх правильную букву. Сказать, что это сильно порадовало писателей и редакторов бумажных СМИ значит ничего не сказать, это была настоящая революция в писательском и издательском деле, сравнимая разве что с изобретением печатного станка Гутенбергом в XV веке. А когда к этому добавились еще электронные таблицы для сведения дебета с кредетом в интерактивном режиме, это была еще одна революция в бухгалтерии того же масштаба, если не большего.