Эксперты в подборе IT-оборудования
Любая компания работает с данными: клиентская база, заказы, склад, бухгалтерия, аналитика. Держать всё это в Excel-таблицах можно ровно до того момента, пока сотрудников не станет десяток. Дальше файлы теряются, версии путаются, а одновременная работа превращается в переписку «закрой, я сохраню».
СУБД - программа, которая берёт хранение данных на себя: следит за целостностью, разграничивает доступ, ищет за доли секунды и делает резервные копии. Ниже - что именно она умеет, как это выглядит в деньгах для бизнеса и что из этого реально можно поставить в российской компании в 2026 году.
База данных - это структурированное хранилище информации. СУБД - программная оболочка, которая этим хранилищем управляет: обеспечивает быстрый доступ, следит за целостностью, разграничивает права и автоматизирует рутину.
Представьте библиотеку: книги - это данные, а библиотекарь с каталогом и правилами выдачи - СУБД. Найти нужную книгу можно и самостоятельно, копаясь в стеллажах, но с каталогом это займёт секунды, а не часы.
Практический смысл простой: без СУБД квартальный отчёт собирают неделю, сводя выгрузки вручную. С ней - формируют запросом.
СУБД структурирует информацию так, чтобы её было легко искать, обновлять и анализировать. В реляционных системах данные лежат в таблицах со связями между ними. В нереляционных - в виде документов, графов или пар ключ-значение.
Главное преимущество: вы описываете структуру один раз, и дальше система сама следит, чтобы данные ей соответствовали. Попытка записать текст в числовое поле? Не пропустит. Удаление клиента, у которого есть активные заказы? Предупредит или запретит, в зависимости от настроек.
Схему при необходимости меняют на ходу. Добавили новое поле в карточку товара - обновили схему, а не переписали половину кода приложения.
Самая частая операция с базой - поиск. Найти всех клиентов из Москвы, которые купили больше чем на 50 тысяч за последний месяц. В Excel для этого придётся фильтровать, сортировать и считать руками. СУБД сделает это одним запросом.
Ускоряют поиск индексы. Индекс - это заранее построенная структура, по которой СУБД сразу переходит к нужным строкам вместо перебора всей таблицы.
Порядок величины. На большой таблице разница между поиском с индексом и без него - это разница между «мгновенно» и «полный перебор всех строк». Чем больше записей, тем сильнее расходятся эти два сценария: на десяти тысячах строк вы разницы не заметите, на десяти миллионах она решает всё. Точные цифры зависят от структуры таблицы, запроса и железа, поэтому измерять надо на своих данных - через план выполнения запроса.
Транзакция - группа операций, которые выполняются либо все вместе, либо не выполняются вообще. Классический пример: перевод денег между счетами. Списалось с одного, но не дошло до другого из-за сбоя? СУБД откатит операцию, и оба счёта вернутся в исходное состояние.
За это отвечают принципы ACID: атомарность (всё или ничего), согласованность (данные всегда остаются корректными), изолированность (параллельные транзакции не мешают друг другу), долговечность (подтверждённые изменения не пропадут даже при аварийном выключении).
Все изменения журналируются, поэтому после сбоя система восстанавливает последнее корректное состояние сама.
СУБД разграничивает права: кто может читать данные, кто изменять, кто удалять. Это работает на уровне таблиц, а в развитых системах - на уровне отдельных строк и столбцов.
Контроль доступа на уровне строки. Менеджер видит только своих клиентов, директор - всех. База одна, права разные.
Сверх того: шифрование данных, аудит действий пользователей, средства против SQL-инъекций. Всё это встроено в СУБД и работает, если настроено.
СУБД автоматизирует создание копий и восстановление из них. Настроили расписание - система делает бэкапы по ночам, хранит их заданный срок и умеет откатиться на точку во времени.
Многие СУБД поддерживают репликацию: данные копируются на второй сервер в реальном времени. Основной упал - переключаемся на резервный.
Оговорка, которая стоит дороже всего остального: резервная копия, из которой ни разу не восстанавливались, - это не резервная копия, а предположение. Проверять восстановление надо по календарю, а не когда прижмёт.
Миллионы операций в день, строгие требования к безопасности, отчётность для регулятора. Каждая операция логируется, каждое изменение отслеживается, откат возможен в любой момент.
Интернет-магазин обрабатывает заказы, ведёт склад, анализирует поведение покупателей. СУБД связывает товары, клиентов, заказы и платежи в одну систему и держит нагрузку в пиковые дни распродаж.
Электронные медкарты, история болезней, назначения, результаты анализов. Врачу нужен мгновенный доступ, а данные относятся к персональным и требуют защиты по 152-ФЗ.
Сколько продали за месяц, какие товары популярны, где проседают продажи. Выборки, группировки, агрегация делаются запросами. Аналитик тратит время на выводы, а не на сведение выгрузок.
| Критерий | Реляционные (SQL) | Нереляционные (NoSQL) |
|---|---|---|
| Структура | Жёсткая схема, таблицы с чёткими связями | Гибкая или отсутствующая схема |
| Применение | Финансы, бухгалтерия, CRM, ERP, 1С | Логи, IoT, кэш, рекомендательные системы |
| Транзакции | Полная поддержка ACID | Часто ослаблены ради скорости |
| Масштабируемость | Вертикальная: более мощный сервер | Горизонтальная: больше серверов |
| Язык запросов | SQL, стандартизирован | Зависит от системы |
| Примеры | PostgreSQL, Postgres Pro, MySQL, MS SQL Server, Oracle | MongoDB, Redis, Cassandra, Tarantool |
Реляционные подходят там, где важна строгая структура и целостность. Нереляционные - где нужна гибкость и скорость на больших однотипных потоках. Как устроена изнутри одна из самых распространённых реляционных систем, разобрано отдельно - архитектура MySQL.
Для большинства задач среднего бизнеса ответ скучный: реляционная СУБД, скорее всего PostgreSQL или её российская сборка. NoSQL берут под конкретную задачу рядом с основной базой, а не вместо неё.
Для российского бизнеса выбор СУБД начинается с вопроса, что можно легально купить и поддерживать. ACID подождёт.
Oracle ушёл из России полностью - вместе с продажами, поддержкой и правом использования: продукты компании не авторизованы для экспорта, реэкспорта и применения в России. Поставки Microsoft SQL Server ограничены санкциями ЕС наравне с облачными сервисами Azure. Если эти системы у вас уже работают, они не выключатся сами по себе, но обновлений, патчей безопасности и легального продления лицензий ждать не приходится - и это аргумент планировать миграцию заранее, а не в момент инцидента.
Что берут взамен. Основной путь - PostgreSQL и российские сборки на его основе. У Postgres Pro три редакции: Standard, Certified и Enterprise. Certified - вариант с сертификатом ФСТЭК, нужен там, где есть требования по защите информации. Enterprise рассчитан на высоконагруженные системы. Есть и другие отечественные СУБД, в том числе нереляционные.
Три требования отечественности - разные, и одно не заменяет другое:
Проверять надо каждое требование отдельно: наличие СУБД в реестре Минцифры само по себе не означает, что у неё есть сертификат ФСТЭК.
Про операционные системы под всё это у нас есть отдельный разбор - российские ОС для импортозамещения.
Миграции схемы через код, автоматическое развёртывание на новых серверах, тестирование на копии продуктовой базы. Для команд разработки это стандарт, а не экзотика.
СУБД поддерживает разные типы данных - от чисел и текста до JSON и геоданных, - даёт API для внешних систем и держит часть логики прямо в базе - в хранимых процедурах и триггерах.
Схема базы даёт менять бизнес-логику без переписывания приложений. Добавили новый статус заказа - обновили справочник, и всё работает дальше.
База данных как сервис: не нужно покупать сервер, ставить и настраивать СУБД, платите за использование. Модель удобная, но для российской компании её надо оценивать отдельно - AWS RDS, Google Cloud SQL и Azure Database в России недоступны. Аналогичные услуги предлагают российские провайдеры, и выбирать приходится среди них, отдельно проверяя, где физически лежат данные: для персональных данных это требование 152-ФЗ, а не вопрос предпочтений.
СУБД научились работать с объёмами в петабайты, поддерживают распределённые вычисления и стыкуются с системами машинного обучения. Для среднего бизнеса это чаще всего избыточно: разговор про Big Data начинается там, где обычная база перестаёт справляться, а не там, где хочется модного слова.
Датчики и счётчики генерируют миллионы однотипных записей. Под такие потоки есть специализированные СУБД временных рядов - InfluxDB, TimescaleDB. Классическая реляционная база на этой задаче тоже работает, но заметно хуже по месту и скорости.
Лицензии и доступность. Первый пункт, а не последний. Можно ли купить, будет ли поддержка, есть ли продукт в реестре Минцифры, если у вас закупки по импортозамещению.
Объём данных и нагрузка. Миллионы записей и сложная аналитика требуют системы с хорошим оптимизатором запросов и грамотного железа под ней.
Требования к согласованности. Финансы и медицина не прощают ошибок - здесь строгие реляционные СУБД с полной поддержкой транзакций.
Скорость разработки. Если логика меняется каждую неделю, гибкая схема экономит время.
Бюджет и инфраструктура. Облако снижает порог входа, но на больших объёмах и длинной дистанции обычно дороже своих серверов.
Экспертиза команды. Экзотическая СУБД, с которой никто не работал, обойдётся дороже любой лицензии. PostgreSQL и его российские сборки выигрывают тут за счёт доступных специалистов и документации.
Про то, каким должно быть железо под всё это, у нас есть отдельная статья: сервер баз данных - каким он должен быть. А про то, как база работает в связке с приложением, - разбор файл-серверной и клиент-серверной архитектуры.
Отсутствие индексов. База тормозит, потому что каждый запрос перебирает таблицу целиком. Лечится построением правильных индексов - как именно, разобрано в статье про оптимизацию SELECT-запросов.
Резервные копии, которые никто не проверял. Пока всё работает, о бэкапах не думают. Потом ломается диск.
Слишком широкие права. Когда у всех права администратора, случайное удаление критичных данных - вопрос времени.
Неправильный тип СУБД. NoSQL под строгие финансовые транзакции или реляционная база под поток телеметрии обернутся проблемами.
Железо не под задачу. База упирается не в лицензию, а в память и диски. Экономия на оперативной памяти и дисковой подсистеме съедает любой выигрыш от выбора «правильной» СУБД.
Чем база данных отличается от СУБД?
База данных - это сами данные и их структура. СУБД - программа, которая ими управляет: выполняет запросы, следит за целостностью, раздаёт права, делает копии. Говоря «поставили PostgreSQL», имеют в виду СУБД.
Какую СУБД выбрать небольшой компании?
В подавляющем большинстве случаев PostgreSQL или его российскую сборку. Бесплатна в базовом варианте, есть специалисты на рынке, покрывает почти любые задачи среднего бизнеса и не создаёт проблем с импортозамещением.
Что делать, если у нас работает Oracle или MS SQL?
Ничего срочного, они не отключатся. Но обновлений и легального продления лицензий не будет, поэтому миграцию стоит планировать спокойно и заранее, а не после инцидента с безопасностью.
Обязательно ли брать СУБД с сертификатом ФСТЭК?
Нет. Сертификат нужен, если у вас государственные информационные системы, значимые объекты КИИ или иные требования регулятора по защите информации. В остальных случаях достаточно обычной редакции.
Нужен ли отдельный сервер под базу данных?
Как только база становится рабочим инструментом нескольких десятков сотрудников - да. СУБД конкурирует за память и диски с остальными службами, и на общем сервере проигрывает именно она, а вместе с ней тормозит вся работа.
Реестр Минцифры и сертификат ФСТЭК - это одно и то же?
Нет, это независимые требования. В реестре может быть продукт без сертификата, и наоборот. Проверять надо оба, если оба нужны по условиям закупки.
Подберём и соберём сервер под вашу базу данных.
Скажите, какая СУБД и сколько пользователей, - посчитаем память, диски и процессор под реальную нагрузку, соберём и протестируем перед отгрузкой.
Смотрите серверы для баз данных в каталоге или напишите нам.
Телефон: 8 800 551-80-12. Почта: info@ittelo.ru. На рынке серверов 11+ лет.
