У меня есть работающий кластер БД AWS Aurora, который на 99,9% сосредоточен на записи. На пике он будет выполнять 2-3k операций записи в секунду.
Я знаю, что Aurora по умолчанию несколько оптимизирована для операций записи, но я хотел бы спросить как относительный новичок в AWS: каковы некоторые рекомендации/советы по производительности записи с помощью Aurora?
По моему опыту, Amazon Aurora не подходит для работы с базой данных с интенсивным трафиком записи. По крайней мере, в его реализации около 2017 года. Может быть, со временем это улучшится.
Ранее в 2017 году я работал над некоторыми эталонными тестами для приложения с большим объемом записи, и мы обнаружили, что RDS (не Aurora) намного превосходит Aurora по производительности записи, учитывая наше приложение и базу данных. По сути, Aurora была на два порядка медленнее, чем RDS. Заявления Amazon о высокой производительности Aurora, по-видимому, полностью маркетинговая чушь.
В ноябре 2016 года я посетил конференцию Amazon re:Invent в Лас-Вегасе. Я попытался найти знающего инженера Aurora, чтобы он ответил на мои вопросы о производительности. Все, что я смог найти, это младшие инженеры, которым было приказано повторить утверждение, что Aurora волшебным образом в 5-10 раз быстрее, чем MySQL.
В апреле 2017 года я посетил конференцию Percona Live и увидел презентацию о том, как разработать архитектуру распределенного хранилища, подобную Aurora, с использованием стандартного MySQL с CEPH для уровня распределенного хранилища с открытым исходным кодом. Здесь есть вебинар на ту же тему: https://www.percona.com/resources/webinars/mysql-and-ceph, совместно представленный Ивом Трюдо, инженером, которого я видел на конференции.
Что стало ясно при использовании MySQL с CEPH, так это то, что инженерам пришлось отключить буфер изменений MySQL, потому что нет возможности кэшировать изменения во вторичных индексах, а также распределять хранилище. Это вызывало огромные проблемы с производительностью при записи в таблицы с вторичными (неуникальными) индексами.
Это соответствовало проблемам с производительностью, которые мы наблюдали при тестировании нашего приложения с помощью Aurora. В нашей базе данных было много вторичных индексов.
Поэтому, если вам абсолютно необходимо использовать Aurora для базы данных с высоким трафиком записи, я рекомендую в первую очередь удалить все вторичные индексы.
Очевидно, что это проблема, если индексы нужны для оптимизации некоторых ваших запросов. Конечно, оба запроса SELECT, а также некоторые запросы UPDATE и DELETE могут использовать вторичные индексы.
Одна из стратегий может состоять в том, чтобы создать не-Aurora реплику чтения вашего кластера Aurora и создать вторичные индексы только в реплике чтения для поддержки ваших запросов SELECT. Я никогда этого не делал, но, по-видимому, это возможно, согласно https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/
Но это все еще не помогает в случаях, когда вашим операторам UPDATE/DELETE нужны вторичные индексы. У меня нет никаких предложений для этого сценария. Возможно, вам не повезло.
Мой вывод состоит в том, что я бы не стал использовать Aurora для приложений с большим объемом записи. Может быть, это изменится в будущем.
Обновление за апрель 2021 г.:
После написания вышеизложенного я провел тесты sysbench для Aurora версии 2. Я не могу поделиться конкретными цифрами, но я пришел к выводу, что текущие улучшения Aurora лучше подходят для рабочей нагрузки с большим количеством операций записи. Я провел тесты с большим количеством вторичных индексов, чтобы убедиться. Но я призываю всех, кто серьезно относится к внедрению Aurora, провести свои собственные тесты.
По крайней мере, Aurora намного лучше, чем обычный Amazon RDS для MySQL, использующий хранилище EBS. Вероятно, поэтому они утверждают, что Aurora в 5 раз быстрее, чем MySQL. Но Aurora не быстрее, чем некоторые другие альтернативы, которые я тестировал, и фактически не может сравниться:
MySQL Server устанавливался на экземпляры EC2 с использованием локального хранилища, особенно на экземпляры i3 с локально подключенным NVMe. Я понимаю, что хранилище экземпляров ненадежно, поэтому нужно будет запускать избыточные узлы.
Сервер MySQL я установил на физические хосты в нашем центре обработки данных, используя SSD-хранилище с прямым подключением.
Ценность использования Aurora в качестве управляемой облачной базы данных заключается не только в производительности. Он также имеет автоматизированный мониторинг, резервное копирование, аварийное переключение, обновления и т. д.
У меня был относительно положительный опыт работы с Aurora для моего варианта использования. Я полагаю (время прошло), что мы нажимали где-то около 20 000 DML в секунду, самый большой тип экземпляра (я думаю, db.r3.8xlarge?). Извиняюсь за неточность, у меня больше нет возможности получать метрики для этой конкретной системы.
Что мы сделали:
Эта система не требовала «немедленного» ответа на данную вставку, поэтому записи ставились в очередь отдельному процессу. Этот процесс будет собирать N запросов и разбивать их на M пакетов, где каждый пакет будет коррелировать с целевой таблицей. Эти пакеты будут помещены в один txn.
Мы сделали это, чтобы добиться эффективности записи за счет массовой записи и избежать межтабличной блокировки. Было 4 отдельных (я полагаю?) процесса, которые выполняли это удаление из очереди и поведение записи.
Из-за такой высокой нагрузки на запись нам абсолютно необходимо было передавать все операции чтения на реплику чтения, так как основной сервер обычно загружал 50-60% ЦП. Мы проверили эту архитектуру заранее, просто создав произвольные процессы записи данных и смоделировав общее поведение системы, прежде чем мы зафиксировали в ней реальное приложение.
Записи почти все были INSERT ON DUPLICATE KEY UPDATE, а таблицы имели ряд вторичных индексов.
Я подозреваю, что этот подход сработал для нас просто потому, что мы смогли допустить задержку между появлением информации в системе и моментом, когда она действительно понадобится читателям, что позволило нам группировать гораздо большие объемы. YMMV.
Для сотрудников Google:
Чтобы решить проблему (больше похоже на обходной путь):
Я сказал БУДЬТЕ ОСТОРОЖНЫ, но не НЕ ИСПОЛЬЗУЙТЕ, так как многие сценарии могут быть решены с помощью продуманной архитектуры. На производительность записи базы данных вряд ли можно положиться.
