MARS3 Автоматическое многоуровневое хранение

Этот документ описывает, как YMatrix поддерживает автоматическое перенос данных в объектное хранилище (например, AWS S3), обеспечивая полностью автоматизированное многоуровневое хранение горячих и холодных данных.

Примечание!
Эта функция поддерживается только для таблиц MARS3.

1 Обзор

Сценарии IoT генерируют огромные объемы данных. Хотя YMatrix уделяет особое внимание важности горячих данных (реального времени), она также фокусируется на оптимизации производительности и удобства использования для холодных данных (исторических). Например, транзакционные заказы на платформах электронной коммерции часто запрашиваются в течение 7 дней, но частота доступа резко снижается после истечения срока возврата/возмещения. Тем не менее, эти просроченные заказы по-прежнему занимают значительное количество места в хранилище. В таких случаях снижение затрат на хранение становится критически важным.

Для решения проблемы хранения холодных данных YMatrix разработала функцию деградации данных. Она позволяет хранить горячие и холодные данные на разных носителях: горячие данные остаются на высокопроизводительных носителях, таких как стандартное хранилище, локальные SSD или HDD, а холодные данные автоматически перемещаются в экономичное емкостное хранилище, например, объектное хранилище. Стоимость емкостного хранилища составляет всего 20% от стоимости стандартного хранилища, что значительно снижает общие расходы на хранение. После миграции эти данные бесшовно интегрируются с мощной архитектурой массово параллельной обработки (MPP) YMatrix, обеспечивая эффективное многоуровневое хранение и оптимизацию.

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

Большинство существующих решений для многоуровневого хранения полагаются на FDW (Foreign Data Wrapper). В отличие от них, YMatrix рассматривает объектное хранилище как равнозначный носитель по сравнению с локальными файловыми системами и интегрирует его непосредственно в движок хранения MARS3. Возможности, доступные для обычных файловых систем, одинаково применимы и к деградированным данным.

Это означает, что многоуровневое хранение MARS3 предлагает большую гибкость:

Функция YMatrix (MARS3 Tiered Storage) Решения на основе FDW
Поддержка транзакций Да Нет
Автоматическая миграция холодных данных Да Нет
Сложность управления Не требуется ручная настройка Требует сложных операций

2 Быстрый старт

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

2.1 Создание объектного хранилища

В качестве примера используется AWS S3.

Сначала войдите в AWS, щелкните свое имя в правом верхнем углу, выберите Security credentials, затем прокрутите вниз и выберите Sign out. Так как нам нужно перенести холодные данные из YMatrix в бакет AWS S3, выберите Applications running outside of Amazon Web Services. Создание успешно завершено.

После создания бакета соберите следующую информацию:

  • Access Key
  • Secret Key
  • Region
  • Bucket
  • Endpoint: https://<your_bucket>.s3.<your_region>.amazonaws.com.cn

2.2 Инициализация тестового кластера

Создайте каталог табличного пространства на мастере и сегментах вашего тестового кластера.

$ mkdir -p <tablespace_dir,eg:'/home/mxadmin/test'>

2.3 Инициализация многоуровневого хранения

Используйте vi quick.sql, чтобы создать файл с именем quick.sql со следующим содержимым:

-- Create matrixts extension
CREATE EXTENSION IF NOT EXISTS matrixts;

-- Configure system parameters
\!gpconfig -c mars3.enable_objectstore -v ON --skipvalidation
\!gpconfig -c mars3.degrade_min_run_size -v 0 --skipvalidation
\!gpconfig -c mars3.degrade_probe_interval -v 300 --skipvalidation

-- Create tablespace your_tbs
DROP TABLESPACE IF EXISTS your_tbs;

CREATE TABLESPACE your_tbs LOCATION :tablespace_dir
WITH(
        oss_accessid=:oss_accessid,
        oss_secretkey=:oss_secretkey,
        oss_endpoint=:oss_endpoint,
        oss_region=:oss_region,
        oss_bucket=:oss_bucket
);

Замените значения конфигурации в < > (включая < >) и выполните:

