Еще больше больших данных: масштабирование кластера Greenplum

Какие подходы позволяют увеличить емкость СУБД, чтобы повысить объем хранящихся в ней данных и ускорить вычисления. Разбираем тонкости масштабирования распределенной базы данных с массово-параллельной обработкой Greenplum: действия администратора по добавлению новых узлов в кластер.

Как увеличить емкость базы данных: 4 подхода к масштабированию

Чтобы увеличить емкость СУБД, т.е. объем хранимых в ней данных, используются различные варианты масштабирования:

• Вертикальное, которое предполагает наращивание аппаратных ресурсов текущего сервера для обработки большей рабочей нагрузки, включая добавление дополнительной памяти, хранилища или мощности ЦП к существующему серверу. Этот вариант часто является самым простым и быстрым способом масштабирования СУБД, но может оказаться самым дорогим, поскольку требует покупки нового оборудования. Кроме того, бесконечно наращивать ресурсы компьютера не имеет смысла из-за физических ограничений, связанных со скоростью света: по достижении определенного предела увеличение объема памяти теряет смысл.
• горизонтальное масштабирование предполагает добавление дополнительных серверов для распределения рабочей нагрузки. Это обеспечивает лучшую масштабируемость и отказоустойчивость, поскольку если один узел кластера выйдет из строя, другие узлы смогут справиться с ростом нагрузки. Однако, на практике горизонтальное масштабирование может оказаться сложнее в настройке и управлении, чем вертикальное.
• Использование массивно-параллельной обработки данных (MPP, Massively Parallel Processing), когда несколько серверов выполняют вычисления для параллельной обработки запросов. Это позволяет повысить производительность при работе с большими наборами данных, что полезно для рабочих нагрузок DWH и бизнес-аналитики. Также MPP-базы также можно масштабировать по горизонтали, чтобы справляться с еще большими рабочими нагрузками.
• Шардирование, что предполагает разделение большой базы данных на более мелкие управляемые фрагменты (шарды, shard), каждый из которых хранится на отдельном сервере, обеспечивая масштабируемость и отказоустойчивость. Шардирование БД также может повысить производительность SQL-запросов, которые могут выполняться на определенном сегменте, а не на всей базе данных. Однако, шардирование может быть сложным в настройке и управлении, а также может потребовать специальных навыков.

На практике эти подходы могут сочетаться. В частности, MPP-базы с открытым исходным кодом, такие как Greenplum, Hive и графовая СУБД TigerGraph, о чем мы писали вчера, поддерживают шардирование и горизонтальное масштабирование, обеспечивая высокую производительность и широкий набор сценариев использования. Тем не менее, практическая реализация масштабирования в MPP-СУБД – это не самая тривиальная задача. Как увеличить производительность и емкость хранилища Greenplum, рассмотрим далее.

Масштабирование кластера Greenplum

Корпоративные хранилища данных, которые часто реализуются с помощью MPP-СУБД Greenplum, растут по мере сбора дополнительных данных и увеличения сроков хранения существующих. Иногда необходимо увеличить емкость этой базы данных, чтобы объединить различные хранилища данных или поддерживать новые аналитические приложения. В реальности не всегда получается предусмотреть возможности роста системы на этапе ее проектирования, чтобы инвестировать в ресурсы до того, как они потребуются. Поэтому на практике приходится запускать проекты расширения уже существующей базы данных.

Чтобы увеличить производительность и емкость хранилища на Greenplum, можно выполнить горизонтальное машстабирование, добавив новые хосты. Как правило, добавление узлов в кластер Greenplum обеспечивает линейное масштабирование производительности и емкости хранилища.

Благодаря MPP-архитектуре Greenplum при добавлении ресурсов емкость и производительность остаются такими же, как если бы система изначально была реализована с ними. В отличие от многих других хранилищ, которые требуют значительного времени простоя для создания дампа и восстановления данных, расширение Greenplum представляет собой поэтапный процесс с минимальным временем простоя. Регулярные и нерегламентированные рабочие нагрузки могут продолжаться, пока данные перераспределяются, а согласованность транзакций продолжает поддерживаться. Администратор кластера Greenplum может запланировать масштабирование, приостанавливая и возобновляя его по мере необходимости. Таблицы можно ранжировать таким образом, чтобы наборы данных перераспределялись в приоритетной последовательности, гарантируя, что критические рабочие нагрузки быстрее получат выгоду от расширенной емкости. Или же можно быстрее освободить место на диске, необходимое для перераспределения очень больших таблиц.

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

