Этот документ описывает, как YMatrix поддерживает автоматическое перенос данных в объектное хранилище (например, AWS S3), обеспечивая полностью автоматизированное многоуровневое хранение горячих и холодных данных.
Примечание!
Эта функция поддерживается только для таблиц MARS3.
Сценарии IoT генерируют огромные объемы данных. Хотя YMatrix уделяет особое внимание важности горячих данных (реального времени), она также фокусируется на оптимизации производительности и удобства использования для холодных данных (исторических). Например, транзакционные заказы на платформах электронной коммерции часто запрашиваются в течение 7 дней, но частота доступа резко снижается после истечения срока возврата/возмещения. Тем не менее, эти просроченные заказы по-прежнему занимают значительное количество места в хранилище. В таких случаях снижение затрат на хранение становится критически важным.
Для решения проблемы хранения холодных данных YMatrix разработала функцию деградации данных. Она позволяет хранить горячие и холодные данные на разных носителях: горячие данные остаются на высокопроизводительных носителях, таких как стандартное хранилище, локальные SSD или HDD, а холодные данные автоматически перемещаются в экономичное емкостное хранилище, например, объектное хранилище. Стоимость емкостного хранилища составляет всего 20% от стоимости стандартного хранилища, что значительно снижает общие расходы на хранение. После миграции эти данные бесшовно интегрируются с мощной архитектурой массово параллельной обработки (MPP) YMatrix, обеспечивая эффективное многоуровневое хранение и оптимизацию.
Помимо прямой экономии на стоимости хранения, процесс деградации данных не требует ручного вмешательства, минимизируя операционные и управленческие издержки.
Большинство существующих решений для многоуровневого хранения полагаются на FDW (Foreign Data Wrapper). В отличие от них, YMatrix рассматривает объектное хранилище как равнозначный носитель по сравнению с локальными файловыми системами и интегрирует его непосредственно в движок хранения MARS3. Возможности, доступные для обычных файловых систем, одинаково применимы и к деградированным данным.
Это означает, что многоуровневое хранение MARS3 предлагает большую гибкость:
| Функция | YMatrix (MARS3 Tiered Storage) | Решения на основе FDW |
|---|---|---|
| Поддержка транзакций | Да | Нет |
| Автоматическая миграция холодных данных | Да | Нет |
| Сложность управления | Не требуется ручная настройка | Требует сложных операций |
В этом разделе описан полный рабочий процесс, который поможет вам быстро ознакомиться с процессом и результатами многоуровневого хранения данных.
В качестве примера используется AWS S3.
Сначала войдите в AWS, щелкните свое имя в правом верхнем углу, выберите Security credentials, затем прокрутите вниз и выберите Sign out.
Так как нам нужно перенести холодные данные из YMatrix в бакет AWS S3, выберите Applications running outside of Amazon Web Services.
Создание успешно завершено.
После создания бакета соберите следующую информацию:
https://<your_bucket>.s3.<your_region>.amazonaws.com.cnСоздайте каталог табличного пространства на мастере и сегментах вашего тестового кластера.
$ mkdir -p <tablespace_dir,eg:'/home/mxadmin/test'>
Используйте 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
Используйте 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
Используйте встроенную функцию для ручной миграции всех данных в объектное хранилище:
$ psql <your_database>
=# SELECT matrixts_internal.mars3_degrade('t1'::regclass, -1);
После выполнения вышеуказанной команды все данные из 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, подтверждая успех: доступные данные теперь полностью находятся в объектном хранилище.
| Функция | Описание | Параметры конфигурации |
|---|---|---|
| Режимы аутентификации | Поддерживает два метода аутентификации: Статические 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 |
| Инструменты управления | Инструмент проверки подключения: проверяет соответствие среды требованиям Сканер мусора: обнаруживает и позволяет вручную очищать оставшиеся объекты |
YMatrix поддерживает два режима аутентификации — выберите один:
В быстром старте используются статические учетные данные (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>'
);
Для режима 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 для подробностей о параметрах табличного пространства.
Сначала включите миграцию данных с помощью:
Пример:
$ 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');
Кэширование снижает нагрузку на ввод-вывод при запросе холодных данных из объектного хранилища, повышая производительность. Управляется параметрами:
Пример: установите кэш размером 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 МБ дополнительной памяти. Для оптимальной производительности включите оба кэша.
Перед включением многоуровневого хранения на продакшн-кластере используйте проверщик подключения для проверки совместимости среды.
Инструмент osscheck находится в каталоге $GPHOME/bin.
Шаги:
Создайте шаблон конфигурации:
$ osscheck -g conf
Отредактируйте файл конфигурации
Обязательные поля: 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
$ 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
Обнаруживает неожиданные оставшиеся объекты в объектном хранилище.
Причины появления мусора:
Примечания:
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
......
Поля:
Да. Временной столбец должен быть частью ключа партиционирования и иметь тип date или timestamp. Время используется для определения пригодности данных к холодному хранению. В настоящее время таблицы без временного ключа партиционирования не поддерживают многоуровневое хранение.
Примечание!
Таблицы с несколькими временными столбцами в ключе партиционирования не поддерживаются.
По умолчанию — каждые 60 минут. Можно настроить через mars3.degrade_probe_interval.
Установите и перезагрузите:
$ gpconfig -c mars3.enable_objectstore -v off --skipvalidation
$ mxstop -u
Теоретически — неограниченное количество, но производительность кэша снижается при использовании нескольких табличных пространств. Рекомендуется использовать одно табличное пространство объектного хранилища на кластер.
Да, оно разделяется.
Да, каждый может использоваться независимо. Однако для наилучшей производительности рекомендуется включать оба.
Нет. Дочерние партиции наследуют настройки только при создании или добавлении. Изменения, внесенные в существующую родительскую таблицу с помощью ALTER TABLE, не распространяются на существующие дочерние партиции.
«Дополнительная память» относится к: базовая память + включено автоматическое многоуровневое хранение + одновременные запросы + включены оба кэша.
Примечание!
Это оценка теоретического худшего случая.
Формула:
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