Раздел 12 — Другие СУБД и выбор СУБД

Чем отличаются альтернативы PostgreSQL и как обосновать выбор

Прогресс курса Раздел 12 из 13

Что вы освоите в этом разделе

2 академических часа теории. Практических заданий в разделе нет — по программе это обзорная тема. В конце даны контрольные вопросы для зачёта.
01

MySQL и MariaDB: одна родословная

MySQL создана в 1995 году шведской компанией MySQL AB. В 2008-м её купила Sun Microsystems, а в 2010-м вместе с Sun она перешла к Oracle — то есть к прямому конкуренту на рынке коммерческих СУБД.

Сообщество восприняло это как угрозу. Михаэль Видениус, один из основателей MySQL, создал форк — MariaDB, названный в честь его дочери. Форк остался свободным и развивается независимо.

Как обстоят дела сейчас

  • MySQL развивается Oracle, доступна в свободной редакции Community и в коммерческой Enterprise. Часть возможностей есть только в платной версии.
  • MariaDB полностью свободна, включает разработки, которых нет в MySQL: дополнительные движки хранения, собственные механизмы кластеризации.
  • Совместимость сохраняется на уровне протокола и базового SQL, но с годами версии расходятся: код под MySQL 8 не всегда работает на MariaDB и наоборот.
  • В российских дистрибутивах Linux по умолчанию обычно поставляется MariaDB — как свободная альтернатива продукту Oracle.
Практический вывод: «MySQL» в вакансиях и требованиях обычно означает «MySQL или MariaDB» — базовые навыки переносятся. Но при выборе для нового проекта различие существенно: MariaDB не зависит от лицензионной политики Oracle, что после 2022 года для российских компаний стало отдельным аргументом.
02

Движки хранения

Архитектурная особенность MySQL и MariaDB, которой нет у PostgreSQL: способ физического хранения выбирается для каждой таблицы отдельно.

ДвижокТранзакцииБлокировкиПрименение
InnoDBда, ACIDна уровне строкосновной выбор по умолчанию
MyISAMнетна уровне таблицыустаревший, встречается в старых системах
MEMORYнеттаблицавременные данные в оперативной памяти
AriaнеттаблицаMariaDB, улучшенный MyISAM
ColumnStoreограниченноMariaDB, аналитика
Таблица на MyISAM не поддерживает ни транзакций, ни внешних ключей: команда FOREIGN KEY принимается синтаксически и молча игнорируется. Целостность при этом никем не обеспечивается. Это одна из главных причин, по которой в старых PHP-проектах базы приходят в противоречивое состояние. При работе с унаследованной системой первым делом проверьте движок таблиц.

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

03

Различия диалектов

Стандарт SQL описывает ядро языка, но каждая СУБД расширяет и трактует его по-своему. Ниже — различия, на которые чаще всего наталкиваются при переносе кода.

ЧтоPostgreSQLMySQL / MariaDB
АвтоинкрементGENERATED ALWAYS AS IDENTITY, SEQUENCEAUTO_INCREMENT, последовательностей нет*
Кавычки для имёндвойные: "user"обратные: `user`
Регистр имён без кавычекприводится к нижнемузависит от файловой системы
Строковая конкатенация||concat(); || означает OR
Вставка или обновлениеON CONFLICT ... DO UPDATEON DUPLICATE KEY UPDATE
Транзакционный DDLданет, неявная фиксация
Логический типbooleantinyint(1)
ПеречислениеCREATE TYPE ... AS ENUMENUM прямо в столбце, ещё есть SET
Массивы, диапазоныестьнет
JSONjsonb с индексами GINjson, индексация через генерируемые столбцы
Регистрозависимость строкда, сравнение точноезависит от collation, часто без учёта регистра
Полнотекстовый поискtsvector + GINFULLTEXT-индексы
Оконные функции, CTEдавнос MySQL 8 / MariaDB 10.2

*В MariaDB последовательности появились в версии 10.3, в MySQL их по-прежнему нет.

-- PostgreSQL
CREATE TABLE users (
    id    bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    name  varchar(100) NOT NULL,
    email varchar(200) UNIQUE
);
INSERT INTO users (name) VALUES ('Анна')
ON CONFLICT (email) DO UPDATE SET name = EXCLUDED.name;

