Amazon Aurora PostgreSQL: возможность клонирования: минусы?
У меня есть база данных, совместимая с Amazon Aurora PostgreSQL, и она работает как «живой» пилотный экземпляр.
Я планирую формальный переход на производство в начале следующего года, который, как я предполагал, будет включать в себя создание экземпляров для разработки и тестирования, восстановление моментальных снимков для начала работы и т. д. Кроме того, мне срочно необходимо внести некоторые улучшения в модель данных, которые имеют потенциальное влияние на существующие представления и процедуры, и я не хочу делать это в «живом» экземпляре, хотя на данный момент нет прямого влияния простоя.
Я читал документацию Amazon о клонировании Aurora, но не нашел никаких «реальных» статей или сообщений об использовании его на практике. Я вижу одну статью, не относящуюся к Amazon, которая на самом деле просто повторяет резюме Amazon.
Есть ли у кого-нибудь прямой опыт использования этой возможности? Или внутреннее знание механики? Конкретно:
- Можете ли вы вносить изменения DDL (схемы) в каждый экземпляр независимо? В документации об этом нет упоминания. Я не уверен, подразумевает ли использование термина «клон», что они остаются структурно идентичными, но, учитывая процитированные варианты использования, я не могу представить, что вы в основном замораживаете структуру БД путем ее клонирования.
- Есть ли какое-либо влияние на производительность (учитывая распределение хранилища между «замороженными» общими страницами и страницами, относящимися к конкретному экземпляру?
- Если вы создаете клон базы данных, а затем удаляете этот клон, изменили ли вы необратимо шаблон хранения для исходной базы данных (включая любые последствия процесса для производительности)?
- Это меняет поведение удалений под капотом? Я не знаю, как работает хранилище Aurora (и имею лишь отрывочные сведения о хранилище базы данных в целом), но в прежние времена хранилище можно было восстановить для удаленных данных. Что происходит в этой модели, если вы клонируете базу данных, а затем удаляете несколько строк из таблицы?
Я собираюсь протестировать это, создав «старомодный клон» (восстановление снимка в новый экземпляр), а затем клонирую его, но пока что с благодарностью получены любые идеи!
Ответы 1
- Да, вы можете вносить изменения в схему клона, и они вообще не влияют на базовую базу данных. Они приведут к тому, что клону нужно будет скопировать каждую страницу в таблице, потому что все исходные страницы должны быть изменены для клона.
- Это зависит - мы видели, что если вы измените схему большой таблицы, клон может работать очень медленно - у меня не было официального объяснения, но я предполагаю, что это связано с тем, что клон должен ссылаться на исходные указатели страниц на добраться до его копий, что нормально для небольшой таблицы или для относительно небольшого количества страниц в большой таблице, но как только вся таблица будет скопирована по существу из-за изменения схемы, мы видим случай, когда субсекундный SELECT запрос занимает 80 секунд на клоне. Я скажу, что фактическое изменение схемы не заняло больше времени, чем ожидалось.
- Нет, страницы исходной базы данных никогда не затрагиваются клоном, они используются до тех пор, пока клон не изменяет их, после чего они копируются только для использования клоном. Если вы позже удалите весь оригинал или весь клон, это тоже нормально, две базы данных работают так, как если бы они были полностью независимы друг от друга, они разделяют только неизмененные страницы.
- Нет, в основном тот же ответ, что и 3. Если вы удалите строки в клоне, страницы, содержащие эти строки, будут скопированы для клона и останутся нетронутыми для оригинала.
Мы используем клоны для разработки и промежуточных копий продукции, как вы описываете, и это отлично работает, но, как я уже сказал, есть сценарий (изменение схемы на большую таблицу), при котором мы наблюдаем очень низкую производительность. В целом производительность была хорошей, мы не видим заметной разницы в производительности обычных INSERT, UPDATE или DELETE - это, вероятно, было бы более заметно, если бы вы выполнили огромное UPDATE, которое затронуло большинство строк в большой таблице, но для обычных приложение работает хорошо.
Большое спасибо за это. Сегодня я провел некоторое время с клонированным экземпляром, и мои выводы в точности такие, как вы описали. Я не сталкивался с какими-либо сбоями в производительности, но моей целью для клона было отбросить все таблицы в одной схеме, а затем воссоздать их с измененным дизайном. Моя БД - это хранилище данных, но небольшое (на данный момент 150 ГБ). Интересный комментарий о пригодности DW и OLTP - мой опыт работы с Aurora был отличным. Пока что это кажется мне блестящим предложением, которое может заставить меня подумать об отсутствии каких-либо постоянных экземпляров разработки / тестирования вообще.
Как выглядят цены на клон Aurora? Придется ли платить за совершенно новый экземпляр? Есть какая-то скидка или сделка?
Экземпляр клона - это просто обычный экземпляр, поэтому вы должны платить за него обычную цену, пока он работает - он может быть другого размера, поэтому стоимость зависит от размера. Вы сэкономите на хранилище, потому что вы платите за хранилище только тогда, когда вносите в клон изменения, которые необходимо записать на отдельные страницы.
Один быстрый комментарий о PostgreSQL Aurora, а не о клонировании - см. Мой ответ для полного ответа на ваши конкретные вопросы о клонировании - мы увидели меньшую производительность в базе данных PostgreSQL Aurora, чем мы видели на экземпляре PostgreSQL RDS того же размера в сценарии, где у нас есть хранилище данных в PostgreSQL, и небольшое количество клиентов выполняет очень большие запросы или массовые обновления. Aurora больше подходит для «большого количества одновременных запросов и транзакций» - см. aws.amazon.com/rds/aurora/faqs