InnoDB Bottleneck: расслабляющая кислота для повышения производительности
Заметив, что наша база данных стала главным узким местом в наших системах реального производства, я решил построить простой бенчмарк, чтобы добраться до сути проблемы.
Эталонный показатель: I время, необходимое для увеличения одной и той же строки в таблице InnoDB в 3000 раз, где строка индексируется ее первичным ключом, а обновляемый столбец не является частью какого-либо индекса. Я выполняю эти 3000 обновлений, используя 20 параллельных клиентов, работающих на удаленной машине, каждый со своим собственным отдельное подключение к БД.
Мне интересно узнать, почему различные механизмы хранения данных, которые я сравнивал, InnoDB, MyISAM и MEMORY, имеют профили, которые они делают. Я также надеюсь понять, почему InnoDB так плохо себя чувствует по сравнению с ними.InnoDB (20 параллельных клиентов): Каждое обновление занимает 0,175 С. Все обновления выполняются после 6.68 с.
MyISAM (20 параллельных клиентов): Каждое обновление занимает 0,003 С. Все обновления выполняются после 0.85 с.
Память (20 одновременных клиенты): Каждое обновление занимает 0,0019 С. Все обновления выполняются после 0.80 с.
Думая, что параллелизм может быть причиной такого поведения, я также сравнил одного клиента, выполняющего 100 обновлений последовательно.
InnoDB: Каждое обновление занимает 0,0026 с.
MyISAM: Каждое обновление занимает 0,0006 с.
Память: Каждое обновление занимает 0,0005 с.
Фактической машиной является экземпляр Amazon RDS (http://aws.amazon.com/rds/) с большей частью конфигурациями по умолчанию.
Я ... предположим, что ответ будет примерно таким: InnoDB fsyncs после каждого обновления (так как каждое обновление является транзакцией, совместимой с ACID), в то время как MyISAM не делает этого, так как он даже не поддерживает транзакцию. MyISAM, вероятно, выполняет все обновления в памяти и регулярно сбрасывает их на диск, поэтому его скорость приближается к движку хранения памяти. Если это так, есть ли способ использовать InnoDB для его поддержки транзакций, но, возможно, ослабить некоторые ограничения (через конфигурации) так, чтобы записи выполняются быстрее за счет некоторой долговечности?
Кроме того, есть ли предложения о том, как улучшить производительность InnoDB по мере увеличения числа клиентов? Он явно масштабируется хуже, чем другие механизмы хранения.
Обновить
Запустив те же бенчмарки, мы видим 10-кратное улучшение производительности записи.
InnoDB (20 параллельных клиентов): Каждое обновление занимает 0,017 С. Все обновления выполняются после 0.98 с.
Есть еще предложения?
2 ответа:
Я нашел https://blogs.oracle.com/MySQL/entry/comparing_innodb_to_myisam_performance , что именно то, что я искал. Установка innodb-flush-log-at-trx-commit=2 позволяет нам ослабить кислотные ограничения (промывка на диск происходит один раз в секунду) для случая, когда происходит сбой питания или сбой сервера. Это дает нам аналогичное поведение MyISAM, но мы все еще получаем выгоду от функций транзакций, доступных в InnoDB.
Запустив те же бенчмарки, мы видим 10-кратное улучшение производительности записи.
InnoDB (20 параллельных клиентов): каждое обновление занимает 0,017 с. Все обновления выполняются после 0,98 с.
Мы провели несколько подобных тестов в нашем приложении, и мы заметили, что если ни одна транзакция не открывается явно, каждая отдельная инструкция SQL обрабатывается внутри транзакции, что занимает гораздо больше времени для выполнения. Если позволяет ваша бизнес-логика, вы можете поместить несколько SQL-команд в блок транзакций, что снизит общую нагрузку на ACID. В нашем случае мы добились значительного улучшения производительности с помощью этого подхода.