-- MySQL / MariaDB
CREATE TABLE users (
    id    BIGINT AUTO_INCREMENT PRIMARY KEY,
    name  VARCHAR(100) NOT NULL,
    email VARCHAR(200) UNIQUE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
INSERT INTO users (name) VALUES ('Анна')
ON DUPLICATE KEY UPDATE name = VALUES(name);
Ловушка кодировки в MySQL. Кодировка с историческим именем utf8 хранит не более трёх байт на символ и не вмещает эмодзи и часть редких символов. Настоящий UTF-8 называется utf8mb4 — его и нужно указывать всегда. Симптом ошибки: текст обрезается на первом эмодзи или запрос падает с Incorrect string value. В PostgreSQL такой проблемы нет: UTF8 означает UTF-8.
Строгий режим. Исторически MySQL при вставке слишком длинной строки молча её обрезал, а некорректную дату превращал в 0000-00-00 — вместо того чтобы отвергнуть операцию. Начиная с версии 5.7 строгий режим включён по умолчанию, но в унаследованных конфигурациях он часто отключён. PostgreSQL всегда отвергает некорректные данные — и это принципиальная разница в философии: лучше ошибка, чем испорченные данные.
04

SQLite и встраиваемые СУБД

SQLite — не сервер. Это библиотека, работающая внутри процесса приложения; вся база лежит в одном файле. Установки и администрирования не требует.

Сильные стороны

Ноль настройки, база — один файл, легко копировать и передавать. Очень быстрая на чтение. Самая распространённая СУБД в мире: она есть в каждом телефоне, браузере и множестве настольных программ.

Ограничения

Одновременная запись только одна на всю базу. Нет пользователей и прав. Нет сетевого доступа. Динамическая типизация: тип — рекомендация, а не ограничение.

-- В SQLite это выполнится без ошибки:
CREATE TABLE t (age INTEGER);
INSERT INTO t VALUES ('не число');   -- строка попадёт в целочисленный столбец

-- В PostgreSQL — ошибка:
-- ERROR: invalid input syntax for type integer
С версии 3.37 в SQLite появились строгие таблицы (CREATE TABLE ... STRICT), где типы проверяются. По умолчанию поведение осталось прежним ради совместимости. Уместное применение SQLite — мобильные и настольные приложения, локальный кэш, файлы обмена данными, прототипы. Неуместное — веб-приложение с несколькими одновременно пишущими пользователями.
05

Краткий обзор остального рынка

Реляционные

  • Oracle Database — самая функциональная и самая дорогая. Исторически основа банковских и корпоративных систем. В России с 2022 года лицензии не продаются и поддержка не оказывается, идёт массовая миграция.
  • Microsoft SQL Server — тесно связан с экосистемой Microsoft, язык T-SQL. В России в том же положении, что Oracle.
  • Postgres Pro — российская сборка PostgreSQL, в реестре отечественного ПО, с сертификацией ФСТЭК и коммерческой поддержкой. Основной путь миграции с Oracle.

Специализированные

  • ClickHouse — колоночная СУБД для аналитики, разработана в «Яндексе», открытый код. Агрегаты по миллиардам строк за секунды. Не предназначена для точечных изменений отдельных записей.
  • Redis — хранилище «ключ — значение» в оперативной памяти. Кэш, сессии, счётчики, очереди. Как основное хранилище не применяется.
  • MongoDB — документная. Гибкая структура записи ценой того, что за схемой теперь следит приложение.
  • Tarantool — российская платформа от VK: хранилище в памяти вместе с сервером приложений.
  • Elasticsearch — поисковый движок. Часто дополняет основную СУБД, а не заменяет её.
Специализированные хранилища почти всегда работают вместе с реляционной базой, а не вместо неё. Типичная рабочая связка: PostgreSQL как источник истины, Redis для кэша и сессий, ClickHouse для аналитики, Elasticsearch для поиска. Каждое добавленное хранилище — это ещё одна система, которую нужно резервировать, обновлять и синхронизировать.
06

Как выбирать СУБД

Критерии в порядке важности

  • Характер нагрузки. OLTP или OLAP; соотношение чтения и записи; объём данных сейчас и через три года.
  • Требования к целостности. Финансовые операции требуют ACID безоговорочно.
  • Компетенции команды. Знакомая СУБД, эксплуатируемая уверенно, лучше идеальной, с которой никто не работал.
  • Лицензия и юридические ограничения. Стоимость, доступность в стране, требование реестра отечественного ПО.
  • Эксплуатация. Есть ли специалисты, инструменты резервного копирования, мониторинг, документация на русском.
  • Экосистема. Драйверы для вашего языка, поддержка в ORM, миграционные инструменты.
  • Горизонт жизни системы. Проект на десять лет и прототип на три месяца выбирают по-разному.
ЗадачаРазумный выбор
Веб-приложение, новый проектPostgreSQL
Информационная система для госзаказчикаPostgres Pro
Поддержка существующей CMSMySQL или MariaDB — что уже стоит
Мобильное приложение, локальные данныеSQLite
Аналитика на сотни миллионов строкClickHouse рядом с основной базой
Кэш и сессииRedis рядом с основной базой
Прототип на две неделичто угодно знакомое
Выбор СУБД «потому что модно» или «потому что так у крупной компании» — источник самых дорогих ошибок в архитектуре. Решения, оправданные при миллиардах записей и штате из десяти инженеров эксплуатации, на проекте из трёх разработчиков дают только сложность. Начинайте с PostgreSQL и добавляйте специализированное хранилище тогда, когда упрётесь в измеренное ограничение, — а не заранее.
07

Миграция между СУБД

Перенос базы с одной СУБД на другую — не выгрузка и загрузка данных, а проект. Данные переносятся относительно легко; ломается всё остальное.

Что придётся переделывать

  • Типы данных. Соответствие неполное: tinyint(1)boolean, ENUM, 0000-00-00 как дата в старых базах MySQL.
  • Хранимые процедуры и триггеры. PL/pgSQL и процедурный язык MySQL несовместимы — переписывается вручную.
  • Специфичные функции. Работа с датами, строками, форматированием различается почти полностью.
  • Автоинкремент. AUTO_INCREMENT превращается в IDENTITY, счётчики требуют синхронизации (раздел 7).
  • Регистр имён. Таблица Users в MySQL и users в PostgreSQL — источник массовых правок в коде.
  • Сравнение строк. Если в MySQL сравнение шло без учёта регистра, то в PostgreSQL логика приложения изменится незаметно и повсеместно.
  • Запросы в коде приложения. Диалектные конструкции: LIMIT, ON DUPLICATE KEY, обратные кавычки, конкатенация.
  • Пропущенная целостность. Если исходная база была на MyISAM, внешние ключи там не работали — и данные почти наверняка содержат «висячие» ссылки, которые PostgreSQL откажется принимать.
Существуют инструменты автоматизации: pgloader для переноса из MySQL и SQLite, ora2pg для Oracle. Они переносят структуру и данные, но не бизнес-логику. Реалистичная оценка: данные — 10% работы, приложение — 90%. Обязательный этап, который чаще всего пропускают, — сверка: число строк по каждой таблице, контрольные суммы ключевых показателей, параллельная работа двух систем на боевых данных до переключения.

Ключевые выводы раздела

Запомните главное

  • MariaDB — свободный форк MySQL, созданный после покупки MySQL компанией Oracle
  • В MySQL движок хранения выбирается для каждой таблицы; в PostgreSQL он один
  • MyISAM молча игнорирует внешние ключи и не поддерживает транзакций
  • Настоящий UTF-8 в MySQL называется utf8mb4, а не utf8
  • Строгий режим MySQL появился поздно; в старых конфигурациях данные могут молча портиться
  • DDL транзакционен в PostgreSQL и не транзакционен в MySQL
  • SQLite — библиотека, а не сервер: одна запись за раз, типы по умолчанию не проверяются
  • Специализированные хранилища дополняют реляционную базу, а не заменяют её
  • Выбор СУБД определяется нагрузкой, требованиями к целостности, компетенциями команды и лицензией
  • При миграции данные — 10% работы, переделка приложения — 90%
Практические задания — на учебном портале. Задания, критерии оценивания, сдача работ и оценки преподавателя — в курсе на portal.nevabit.ru. Учётную запись выдаёт преподаватель.
Раздел 11: Индексы и транзакции Раздел 13: Итоговый проект