Amazon Aurora PostgreSQL: возможность клонирования: недостатки?

Question

У меня есть Amazon Aurora PostgreSQL-совместимая база данных, работающая в качестве «живого» пилотного экземпляра.

Я планирую официальный переход к производству на начало следующего года, который, как я предполагал, будет включать созданиеэкземпляры разработки и тестирования, восстановление моментальных снимков для начала работы и т. д. Кроме того, у меня есть срочная необходимость внести некоторые уточнения в модель данных, которые могут оказать потенциальное влияние на существующие представления и процедуры, и неохотно делать это в «живом» экземпляре,хотя в настоящий момент времени простоя не существует.

Я читал документы Amazon о клонировании Авроры, но не смог найти ни одной статьи или поста "реального мира" об их использовании на практике.Я вижу одну статью, не относящуюся к Amazon, которая на самом деле просто повторяет резюме Amazon.

Кто-нибудь имеет какой-либо прямой опыт использования этой возможности?Или изнутри знание механики?В частности:

1. Можете ли вы вносить изменения DDL (схемы) для каждого экземпляра независимо?Там нет упоминания об этом в документации.Я не уверен, подразумевает ли использование термина «клон», что они остаются структурно идентичными, но, учитывая приведенные примеры использования, я не могу себе представить, что вы в основном замораживаете структуру БД, клонируя ее.
2. есть ли какое-то влияние на производительность (учитывая распределение памяти между «замороженными» общими страницами и страницами, специфичными для экземпляра?
3. Если вы создаете клон базы данных, а затем удаляете этот клон, необратимо ли вы изменили схему хранениядля исходной базы данных (включая любые последствия для производительности процесса)?
4. Меняет ли это поведение удалений под капотом? Я не знаю, как работает хранилище Aurora (и у меня есть только разрозненные знания о хранилище базы данныхв общем), но в старые времена хранилище могло быть восстановлено для удаленных данных. В этой модели, если вы клонируете базу данных, а затем удаляете несколько строк из таблицы, что происходит?

Iсобираюсь протестировать его, создав «старомодный клон» (восстановление моментального снимка до нового экземпляра),затем клонируем это, но любые идеи тем временем с благодарностью получены!

Answer 1

1. Да, вы можете вносить изменения в схему клона, и они вообще не влияют на базовую базу данных.Это приведет к тому, что клону потребуется скопировать каждую страницу в таблице, поскольку все исходные страницы должны быть изменены для клона.
2. Это зависит от того, что мы видели, что если вы измените схему большой таблицы,клон может быть очень медленным - у меня не было официального объяснения, но я предполагаю, что это потому, что клон вынужден ссылаться через указатели оригинальной страницы, чтобы добраться до своих копий, что хорошо для небольшой таблицы или для сравнительно небольшойколичество страниц в большой таблице, но как только вся таблица будет скопирована по существу из-за изменения схемы, мы наблюдаем случай, когда запрос SELECT длиной менее секунды занимает 80 секунд на клон.Я скажу, что фактическое изменение схемы не заняло больше времени, чем ожидалось.
3. Нет, страницы исходной базы данных никогда не затрагиваются клоном, они используются до тех пор, пока клон не изменит их, и в этот момент они копируются дляиспользование клона только.Если впоследствии вы удалите весь оригинал или весь клон, что тоже хорошо, две базы данных будут работать так, как если бы они были полностью независимы друг от друга, они будут использовать только неизмененные страницы.
4. Нет, в основном тот же ответ, что и 3. Есливы удаляете строки в клоне, страницы, содержащие эти строки, будут скопированы для клона и оставлены нетронутыми для оригинала.

Мы используем клонов для разработки и подготовки копий производства, как вы описали иэто прекрасно работает, но, как я уже сказал, есть сценарий (изменение схемы на большую таблицу), где мы наблюдаем очень низкую производительность.В целом, производительность была хорошей, мы не видим заметных различий в производительности обычных INSERT, UPDATE или DELETE. Вероятно, это было бы более заметно, если вы запустили огромное UPDATE, которое коснулось большинства строк в большой таблице, но для обычныхприложение работает хорошо.