Настройка базы данных приложения Glarus BI¶

База данных приложения — это место, где Glarus BI хранит информацию о пользовательских учётных записях, запросах, дашбордах и любых других данных, необходимых для работы приложения Glarus BI. Эта база данных приложения отличается от базы данных, где вы храните свои данные, также известной как ваше хранилище данных. Для подключения к вашему хранилищу данных см. Подключение к поддерживаемой базе данных.

Для промышленной эксплуатации мы рекомендуем использовать PostgreSQL в качестве базы данных приложения Glarus BI.

PostgreSQL (рекомендуется для промышленной эксплуатации)
MySQL (также подходит для промышленной эксплуатации)
H2 (используется по умолчанию для локальных демонстраций).

Предупреждение

Избегайте использования H2 в промышленной эксплуатации.

Glarus BI будет считывать информацию о конфигурации подключения при запуске приложения. Вы не можете изменить базу данных приложения во время работы приложения.

Где хранятся данные¶

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

Хранилище	Технология и протокол	Какие данные
База данных приложения	PostgreSQL, подключение по JDBC; H2 — для пробного запуска	Пользователи, сессии, метаданные подключений, вопросы, модели, дашборды, коллекции, ревизии контента, журнал аудита и кэш результатов запросов. Для промышленной эксплуатации рекомендуется PostgreSQL; другие поддерживаемые варианты описаны ниже на этой странице.
Общий кэш и хранилище импортированных таблиц	ClickHouse, JDBC-драйвер 0.8.4 через HTTP-интерфейс	Таблицы расширенного кэша моделей, результаты ETL в режиме «Общий кэш», импортированные Excel при назначении подключения хранилищем Excel. Обычное кэширование моделей и ETL в режиме «Исходная БД» используют соответствующую исходную базу, а не автоматически ClickHouse.
Файловая система узла	Локальные каталоги сервера	Драйверы-плагины в `MB_PLUGINS_DIR`; файлы журналов, если они включены настройками Log4j2 или средствами запуска; временные ZIP-архивы переноса коллекций, промежуточные файлы XLSX и вложения рассылок.

Кэш результатов запросов хранится в базе данных приложения при MB_QP_CACHE_BACKEND=db. Параметр MB_QUERY_CACHING_MAX_KB ограничивает размер сериализованных строк одного результата до сжатия; значение по умолчанию — 2000 КБ. Это не ограничение суммарного размера всех записей кэша и не размер таблиц ClickHouse.

Политика хранения таблиц аудита, истории выполнения запросов и просмотров управляется MB_AUDIT_MAX_RETENTION_DAYS: по умолчанию 720 дней. Значения от 1 до 29 трактуются как 30 дней; 0 означает хранение без ограничения срока. Эта настройка не задаёт общий срок хранения всех данных приложения или файлов на диске.

Журнал приложения по умолчанию направляется в stdout через Log4j2. Запись в файлы и их ротация зависят от конфигурации развёртывания. См. «Журнал Glarus BI».

Формирование и хранение выгрузок¶

CSV и XLSX из результатов запроса передаются клиенту через HTTP-ответ. CSV формируется потоково; при создании XLSX могут использоваться временные файлы и буферы, в том числе для больших таблиц и сводных представлений. Потоковый HTTP-ответ не означает отсутствие промежуточных файлов на сервере.
PDF и PPTX дашборда формируются в браузере и скачиваются на устройство пользователя. Это не серверный поток экспорта таблицы.
CSV и XLSX во вложениях рассылок предварительно создаются как временные файлы на узле. Они помечаются для удаления при штатном завершении JVM; немедленное удаление после отправки письма не гарантируется.
Перенос коллекций использует ZIP-файлы и рабочие каталоги во временном каталоге Java. Рабочий каталог импорта очищается после обработки; немедленное удаление ZIP-файла экспорта после скачивания не гарантируется. Очистку временного каталога учитывают в эксплуатации узла.

