Насколько я понимаю, новый экземпляр RDS будет "постранично" вставлять блоки из снимка по мере необходимости, как описано для томов EC2. Вот.
В настоящее время это вызывает у меня боль: я выполняю большой запрос на новом тестовом экземпляре; на выполнение должно уйти 10-15 минут, но это продолжалось последний час. У этого экземпляра 1000 ГБ хранилища, то есть 3000 операций ввода-вывода в секунду, но я вижу, что в консоли объединено <100 операций ввода-вывода в секунду (и иногда <20 операций ввода-вывода в секунду при чтении).
Обычно я бы использовал mysqldump сделать полную резервную копию базы данных и отправить ее в /dev/null - но это занимает 12-18 часов. В прошлом я выполнял запросы сканирования таблиц по нескольким таблицам одновременно в надежде, что эти операции ввода-вывода будут происходить параллельно.
Кто-нибудь знает как лучше прогреть громкость?
К сожалению, единственный способ заставить блоки быть выгруженными на страницы - это получить их, и вы уже нашли несколько способов сделать это.
Как оказалось, нет более простого подхода, чем тот, который я уже использовал, поэтому я решил оценить эти подходы.
Для тестовой среды я создал по одному экземпляру для каждого подхода: r3.large (2 виртуальных процессора, 15 ГБ ОЗУ), используя один и тот же снимок для каждого. У этих экземпляров 1000 ГБ на диске, поэтому они должны поддерживать 3000 операций ввода-вывода в секунду.
База данных в целом содержит несколько сотен таблиц, от нескольких сотен до нескольких сотен миллионов строк (пара таблиц, которые используются в основном для ведения журнала, но могут быть задействованы в некоторых отчетных запросах).
Я выбрал две таблицы для оценки: нашу таблицу «пользователей», которая содержит 20 миллионов строк и является чрезмерно широкой, и таблица «связывания», которая также содержит 20 миллионов строк, но только два столбца.
После загрузки я выполнил два запроса к таблице пользователей: один вызвал сканирование таблицы путем суммирования неиндексированного числового поля, а второй выполнил агрегатную операцию с индексированным столбцом (который должен пройти весь индекс). Я не выполнял запросы к таблице связей, потому что она не давала дополнительной информации.
Все тайминги имеют формат H: MM: SS (часы: минуты: секунды) и относятся к одному запуску. Я также отслеживал IOPS при чтении и записи, используя метрики Cloudwatch (обычно в среднем за 5-15 минут).
В нашей базе данных используется MySQL, но я считаю, что общие подходы актуальны для любой СУБД.
mysqldump CONNECTION_OPTIONS --compress DATABASE TABLES > /dev/null
В mysqldump Программа используется для резервного копирования баз данных или отдельных таблиц. Он извлекает все данные таблицы и записывает их в StdOut вместе с DDL для воссоздания таблицы и ее индексов.
Поскольку меня не волнует фактическое резервное копирование таблицы, я перенаправляю вывод в /dev/null. Поскольку я не хочу, чтобы меня задерживала сеть, я использую --compress вариант. Несмотря на это, я использовал инстанс EC2 в той же зоне доступности, чтобы весь сетевой трафик находился в центре обработки данных Amazon.
Главный недостаток этого подхода в том, что он не затрагивает индексные блоки.
Users Linkage
---------------------------------------------
| time to touch blocks | 00:53:38 | 00:03:02 |
| read IOPS | < 150 | 150+ |
| table-scan | 00:01:29 | |
| index aggregate | 00:00:15 | |
Как и в случае с тестовым запросом, этот подход представлял собой простой выбор, который собирал данные из неиндексированного поля. Я выбрал другое поле для запроса «сенсорный», чем для «тестового» запроса.
Как и в случае с операцией дампа, это обращалось только к блокам данных таблицы. Я мог бы расширить его для доступа к индексным блокам с помощью некоторой формы агрегата индекса, но я думаю, что это менее актуально для моих нужд.
Users Linkage
---------------------------------------------
| time to touch blocks | 00:59:12 | 00:03:31 |
| read IOPS | 150 | 150 |
| table-scan | 00:02:04 | |
| index aggregate | 00:00:19 | |
В ОПТИМИЗАЦИЯ ТАБЛИЦЫ команда перестроит таблицу и индекс InnoDB, освободив место в процессе. Это специфично для MySQL, но я бы рассмотрел Postgres VACUUM должна быть похожей, и я уверен, что есть эквивалентные команды для других систем баз данных.
Возможно, это несправедливый тест для нашей большой таблицы, поскольку она подвержена множеству обновлений и, несомненно, никогда не оптимизировалась за свою многолетнюю жизнь. Если бы мы регулярно оптимизировались, возможно, цифры были бы ниже.
Users Linkage
----------------------------------------------
| time to touch blocks | 02:01:36 | 00:03:44 |
| read IOPS | 100 | 150 |
| write IOPS | 500+ | 1000+ |
| table-scan | 00:00:05 | |
| index aggregate | 00:00:01 | |
Вы заметите, что я добавил строку для записи IOPS. Кроме того, эти времена запроса не являются опечатками: они более чем на порядок быстрее, чем другие. Я подозреваю, что это связано с тем, что блоки были кэшированы в памяти (мне, вероятно, следовало перезагрузить экземпляр между касанием блоков и выполнением запросов).
OPTIMIZE значительно медленнее для большой таблицы и использует слишком много операций ввода-вывода в секунду при записи. Однако, если бы я был на Postgres, то VACUUM может быть правильным выбором при условии, что исходная база данных регулярно очищалась.
Разница между выбором всех строк и mysqldump было незначительным и, возможно, из-за нагрузки на сеть или виртуальную машину. Тем не мение, mysqldump выполнить гораздо проще, потому что выбор всех строк требует некоторого размышления, чтобы выбрать подходящий запрос.
После выполнения этих тестов я открыл новый экземпляр и запустил 10 одновременных mysqldump сеансы (случайное разделение таблиц между ними). Некоторые наблюдения:
Поразмыслив над этой проблемой, я пришел к выводу, что моя боль в первую очередь связана с тем, что я использую этот экземпляр для тестирования нагрузки отчетов. Если бы это был экземпляр OLTP, я подозреваю, что смог бы перевести его в эксплуатацию с минимальными трудностями (хотя и с меньшей производительностью). Тем не менее, та же боль повлияет на реплики чтения, возможно, в большей степени, потому что вы вызовете другую реплику только в ответ на большую нагрузку на систему.
В долгосрочной перспективе я могу только надеяться, что Amazon сочтет целесообразным добавить операцию «быстрой инициализации», которая параллельно затрагивает блоки тома.