$ psql -be -d <your_database> 
                  -v tablespace_dir="'<your_tablespace_dir>'" \
                  -v oss_accessid="'<your_oss_accessid>'" \
                  -v oss_secretkey="'<your_oss_secretkey>'" \
                  -v oss_endpoint="'<your_oss_endpoint>'" \
                  -v oss_region="'<your_oss_region>'" \
                  -v oss_bucket="'<your_oss_bucket>'" \
                  -f quick.sql

Перезагрузите конфигурацию:

$ mxstop -u

2.4 Создание таблицы с включенным многоуровневым хранением

Используйте vi quick2.sql, чтобы создать quick2.sql, содержащий:

\set tname t1
\set tnamestr '''t1'''

-- Create test table; configure migration of data older than 7 days
DROP TABLE IF EXISTS :tname;
CREATE TABLE IF NOT EXISTS
:tname(
   key int,
   value int,
   c3 date)
USING mars3
WITH(ttl_interval='7 d', ttl_space='your_tbs')
DISTRIBUTED BY (key)
ORDER BY (key, value);

-- Insert test data
INSERT INTO :tname SELECT i, i, current_date FROM generate_series(1, 12000000) i;

Запустите quick2.sql:

$ psql -be -d <your_database> -f quick2.sql

2.5 Ручная миграция (только для демонстрации)

Используйте встроенную функцию для ручной миграции всех данных в объектное хранилище:

$ psql <your_database>
=# SELECT matrixts_internal.mars3_degrade('t1'::regclass, -1);

2.6 Проверка успешности миграции

После выполнения вышеуказанной команды все данные из t1 должны быть сохранены в объектном хранилище. Кластер сохраняет только «оболочку» для доступа к данным. Проверьте доступ с помощью:

=# \set tname t1

SELECT * FROM :tname LIMIT 10;
DELETE FROM :tname WHERE key < 50;
SELECT * FROM :tname WHERE key < 50;

Вы также можете проверить консоль объектного хранилища, чтобы подтвердить наличие данных. Попробуйте удалить мигрированные объекты и снова получить к ним доступ:

=# SELECT * FROM :tname WHERE key < 50;

База данных вернет ошибку key not exist, подтверждая успех: доступные данные теперь полностью находятся в объектном хранилище.

3 Полный набор функций

Функция Описание Параметры конфигурации
Режимы аутентификации Поддерживает два метода аутентификации:
Статические AccessId/SecretKey
Динамические AccessId/SecretKey через сервис безопасности (STS)
Параметры создания табличного пространства
Системный параметр mars3.degrade_credential_update_interval
Управление политиками миграции Управляет политиками миграции, включая критерии определения исторических данных и интервал проверки в фоновом режиме ttl_interval/ttl_space/mars3.enable_objectstore/mars3.degrade_probe_interval
Кэширование запросов Повышает эффективность ввода-вывода и производительность запросов за счет кэширования данных, извлеченных из объектного хранилища matrixts.enable_object_cache/mars3.enable_object_prefetch/oss_cache_size
Инструменты управления Инструмент проверки подключения: проверяет соответствие среды требованиям
Сканер мусора: обнаруживает и позволяет вручную очищать оставшиеся объекты

3.1 Подключение к объектному хранилищу с различными режимами аутентификации

YMatrix поддерживает два режима аутентификации — выберите один:

  1. В быстром старте используются статические учетные данные (AWS S3):

    =# CREATE TABLESPACE <your_tablespace> LOCATION '<your_tablespace_dir>'
    WITH(
     oss_accessid='<your_accessid>',
     oss_secretkey='<your_secretkey>',
     oss_endpoint='<your_address>',
     oss_bucket='<your_bucket>'
    );
  2. Для режима STS необходимо предоставить дополнительный скрипт для периодического обновления учетных данных:

-- Create tablespace
CREATE TABLESPACE <your_tablespace> LOCATION '<your_tablespace_dir>'
WITH(
        oss_endpoint='<your_address>',
        oss_bucket='<your_bucket>'
);
-- Script to update oss_sessiontoken/oss_accessid/oss_secretkey regularly
DB="postgres"
SPACE="tbs"

