Общая БД или отдельная БД на арендатор: сравнение по архитектуре, стоимости и задачам. Практический разбор архитектуры SaaS: место в системе, компромиссы, порядок реализации, метрики, риски и критерии готовности.
Матрица сравнения
| Критерий | общая БД | отдельная БД на арендатор (tenant) |
|---|---|---|
| Изоляция | данные, доступы, нагрузка | тот же набор тестов изоляции |
| Изменения | миграция и откат (rollback) | одинаковый сценарий выпуска |
| Эксплуатация | трассировки, оповещения, резервные копии, дежурство | та же эксплуатационная инструкция (runbook) и SLO |
| TCO | инфраструктура и команда | горизонты 1 и 3 года |
Как реализовать
Цель — сравнить варианты на одном профиле арендатора, трафика и требований. Для темы «общая БД или отдельная БД на арендатор» сначала фиксируют тип клиентов, модель арендаторов, критичные данные, SLO и границы ответственности. Затем выбирают самый простой вариант, который проходит тесты изоляции, нагрузочный профиль, сценарий сбоя, миграцию и восстановление. Решение документируют в ADR и проверяют на пилоте.
- Опишите модель арендаторов (tenant model). Клиенты, пользователи, данные, роли и критические пути.
- Зафиксируйте контракты. Идентификация (identity), API, события, биллинг и владение данными.
- Проверьте изоляцию. Негативные тесты, квоты, крупный арендатор и эффект «шумного соседа».
- Проверьте эксплуатацию. Трассировки, нагрузка, миграция, восстановление из резервной копии и дежурство.
- Выпускайте управляемо. Флаги функций (feature flags), канареечный выпуск, подтверждения и быстрый откат.
Практический пример
Пример: продукт на отраслевых данных применяет «общая БД или отдельная БД на арендатор». Команда описывает поток запроса и данных, назначает контекст арендатора, вводит идемпотентность и аудит, задаёт лимиты, собирает метрики по арендаторам, проводит нагрузочный тест и учение по откату. Решение принимают только после проверки изоляции и восстановления.
Метрики приёмки
| Слой | Что проверять | Красный флаг |
|---|---|---|
| Арендатор | тесты изоляции, охват контекста, «шумный сосед» | идентификатор арендатора проверяет только интерфейс |
| API и данные | p95, ошибки, блокировки, миграции, восстановление | нет идемпотентности и отката |
| Безопасность | роли, секреты, аудит, локализация данных | поддержка имеет общий полный доступ |
| Экономика | Критерии: изоляция, задержка, стоимость, миграции, восстановление и сложность команды. Дополнительно измеряют долю запросов с контекстом арендатора, p95 критичных операций, очередь, ошибки по тарифам, время доставки вебхука, стоимость на арендатора, RTO/RPO и скорость безопасного отката. | стоимость не распределяется по арендаторам |
Ограничения и ошибки
Главная ошибка — сравнивать только список функций или цену первого месяца. Для «общая БД или отдельная БД на арендатор» нужно явно отделять продуктовые правила, логику приложения, изоляцию данных и эксплуатацию платформы: у каждого слоя свои контракты, тесты и владельцы.
Чек-лист готовности
- модель арендаторов и владение данными зафиксированы
- контекст арендатора проходит через API, фоновые задания, кеш и телеметрию
- тесты изоляции блокируют утечки
- использование и права по тарифу сверяются с реестром начислений
- проверены миграция и восстановление одного арендатора
- есть SLO, ограничения, откат и инструкция для дежурной смены