Почему в Greenplum 7 восстановление данных из резервной копии базы стало медленнее и как разработчики это исправили: причины замедления и способы их устранения.
SQL-синтаксис и восстановление из бэкапа
Напомним, 7-ой релиз Greenplum имеет много интересных и полезных функций, включая возможность определять партиционированную таблицу без определения дочерних разделов и изменять таблицы без их перезаписи, о чем мы писали здесь. Это реализовано за счет нового PostgreSQL-подобного синтаксиса для создания партиционированных таблиц и гибкого управления ими. Этот синтаксис позволяет более четко описывать разнообразие конечных таблиц. Однако, как показали регрессионные тесты, такая гибкость чревата падением производительности при восстановлении больших объемов метаданных с использованием утилиты gprestore и программы создания резервных копий базы данных pg_dump. Утилита gprestore позволяет восстановить резервную копию базы данных Greenplum, созданную с помощью утилиты резервного копирования gpbackup. По умолчанию gprestore использует резервные копии файлов метаданных и файлов DDL-скриптов, расположенных в каталоге данных хоста координатора Greenplum, а данные таблиц хранятся локально на хостах сегментов в CSV-файлах данных. Подробнее об использовании этих утилит при миграции данных читайте в нашей новой статье.
Как и в любой реляционной СУБД, в Greenplum используются DDL-инструкции, которые содержат соответствующие SQL-операторы. Эти операторы позволяют создать и изменить таблицы, включая определение владельца и присоединение раздела: CREATE TABLE, ALTER OWNER и ATTACH PARTITION. Выполнение каждого из этих SQL-операторов имеет накладные расходы, что снижает общую производительность системы. Прежний синтаксис Greenplum (до версии 7) был более производительным, хотя и отличался от популярных конструкций в текущей реализации PostgreSQL. В частности, бенчмаркинговый тест сравнения производительности, проведенный разработчиками Greenplum в 3-сегментном кластере на примере 28 корневых таблиц и общим количеством около 164 000 таблиц, показал замедление выполнения SQL-операторов почти в 7 раз.
Устранить такое снижение производительности, вызванное изменением синтаксиса DDL-инструкций, можно несколькими способами. Во-первых, можно сделать эти команды транзакционными, обернув их в явные операторы BEGIN и END. Это снижает количество фиксаций и ускоряет выполнение кода, поскольку восстановление предварительных метаданных при запуске утилиты gprestore и выполнение DDL-инструкций с операторами присоединения раздела (ATTACH PARTITION) имело накладные расходы, связанные с двухфазной фиксацией.
Параллельное восстановление таблиц в Greenplum
Другим решением стало распараллеливание операций параллельного восстановления данных через настраиваемое количество соединений при использовании флага –jobs в утилите gprestore. Благодаря тому, что данные в одной таблице обычно независимы от данных в других, операторы создания предварительных метаданных можно не выполнять в едином линейном порядке, как это было раньше. Для организации восстановления метаданных утилита gpbackup полагается на таблицу pg_depend, которая отслеживает каждый объект и объекты, от которых он зависит. Можно использовать эту информацию, чтобы гарантировать, что ни один объект не будет восстановлен до того, как станут доступны его зависимости. Это достигается за счет топологической сортировки поиска в глубину, т.е. DFS-стратегии (Depth-First Search), чтобы просмотреть зависимости и привести их в работоспособный порядок. Во время резервного копирования предполагаемый порядок выполнения всех операторов предварительных метаданных записывается, а при восстановлении они просто выполняются в указанном порядке. Чтобы использовать этот подход и усовершенствовать его для поддержки параллельного восстановления, в Greenplum 7 были внесены некоторые изменения.
В частности, во время резервного копирования, помимо записи порядка выполнения, следует заранее распределить объекты по группам, чтобы параллельные соединения не конкурировали и не блокировали друг друга. Это выполняется в несколько этапов. Сперва записываются шаги DFS, используя глубину как значение уровня. Это означает, что объекты, не имеющие зависимых объектов, перейдут на первый уровень, а каждый последующий уровень дерева будет на последующий уровень. Затем начнется восстановление метаданных и будет зафиксирована отдельная транзакция для каждого уровня. Это позволяет делать транзакции немного короче для большей стабильности в случае ошибок и дает пространство для перемещения вещей вверх или вниз по течению, если обнаружится, что таблице pg_depend недостаточно информации для поддержания правильного порядка. Однако, уровни все равно должны идти по порядку и, чтобы разделить их для запуска по нескольким соединениям, внутри каждого уровня сделано распределение объектов по когортам на основании зависимостей. Если какие-либо из последующих объектов уже сопоставлены с каким-либо деревом, все дерево этого объекта помещается в ту же группу. После этого на любом уровне ни один объект не зависит от объектов из другой когорты. Таким образом, каждую когорту можно безопасно восстановить совершенно независимо от других.
Этот подход предоставляет toc-файлам оглавления удобный способ точного определения уровня параллелизма, доступного для каждой конкретной резервной копии. Наивысшее наблюдаемое значение когорты для любого заданного уровня — это теоретическое максимальное количество заданий, которые можно использовать при восстановлении метаданных. Чтобы сопоставить когорты с соединениями, следует организовать перебор оператора восстановления каждого объекта и присвоить его тому соединению, к которому принадлежит его когорта. Каждый раз, когда появляется новая когорта, она присваивается соединению, которое в данный момент имеет наименьшее количество утверждений. После того как все назначения выполнены, каждое соединение открывает транзакцию и просто выполняет свои операторы по порядку, дополнительная логика не требуется. Тестирование показало жизнеспособность этого подхода и ускорение операций восстановления.
Освойте администрирование и эксплуатацию Greenplum с Arenadata DB для эффективного хранения и аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