RES=$(aws sts get-session-token)
if [ $? != 0 ]
then
        echo "get credentials fail!"
        exit 1
fi

ak=$(echo "${RES}"|jq -r .Credentials.AccessKeyId)
sk=$(echo "${RES}"|jq -r .Credentials.SecretAccessKey)
token=$(echo "${RES}"|jq -r .Credentials.SessionToken)

if [ "${ak}" == "" ]
then
        echo "AccessKeyId is empty!"
        exit 1
fi

if [ "${sk}" == "" ]
then
        echo "SecretAccessKey is empty!"
        exit 1
fi

if [ "${token}" == "" ]
then
        echo "SessionToken is empty!"
        exit 1
fi

echo $ak
echo $sk
echo $token

psql -d "${DB}" -c "ALTER TABLESPACE ${SPACE} SET (oss_accessid='${ak}', oss_secretkey='${sk}', oss_sessiontoken='${token}');"
if [ $? != 0 ]
then
        echo "alter tablespace fail!"
        exit 1
fi

Чтобы запланировать периодическое обновление учетных данных, задайте:

Примечание!
См. CREATE TABLESPACE для подробностей о параметрах табличного пространства.

3.2 Управление политиками миграции

Сначала включите миграцию данных с помощью:

Пример:

$ gpconfig -c mars3.enable_objectstore -v ON --skipvalidation
$ gpconfig -c mars3.degrade_probe_interval -v 300 --skipvalidation
$ mxstop -u

Задайте политику миграции при создании таблицы с помощью ttl_interval и ttl_space:

=# CREATE TABLE <your_table> (
  ...
) 
...
WITH (ttl_interval='<your_interval>', ttl_space='<your_tablebspace>')
...
;

Измените политику для существующих таблиц:

=# ALTER TABLE <your_table> SET (ttl_interval='14d');

3.3 Кэширование запросов

Кэширование снижает нагрузку на ввод-вывод при запросе холодных данных из объектного хранилища, повышая производительность. Управляется параметрами:

Пример: установите кэш размером 10 000 МБ на табличное пространство:

=# CREATE TABLESPACE <your_tablebspace> LOCATION <your_tablespace_dir>
WITH(
    ...
    oss_cache_size=10000,
    ...
);

Включите кэширование в сессии:

=# SET matrixts.enable_object_cache TO ON;
=# SET mars3.enable_object_prefetch TO ON;

Примечание!
Каждый фоновый процесс требует 64 МБ памяти для кэша файлов и 64 МБ для кэша памяти. Запрос с 10 сегментами может потребовать до 1280 МБ дополнительной памяти. Для оптимальной производительности включите оба кэша.

3.4 Инструменты управления

3.4.1 Проверка подключения

Перед включением многоуровневого хранения на продакшн-кластере используйте проверщик подключения для проверки совместимости среды.

Инструмент osscheck находится в каталоге $GPHOME/bin.

Шаги:

  1. Создайте шаблон конфигурации:

    $ osscheck -g conf
  2. Отредактируйте файл конфигурации

Обязательные поля: oss_accessid, oss_secretkey, oss_endpoint, oss_bucket
Для STS: включите oss_sessiontoken
Необязательный префикс: oss_keyprefix

Шаблон (замените значения в < >, включая < >):

oss_accessid='<your_oss_accessid>'
oss_secretkey='<your_oss_secretkey>'
oss_sessiontoken='<your_oss_sessiontoken>'
oss_endpoint='<your_oss_endpoint>'
oss_region='<your_oss_region>'
oss_bucket='<your_oss_bucket>'
oss_keyprefix='<your_oss_keyprefix>'
oss_retry_mode=default
oss_upload_partsize=5
oss_upload_parallelnum=3
oss_retry_times=3
oss_timeout=3000
  1. Запустите проверку подключения:
    $ osscheck -t conf
    put object success
    get object success
    list object success
    delete object success

Успешный результат показывает зеленый success. Ошибка показывает красный fail:

$ osscheck -t conf.template
ERROR: InvalidAccessKeyId: The Access Key Id you provided does not exist in our records.
put object fail