Отдельное объектное хранилище S3 или MinIO для перечисленных внутренних хранилищ Glarus BI не требуется. Обычные выгрузки не сохраняются приложением в постоянной библиотеке готовых файлов; это не исключает временные файлы на узле, кэш результатов в базе или сохранение скачанного файла пользователем.

PostgreSQL¶

Мы рекомендуем использовать PostgreSQL для базы данных приложения Glarus BI. Glarus BI поддерживает версии PostgreSQL от самой старой поддерживаемой до последней стабильной. См. версии PostgreSQL (postgresql.org).

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

export MB_DB_TYPE=postgres
export MB_DB_DBNAME=metabase
export MB_DB_PORT=5432
export MB_DB_USER=<username>
export MB_DB_PASS=<password>
export MB_DB_HOST=localhost
java --add-opens java.base/java.nio=ALL-UNNAMED -jar metabase.jar

Glarus BI не создаст базу данных Postgres для вас. Пример команды для создания базы данных:

createdb --encoding=UTF8 -e metabase

Если у вас есть дополнительные параметры, Glarus BI также поддерживает предоставление полной строки подключения JDBC:

export MB_DB_CONNECTION_URI="jdbc:postgresql://localhost:5432/metabase?user=<username>&password=<password>"
java --add-opens java.base/java.nio=ALL-UNNAMED -jar metabase.jar

Если вы хотите передать URI подключения, учётные данные пользователя и пароль отдельно от строки подключения JDBC (полезно, если пароль содержит специальные символы), вы можете использовать переменную окружения MB_DB_CONNECTION_URI (см. "Переменные окружения") в сочетании с переменными MB_DB_USER и MB_DB_PASS:

export MB_DB_CONNECTION_URI="jdbc:postgresql://localhost:5432/metabase"
export MB_DB_USER=<username>
export MB_DB_PASS=<password>
java --add-opens java.base/java.nio=ALL-UNNAMED -jar metabase.jar

MySQL или MariaDB¶

Мы рекомендуем PostgreSQL, но вы также можете использовать MySQL или MariaDB.

Минимальная рекомендуемая версия — MySQL 8.0.17 или MariaDB 10.2.2. Набор символов utf8mb4 обязателен.

Мы не поддерживаем ApsaraDB MySQL. Вместо этого вы можете использовать ApsaraDB PostgreSQL.

Вы можете изменить базу данных приложения для использования MySQL с помощью переменных окружения следующим образом:

export MB_DB_TYPE=mysql
export MB_DB_DBNAME=metabase
export MB_DB_PORT=3306
export MB_DB_USER=<username>
export MB_DB_PASS=<password>
export MB_DB_HOST=localhost
java --add-opens java.base/java.nio=ALL-UNNAMED -jar metabase.jar

Glarus BI не создаст эту базу данных для вас. Пример SQL-запроса для создания базы данных:

CREATE DATABASE metabase CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Следующая команда укажет Glarus BI искать базу данных приложения, используя предоставленную информацию о подключении MySQL. Glarus BI также поддерживает предоставление полной строки подключения JDBC при наличии дополнительных параметров:

export MB_DB_CONNECTION_URI="jdbc:mysql://localhost:3306/metabase?user=<username>&password=<password>"
java --add-opens java.base/java.nio=ALL-UNNAMED -jar metabase.jar

Как и с Postgres, MB_DB_CONNECTION_URI также можно использовать в сочетании с MB_DB_USER и/или MB_DB_PASS, а если вы хотите передать один или оба параметра отдельно от остальной части строки подключения JDBC:

export MB_DB_CONNECTION_URI="jdbc:mysql://localhost:5432/metabase"
export MB_DB_USER=<username>
export MB_DB_PASS=<password>
java --add-opens java.base/java.nio=ALL-UNNAMED -jar metabase.jar

База данных приложения H2¶

Предупреждение