Сперва необходимо добавить новые хосты сегментов и инициализировать новые экземпляры сегментов. Рекомендуется выполнять это в период низкой активности, чтобы избежать нарушения текущих бизнес-операций. В процессе инициализации базы данных Greenplum и ее объекты создаются в экземплярах нового сегмента на новых хостах сегмента. Можно использовать в схеме данных gpexpand для мониторинга и управления процессом расширения. После обновления системы новые экземпляры сегментов на новых хостах сегментов сразу становятся доступными для SQL-запросов и загрузки данных. Однако, ранее существующие данные становятся распределены неравномерно и должны быть перераспределены по новому общему количеству первичных сегментов для эффективного выполнения SQL-запросов. Сделать это поможет утилита gpexand, которая перераспределяет данные таблицы по всем серверам, старым и новым, в соответствии с политикой распределения, а статус таблицы обновляется в таблицах управления расширением. В результате этого после перераспределения данных оптимизатор SQL-запросов создает более эффективные планы выполнения.

При масштабировании Greenplum администратор кластера запускает утилиту gpexpand несколько раз с различными параметрами, чтобы:

• создать входной файл расширения gpexpand -f <hosts_file>;
• инициализировать сегменты и создать схему расширения gpexpand -i <входной_файл>. При этом gpexpand создает каталог данных, копирует пользовательские таблицы из всех существующих баз данных в новые сегменты и записывает метаданные для каждой таблицы в схему расширения для отслеживания состояния. После завершения этого процесса операция расширения фиксируется и не может быть отменена.
• перераспределить данные таблицы между вновь добавленными экземплярами сегментов: gpexpand -d <duration>. В зависимости от размера и масштаба перераспределение может быть выполнено за один сеанс в часы малой загрузки или за несколько раз в течение длительного периода. Каждая таблица или раздел становятся недоступны для операций чтения или записи во время перераспределения. Поскольку каждая таблица перераспределяется между новыми сегментами, производительность базы данных должна постепенно улучшаться, пока она не превысит уровни производительности до расширения. Иногда требуется запустить gpexpand несколько раз, чтобы завершить расширение в крупномасштабных системах, требующих нескольких сеансов перераспределения. Пользователи могут иметь доступ к Greenplum во время инициализации, но возможно снижение производительности в ситуациях, которые сильно зависят от распределения хэшей таблиц. ETL-задания, пользовательские запросы и отчеты могут продолжаться, хотя время отклика увеличится.
• удалить схему расширения: gpexpand -c

При расширении Greenplum необходимо деактивировать прокси-серверы межсоединений перед добавлением в систему новых хостов и экземпляров сегментов. Также следует обновить параметр gp_interconnect_proxy_addresses, указав недавно добавленные экземпляры сегментов, прежде чем повторно включать прокси-серверы межсоединений. Например, эти команды деактивируют прокси-серверы межсоединения Greenplum, устанавливая межсоединение по умолчанию (UDPIFC) и перезагружая конфигурационный файл postgresql.conf для обновления:

• gpconfig -r gp_interconnect_type
• gpstop -u

Чтобы убедиться в готовности новых хостов в существующую систему, их надо подготовить, установите бинарные файлы Greenplum. Также рекомендуется обменяйтесь необходимыми SSH-ключами и протестировать производительность, запустив тесты сначала на новых хостах, а затем на всех в автономном режиме, чтобы активность пользователя не искажала результаты. Обычно это выполняется, когда администратор изменяет сетевые параметры хоста или другие особые условия в системе. Новые хосты должны обмениваться SSH-ключами с существующими, чтобы административные утилиты Greenplum могли подключаться ко всем сегментам без запроса пароля. Следует дважды выполнить процесс обмена ключами с помощью утилиты gpssh-exkeys: сначала от имени пользователя root для удобства администрирования, а затем от имени пользователя gpadmin для утилит управления.

Инициализацию новых сегментов обеспечит утилита gpexpand, которая при первом запуске с допустимым входным файлом создает и инициализирует экземпляры сегментов и создаст схему расширения. Затем gpexpand выполняет перераспределение таблиц, при котором Greenplum должна находиться в рабочем режиме, но не в ограниченном режиме и не в режиме мастера. Нельзя указать параметры gpstart -R или -m для запуска Greenplum. Пока происходит перераспределение таблиц, любые новые созданные таблицы или разделы распределяются по всем сегментам точно так же, как в нормальных условиях работы. SQL-запросы могут обращаться ко всем сегментам даже до того, как соответствующие данные будут перераспределены в таблицы новых сегментов. Перераспределяемая таблица или раздел блокируются для операций чтения или записи. Когда его перераспределение завершится, нормальная работа возобновится.

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

В заключение отметим, что утилита gprestore не может восстановить резервные копии, сделанные до расширения с помощью утилиты gpbackup, поэтому рекомендуется делать резервную копию базы данных сразу после завершения расширения системы. Подробнее про резервное копирование и обеспечение высокой доступности этой MPP-СУБД читайте здесь.

Узнайте больше про администрирование и эксплуатацию Greenplum с Arenadata DB для эффективного хранения и аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

• Greenplum для инженеров данных
• Администрирование Greenplum / Arenadata DB

Источники

1. https://greenplum.org/how-to-scale-sql-server/
2. https://docs.vmware.com/en/VMware-Tanzu-Greenplum/6/greenplum-database/GUID-admin_guide-expand-expand-main.html