База workfloy n8n

База данных workflow n8n: архитектура, управление и практическое применение

n8n — это платформа с открытым исходным кодом для оркестрации workflow (рабочих процессов), которая использует визуальный редактор на основе узлов. В отличие от многих других инструментов автоматизации, n8n может хранить данные о workflow, их выполнении, учетных данных и прочей служебной информации в различных типах баз данных. Это обеспечивает гибкость, переносимость и масштабируемость развертывания. Понимание архитектуры и принципов работы с базой данных n8n критически важно для администрирования, резервного copying, миграции и отладки сложных автоматизаций.

Архитектура хранения данных в n8n

Данные в n8n делятся на несколько ключевых категорий, каждая из которых хранится в определенных таблицах или коллекциях базы данных. Выбор типа базы данных влияет на производительность и возможности развертывания.

• Метаданные workflow: Структура самого workflow — узлы, их связи, позиции на холсте, настройки, статические данные. Это определение процесса.
• Данные выполнения (Execution Data): Детальная информация о каждом запуске workflow — входные и выходные данные каждого узла, статус выполнения (успех, ошибка), временные метки. Это исторические данные.
• Учетные данные (Credentials): Зашифрованные данные для подключения к внешним сервисам (API-ключи, токены, логины и пароли).
• Служебные данные: Настройки инстанса n8n, информация о пользователях, статистика, переменные окружения.

Поддерживаемые базы данных и их выбор

n8n поддерживает несколько систем управления базами данных (СУБД), что позволяет адаптировать его под различные инфраструктурные требования.

Тип базы данных	Рекомендуемое использование	Ключевые особенности
SQLite (по умолчанию)	Разработка, тестирование, персональное использование, небольшие развертывания.	Встроенная, не требует отдельного сервера. Все данные в одном файле (например, `database.sqlite`). Простота настройки, но ограниченная производительность и масштабируемость при высокой нагрузке.
PostgreSQL	Производственные среды, высоконагруженные системы, требующие надежности и масштабируемости.	Наиболее рекомендуемая СУБД для продакшена. Поддерживает сложные запросы, обладает высокой устойчивостью к сбоям, эффективно управляет большими объемами данных выполнения.
MySQL / MariaDB	Производственные среды, где уже используется стек MySQL.	Хорошая альтернатива PostgreSQL. Полностью поддерживается n8n, но некоторые пользователи отмечают лучшую интеграцию с PostgreSQL.
SQL Server	Корпоративные среды, интегрированные в экосистему Microsoft.	Официальная поддержка для пользователей, стандартизированных на SQL Server.

Структура ключевых таблиц в базе данных

При использовании SQL-баз (PostgreSQL, MySQL) данные организованы в логические таблицы. Понимание их назначения упрощает администрирование.

Название таблицы	Назначение	Важные поля
`workflow_entity`	Хранение основных метаданных workflow.	`id`, `name`, `active` (активен ли workflow), `nodes` (JSON-структура узлов), `connections` (JSON-структура связей), `versionId`.
`execution_entity`	Хранение данных о выполнении workflow.	`id`, `workflowId` (ссылка на workflow), `data` (JSON с входными/выходными данными), `finished` (завершен ли запуск), `mode` (триггер), `startedAt`, `stoppedAt`, `status` (`success`, `error`, `waiting`).
`credentials_entity`	Хранение зашифрованных учетных данных.	`id`, `name`, `type` (например, `httpBasicAuth`, `slackApi`), `data` (зашифрованные данные), `projectId`.
`tag_entity`	Метки (теги) для workflow.	`id`, `name`.
`workflows_tags`	Связь многие-ко-многим между workflow и тегами.	`workflowId`, `tagId`.
`installed_packages`	Информация об установленных пользовательских пакетах узлов.	`packageName`, `installedVersion`, `authorName`.
`user`	Данные пользователей (для многопользовательского режима).	`id`, `email`, `firstName`, `lastName`, `password` (хэш).

Управление данными выполнения (Execution Data)

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

• Политики хранения: В настройках n8n (`EXECUTIONS_DATA_PRUNE` или через интерфейс администратора) можно задать правила:
  • Срок хранения (TTL): Автоматическое удаление данных выполнения старше определенного количества часов или дней.
  • Сохранять только ошибки: Удалять данные об успешных выполнениях, сохраняя только информацию о неудачных запусках для отладки.
  • Ограничение количества: Хранение только N последних выполнений для каждого workflow.
• Ручная очистка: Через интерфейс в разделе «Executions» можно вручную удалять отдельные записи или массово очищать историю.
• Резервное копирование и экспорт: Отдельные успешные выполнения можно экспортировать в виде JSON-файла для последующего анализа или импорта (например, для воссоздания контекста ошибки).

Миграция и резервное копирование базы данных

Надежная стратегия работы с данными n8n включает регулярное резервное копирование и возможность миграции между СУБД.