Для промышленной эксплуатации Glarus BI мы рекомендуем заменить базу данных H2 по умолчанию на PostgreSQL. Postgres обеспечивает более высокую производительность и надёжность.

По умолчанию Glarus BI поставляется с базой данных H2, чтобы вам было легко демонстрировать Glarus BI на локальной машине. Избегайте использования этой базы данных по умолчанию в промышленной эксплуатации.

Если при запуске Glarus BI вы не предоставите переменные окружения, которые определяют детали подключения к промышленной базе данных, Glarus BI попытается создать новую базу данных H2 в том же каталоге, что и JAR-файл Glarus BI.

H2 — это файловая база данных, и вы можете увидеть эти файлы базы данных H2 в консоли:

ls metabase.*

Вы должны увидеть следующие файлы:

metabase.db.h2.db  # Или metabase.db.mv.db в зависимости от того, когда вы впервые начали использовать Metabase.
metabase.db.trace.db

Если вы хотите использовать файл базы данных H2 в определённом каталоге, используйте переменные окружения MB_DB_TYPE и MB_DB_FILE:

export MB_DB_TYPE=h2
export MB_DB_FILE=/the/path/to/my/h2.db
java --add-opens java.base/java.nio=ALL-UNNAMED -jar metabase.jar

Обратите внимание, что H2 автоматически добавляет .mv.db или .h2.db к указанному вами пути. Не указывайте эти двойные расширения в значении переменной окружения. Другими словами, MB_DB_FILE должен быть чем-то вроде /path/to/metabase.db, а не /path/to/metabase.db.mv.db (даже несмотря на то, что последний — это файл, который Glarus BI будет создавать).

Миграция с H2¶

Если вы начали использовать базу данных H2 по умолчанию, но хотите сохранить созданный контент и перейти на промышленную базу данных приложения, Glarus BI предоставляет ограниченную поддержку для миграции с H2 на PostgreSQL.

Обновление с версии ниже 0.38¶

Если вы обновляетесь с версии ниже 0.38, обратите внимание, что в версии 0.38 было удалено использование NonValidatingFactory PostgreSQL для проверки SSL. Возможно, вы можете столкнуться с ошибкой либо при запуске (если вы используете базу данных приложения PostgreSQL), либо при запросе к хранилищу данных PostgreSQL.

Вы можете решить эту проблему одним из двух способов:

Настроить подключение PostgreSQL для использования проверки SSL-сертификата.
Вручную включить NonValidatingFactory.

Предупреждение

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

Способ настройки подключения зависит от того, используете вы Postgres в качестве базы данных приложения Glarus BI или в качестве хранилища данных, подключенного к Glarus BI.

Проверка SSL-сертификата для баз данных приложения Postgres¶

Для использования проверки SSL-сертификата вам необходимо использовать переменную окружения MB_DB_CONNECTION_URI для настройки подключения к базе данных. Вот пример:

export MB_DB_CONNECTION_URI="postgres://localhost:5432/metabase?user=<username>&password=<password>&sslmode=verify-ca&sslrootcert=<path to CA root or intermediate root certificate>"

Если вы не можете включить проверку сертификата, включите NonValidatingFactory для базы данных вашего приложения:

export MB_DB_CONNECTION_URI="postgres://localhost:5432/metabase?user=<username>&password=<password>&ssl=true&sslfactory=org.postgresql.ssl.NonValidatingFactory"

Проверка SSL-сертификата для баз данных хранилища данных Postgres¶

Добавьте следующее в конец строки подключения JDBC для вашей базы данных:

&sslmode=verify-ca&sslrootcert=<path to CA root or intermediate root certificate>

Если это не срабатывает, вы можете включить NonValidatingFactory, добавив следующее в конец URI подключения для вашей базы данных:

&ssl=true&sslfactory=org.postgresql.ssl.NonValidatingFactory

Для получения дополнительных опций для дальнейшей настройки параметров SSL-подключения см. документацию клиента PostgreSQL SSL.

Дополнительная информация¶

Переменные окружения