В этом разделе описываются различные клиентские инструменты, которые вы можете использовать для подключения к RT.Warehouse, а как установить подключение.
Пользователи могут подключаться к RT.Warehouse с помощью клиентской программы, совместимой с PostgreSQL, например, psql. Пользователи и администраторы всегда подключаются к RT.Warehouse через машину мастера, сегменты не могут принимать клиентские соединения.
Чтобы установить соединение с сервером мастера RT.Warehouse, вам необходимо знать следующую информацию о подключении и соответствующим образом настроить клиентскую программу.
Таблица 1— Параметры подключения
Параметр подключения
Описание
Переменная окружения
Имя приложения
Имя приложения, которое подключается к базе данных. Значение по умолчанию, содержащееся в параметре подключения application_name, —psql.
$PGAPPNAME
Имя базы данных
Имя базы данных, к которой вы хотите подключиться. Для вновь инициализированной системы используйте базу данных postgres для первого подключения.
$PGDATABASE
Имя хоста
Имя хоста сервера мастера RT.Warehouse. Хост по умолчанию — это локальный хост.
$PGHOST
Порт
Номер порта, на котором работает инстанс мастера RT.Warehouse. По умолчанию 5432.
$PGPORT
Имя пользователя
Имя пользователя (роли) базы данных для подключения. Это не обязательно имя пользователя вашей ОС. Если вы не уверены, какое имя пользователя базы данных у вас, обратитесь к администратору RT.Warehouse. Обратите внимание, что каждая система RT.Warehouse имеет одну учётную запись суперпользователя, которая создается автоматически во время инициализации. Эта учётная запись имеет то же имя, что и имя пользователя ОС, инициализировавшего систему RT.Warehouse (обычно gpadmin).
Пользователи могут подключаться к RT.Warehouse с помощью различных клиентских приложений:
Ряд клиентских приложений RT.Warehouse входит в комплект поставки RT.Warehouse. Клиентское приложение psql предоставляет интерактивный интерфейс командной строки для RT.Warehouse.
Используя стандартные интерфейсы приложений баз данных, такие как ODBC и JDBC, пользователи могут создавать свои собственные клиентские приложения, которые взаимодействуют с RT.Warehouse.
Большинство клиентских инструментов, использующих стандартные интерфейсы базы данных, такие как ODBC и JDBC, можно настроить для подключения к RT.Warehouse.
RT.Warehouse поставляется с установленным рядом клиентских служебных приложений, расположенных в каталоге $GPHOME/bin вашей установки хоста мастера RT.Warehouse. Ниже приведены наиболее часто используемые клиентские служебные приложения:
Таблица 2— Часто используемые клиентские приложения
Имя
Использование
createdb
Создание новой базы данных.
createlang
Определение нового процедурного языка.
createuser
Определение новой роли базы данных.
dropdb
Удаление базы данных.
droplang
Удаление процедурного языка.
dropuser
Удаление роли.
psql
Интерактивный терминал PostgreSQL.
reindexdb
Переиндексация базы данных.
vacuumdb
Сбор мусора и анализ базы данных.
Примечание.
createlang и droplang устарели и могут быть удалены в будущем выпуске.
При использовании этих клиентских приложений вы должны подключиться к базе данных через инстанс мастера RT.Warehouse. Вам нужно будет знать имя вашей целевой базы данных, имя хоста и номер порта мастера, а также имя пользователя базы данных для подключения. Эта информация может быть предоставлена в командной строке с помощью параметров -d, -h, -p и-U соответственно. Если найден аргумент, не принадлежащий ни одному параметру, он будет сначала интерпретирован как имя базы данных.
Все эти параметры имеют значения по умолчанию, которые будут использоваться, если параметр не указан. Хост по умолчанию — это локальный хост. Номер порта по умолчанию — 5432. Имя пользователя по умолчанию — это имя пользователя вашей ОС, как и имя базы данных по умолчанию. Обратите внимание, что имена пользователей ОС и имена пользователей RT.Warehouse не обязательно совпадают.
Если значения по умолчанию неверны, вы можете установить для переменных окружения PGDATABASE, PGHOST, PGPORT и PGUSER соответствующие значения или использовать файл psql ~/.pgpass для хранения часто используемых паролей.
В зависимости от используемых значений по умолчанию или установленных вами переменных окружения следующие примеры показывают, как получить доступ к базе данных через psql:
Если пользовательская база данных ещё не создана, вы можете получить доступ к системе, подключившись к базе данных postgres. Например:
$ psql postgres
После подключения к базе данных psql отображает подсказку с именем базы данных, к которой в настоящее время подключён psql, за которым следует строка => (или =#, если вы являетесь суперпользователем базы данных). Например:
gpdatabase =>
В командной строке вы можете ввести команды SQL. Команда SQL должна заканчиваться на ; (точка с запятой) для отправки на сервер и выполнения. Например:
=> SELECT * FROM mytable;
¶ 2. ХРАНЕНИЕ ИНФОРМАЦИИ И ОСНОВНЫЕ ОПЕРАЦИИ В RT.WAREHOUSE
¶ 2.1 Сравнение хранилищ типа “heap” и “append-optimized”
Существуют два типа хранения данных в таблицах — heap и append-optimized.
Хранение типа heap следует использовать для таблиц и партиций, которые получают итеративные пакетные, однострочные, а также синхронные операции UPDATE, DELETE и INSERT.
Хранение append-optimized следует использовать для таблиц и партиций, которые редко обновляются после начальной загрузки и в которых последующие вставки выполняются только в больших пакетных операциях.
Внимание.
Никогда не выполняйте однострочные операции INSERT, UPDATE или DELETE в таблицах типа append-optimized.
Внимание.
Никогда не выполняйте параллельные пакетные операции UPDATE или DELETE в append-optimized (это не касается одновременных операций вставки INSERT).
Построчное хранение необходимо использовать для рабочих нагрузок с итеративными транзакциями, в которых требуются обновления и частые вставки. Также его следует использовать для общих целей или в случае, если рабочие нагрузки носят смешанный характер.
Хранить данные по столбцам стоит в том случае, когда запросы необходимы для поиска узкого спектра данных. Также хранение по столбцам подходит при наличии отдельных столбцов, которые регулярно обновляются без изменения других столбцов в строке.
Для улучшения ввода-вывода в системе следует использовать сжатие для append-optimized таблиц. Параметры сжатия столбцов следует установить на уровне, на котором находятся данные. Рекомендуется балансировать более высокий уровень сжатия с временем и циклами ЦП, необходимыми для сжатия и распаковки данных.
Для корректного распределения данных необходимо следовать рекомендациям:
Задать значения столбца или выбрать случайное распределение для всех таблиц. Не использовать значение по умолчанию.
Использовать один столбец, который будет равномерно распределять данные по всем сегментам.
Не распределять на столбцы, которые будут использоваться при запросе WHERE.
Не распределять на даты или временные метки.
Никогда не распределять и не разделять таблицы в одном столбце.
Достичь локальных объединений для значительного повышения производительности, распределив их в одном столбце для больших таблиц, которые обычно объединяются вместе.
Убедиться, что данные равномерно распределены после начальной загрузки и после инкрементных нагрузок.
В конечном итоге убедиться, что нет искажений данных.
Для управления памятью необходимо следовать рекомендациям:
Установить значение параметра vm.overcommit_memory на 2.
Не настраивать ОС для использования огромных страниц.
Использовать gp_vmem_protect_limit, чтобы установить максимальный размер памяти, которую инстанс может выделить для работы, выполняющейся в каждом сегментном хосте.
Не допускать, чтобы значение gp_vmem_protect_limit превышало значения физического RAM в системе.
Установить правильное значение для gp_vmem_protect_limit следующим образом: (SWAP + (RAM vm.overcommit_ratio)) 0.9 / number_segments_per_server
Использовать statement_mem для выделения памяти, используемой для запроса на сегмент db.
Использовать очереди ресурсов для установки количества активных запросов (ACTIVE_STATEMENTS) и суммы памяти (MEMORY_LIMIT), которые могут использоваться запросами в очереди.
Связать всех пользователей с очередью ресурсов. Не использовать значения, установленные по умолчанию.
Установить PRIORITY в соответствии с реальными потребностями очереди для рабочей нагрузки.
Убедиться, что распределение памяти очереди ресурсов не превышает gp_vmem_protect_limit.
Обновить параметры очереди ресурсов в соответствии с ежедневным потоком операций.
При партиционировании необходимо следовать рекомендациям:
Можно партиционировать только больших таблиц. Не партиционируйте маленькие таблицы.
Используйте партиционирование только в том случае, если удаление партиций (сокращение партиций) может быть достигнуто на основе критериев запроса.
Выбирайте партиционирование по диапазону вместо партиционирования по списку.
Разбивайте таблицу на партиции на основе часто используемого столбца, например, столбца даты.
Никогда не разбивайте и не распределяйте таблицы по одному столбцу.
Не используйте партиционирование по умолчанию.
Не используйте многоуровневое партиционирование; создавайте меньше партиций с большим количеством данных в каждой партиции.
Убедитесь, что запросы выборочно сканируют партиционированные таблицы путём изучения плана запроса EXPLAIN.
Не создавайте слишком много партиций с хранилищем, ориентированным на столбцы, из-за общего количества физических файлов в каждом сегменте: физические файлы = сегменты x столбцы x партиции.
При работе с индексами необходимо следовать рекомендациям:
Обычно индексы в RT.Warehouse не нужны.
Создавайте индекс в одном столбце таблицы (хранение данных по столбцам) для сквозного доступа для таблиц высокой кардинальности, требующих запросов с высокой избирательностью.
Не индексируйте часто обновляемые столбцы.
Рассмотрите возможность удаления индексов перед загрузкой данных в таблицу. После загрузки заново создайте индексы для таблицы.
Создавайте выборочные индексы B-дерева.
Не создавайте bitmap-индексы в столбцах, которые находятся в процессе обновления.
Избегайте использования bitmap-индексов для уникальных столбцов, данных с очень большой или маленькой кардинальности. Bitmap-индексы работают лучше всего, когда столбец имеет маленькую кардинальность — от 100 до 100 000 различных значений.
Не используйте bitmap-индексы для транзакционных нагрузок.
Как правило, не индексируйте партиционированные таблицы. Если индексы необходимы, столбцы индекса должны отличаться от столбцов партиций.
Для управления рабочей нагрузкой в кластере необходимо использовать очереди ресурсов:
Свяжите все роли с определяемой пользователем очередью ресурсов.
Используйте параметр ACTIVE_STATEMENTS, чтобы ограничить количество активных запросов, которые члены определённой очереди могут выполнять одновременно.
Используйте параметр MEMORY_LIMIT для управления общим объёмом памяти, который могут использовать запросы, выполняемые через очередь.
Динамически изменяйте очереди ресурсов в соответствии с рабочей нагрузкой и временем суток.