3.4.2 Сканер мусора

Обнаруживает неожиданные оставшиеся объекты в объектном хранилище.

Причины появления мусора:

  • Неудачное удаление объектных данных при удалении объектных таблиц
  • Прямое удаление базы данных или кластера без удаления связанных объектных данных
  • Человеческие ошибки (например, забытые тестовые файлы)

Примечания:

  • Использует matrixts_internal.oss_junkobjects() для запроса каталога
  • Требует конфигурации табличного пространства; сканирует только в пределах текущего пути oss_bucket/oss_keyprefix/
  • Убедитесь, что этот путь выделен исключительно для текущего кластера

Использование:

=# CREATE EXTENSION IF NOT EXISTS matrixts;
=# SELECT * FROM matrixts_internal.oss_junkobjects('<your_tablespace>');
                 key                 |       lastmodify       |   size
-------------------------------------+------------------------+----------
 49948/2/52751/4/0                   | 2023-10-19 16:00:14+08 |    38964
 49948/2/53021/1/0                   | 2023-10-19 16:04:55+08 |    38964
 16384/2/158581/3/0                  | 2023-09-03 13:16:26+08 |     4080
 16384/2/158581/p2                   | 2023-09-03 15:18:36+08 |        5
 16384/2/202151/3/0                  | 2023-09-21 16:22:09+08 |       80
 49948/1/52751/4/0                   | 2023-10-19 16:00:14+08 |    40620
 49948/1/52861/1/0                   | 2023-10-19 16:01:34+08 |   240000
 49948/1/53021/1/0                   | 2023-10-19 16:04:55+08 |    40620
 49948/1/53038/1/0                   | 2023-10-19 16:05:10+08 |   120000
 16384/1/158581/3/0                  | 2023-09-03 13:16:26+08 |     3864
 16384/1/202151/3/0                  | 2023-09-21 16:22:09+08 |       20
 49948/0/52751/4/0                   | 2023-10-19 16:00:14+08 |    40416
 49948/0/53021/1/0                   | 2023-10-19 16:04:55+08 |    40416
 ......

Поля:

  • key: Ключ оставшегося объекта
  • lastmodify: Временная метка последнего изменения
  • size: Размер объекта в байтах

Часто задаваемые вопросы

  1. Обязательно ли наличие временного столбца в таблице для многоуровневого хранения?

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

Примечание!
Таблицы с несколькими временными столбцами в ключе партиционирования не поддерживаются.

  1. Как часто проверяется миграция?

По умолчанию — каждые 60 минут. Можно настроить через mars3.degrade_probe_interval.

  1. Как временно отключить автоматическую миграцию?

Установите и перезагрузите:

$ gpconfig -c mars3.enable_objectstore -v off --skipvalidation
$ mxstop -u
  1. Сколько табличных пространств может поддерживать один кластер?

Теоретически — неограниченное количество, но производительность кэша снижается при использовании нескольких табличных пространств. Рекомендуется использовать одно табличное пространство объектного хранилища на кластер.

  1. Разделяется ли табличное пространство объектного хранилища между базами данных?

Да, оно разделяется.

  1. Можно ли включить только кэш памяти или только кэш файлов?

Да, каждый может использоваться независимо. Однако для наилучшей производительности рекомендуется включать оба.

  1. Наследуются ли настройки партиционированной таблицы дочерними партициями?

Нет. Дочерние партиции наследуют настройки только при создании или добавлении. Изменения, внесенные в существующую родительскую таблицу с помощью ALTER TABLE, не распространяются на существующие дочерние партиции.

  1. Дополнительное использование памяти при многоуровневом хранении

«Дополнительная память» относится к: базовая память + включено автоматическое многоуровневое хранение + одновременные запросы + включены оба кэша.

Примечание!
Это оценка теоретического худшего случая.

Формула:

Additional memory = 
  Concurrent client queries × 
  Segments per node × 
  Average tables scanned per query × 
  (Parallel Workers + 1) × 
  (64MB + 64MB + 10MB) +
  Number of partitioned tables × 
  Segments per node × 
  64MB