• Резервное копирование SQLite: Достаточно скопировать файл `database.sqlite` в безопасное место. Рекомендуется делать это при остановленном экземпляре n8n для гарантии целостности.
• Резервное копирование PostgreSQL/MySQL: Использование стандартных утилит СУБД: `pg_dump` для PostgreSQL и `mysqldump` для MySQL. Эти дампы можно использовать для восстановления или переноса данных.
• Миграция между базами данных: Стандартный путь — использование встроенной функциональности n8n. Процесс включает экспорт всех workflow, учетных данных и настроек через интерфейс (или с помощью CLI-команд), настройку нового экземпляра n8n с целевой СУБД и последующий импорт данных. Для прямого переноса данных между разными СУБД требуется конвертация схемы и данных, что является сложной задачей.

Безопасность и шифрование

Безопасность данных, особенно учетных credentials, является приоритетом в n8n.

• Шифрование учетных данных: Все учетные данные шифруются с использованием секретного ключа (`N8N_ENCRYPTION_KEY`). Этот ключ должен быть установлен через переменную окружения и храниться в тайне. Без правильного ключа существующие учетные данные становятся нечитаемыми.
• Безопасность соединения с БД: Рекомендуется использовать SSL/TLS-шифрование для соединения между n8n и внешней базой данных (PostgreSQL, MySQL) в производственных средах.
• Разграничение доступа: В многопользовательском режиме (n8n Paid) реализована модель проектов, которая изолирует workflow и учетные данные между разными командами или пользователями на уровне базы данных.

Оптимизация производительности базы данных

С ростом количества и сложности workflow производительность базы данных становится ключевым фактором.

• Индексация: n8n автоматически создает базовые индексы для первичных и внешних ключей. Для больших таблиц `execution_entity` может потребоваться создание дополнительных индексов по полям `workflowId`, `finished`, `startedAt` для ускорения запросов истории.
• Отдельный диск для БД: Размещение файлов или тома базы данных на высокопроизводительном SSD-диске, отдельном от системных файлов.
• Выделение ресурсов: Для PostgreSQL/MySQL необходимо корректно настроить параметры памяти (`shared_buffers`, `innodb_buffer_pool_size`) в соответствии с доступными ресурсами сервера.
• Регулярная очистка: Включение и настройка политик автоматического удаления старых данных выполнения для предотвращения раздувания таблиц.

Ответы на часто задаваемые вопросы (FAQ)

Где физически находится база данных SQLite по умолчанию?

Путь к файлу зависит от операционной системы и способа установки. При стандартной установке через npm файл `database.sqlite` обычно находится в папке `~/.n8n` (домашняя директория пользователя). В Docker-контейнере расположение зависит от смонтированных томов; часто он находится по пути `/home/node/.n8n/database.sqlite`.

Как переключиться с SQLite на PostgreSQL?

Необходимо:
1. Создать базу данных и пользователя в PostgreSQL.
2. Экспортировать все данные из текущего экземпляра n8n (Workflows, Credentials).
3. Остановить n8n.
4. Установить переменные окружения для нового подключения: `DB_TYPE=postgresdb`, `DB_POSTGRESDB_DATABASE=your_db_name`, `DB_POSTGRESDB_HOST=your_host`, `DB_POSTGRESDB_USER=your_user`, `DB_POSTGRESDB_PASSWORD=your_password`.
5. Запустить n8n. Он инициализирует пустые таблицы.
6. Импортировать ранее экспортированные данные.

Как сделать резервную копию только workflow, без данных выполнения?

Через веб-интерфейс: перейдите в раздел «Workflows», выберите нужные workflow (или все) и используйте функцию «Export». Вы получите JSON-файл, содержащий только определения workflow. Для автоматизации можно использовать n8n API или CLI-команды.

Почему база данных так быстро растет в размере?

Основная причина — накопление данных выполнения (Execution Data), особенно если workflow обрабатывают большие объемы данных (файлы, вложения, крупные JSON-объекты) и политики хранения не настроены. Необходимо немедленно настроить `EXECUTIONS_DATA_PRUNE` для удаления ненужных данных и проверить, не сохраняются ли в истории выполнения избыточные данные.

Можно ли использовать n8n без внешней базы данных в продакшене?

Использование встроенной SQLite для производственных сред не рекомендуется. Она не обеспечивает достаточной отказоустойчивости (файл может быть поврежден), производительности при параллельном доступе и сложности в масштабировании (невозможно запустить несколько экземпляров n8n на одном файле). Для продакшена обязательна внешняя СУБД: PostgreSQL или MySQL.

Как восстановить данные после сбоя?

Процедура зависит от типа базы данных:
Для SQLite: Заменить поврежденный файл `database.sqlite` на резервную копию. Убедиться, что n8n остановлен.
Для PostgreSQL/MySQL: Восстановить базу данных из дампа, созданного `pg_dump`/`mysqldump`. Также всегда следует иметь актуальные экспорты workflow и учетных данных через встроенные механизмы n8n как дополнительный уровень защиты.

Как шифруются учетные данные и что делать, если потерян ключ шифрования?

Учетные данные шифруются с использованием алгоритма AES-256-GCM. Ключ шифрования задается переменной окружения `N8N_ENCRYPTION_KEY`. Если этот ключ утерян или изменен, все ранее сохраненные учетные данные станут нечитаемыми для n8n. Их необходимо будет ввести заново. Поэтому ключ шифрования должен надежно храниться и включаться в резервные копии конфигурации.