Для моей машины разработки мне не нужна согласованность данных в случае сбоя. Есть ли конфигурация для подобной Debian системы, которая оптимизирует MySQL для скорости (даже если она жертвует надежностью)?MySQL: скорость над конфигурацией надежности
Так что-то вроде: Кэш последней 1 ГБ в ОЗУ. Не прикасайтесь к диску данными до тех пор, пока не будет использован 1 ГБ.
Хотя этот ответ не может ударить именно те вопросы, которые вы задаете, рассмотреть возможность создания таблицы с помощью MEMORY двигателя как описано здесь: http://dev.mysql.com/doc/refman/5.7/en/memory-storage-engine.html
Типичный случай использования для ПАМЯТЬ двигателя включает следующие характеристики:
Операции с временными, некритическими данными, такими как сеанс Управление или кэширование. Когда сервер MySQL останавливается или перезапускается, данные в таблицах MEMORY теряются.
Память в памяти для быстрого доступа и низкой латентности. Объем данных может полностью соответствовать в памяти, не вызывая операционную систему для замены страниц виртуальной памяти .
Образец доступа только для чтения или чтения (ограниченные обновления).
Дайте этот снимок.
Моей рекомендацией, даже для машины разработки, было бы использовать InnoDB по умолчанию. Если вы решите совершать транзакции, InnoDB будет полезен.
Этот блог может помочь вам запустить MySQL с tmpfs: http://jotschi.de/2014/02/03/high-performance-mysql-testdatabase/. Пользователь Jotschi также говорит об этом в SO answer #10692398
Вы можете отключить многие конфигурации InnoDB для обеспечения долговечности, рискуя увеличить риск потери данных. Но иногда вы хотите управлять базой данных в Running with scissors mode, потому что исходные данные безопасно хранятся в другом месте, а копия в тестовой базе данных легко воссоздана.
Этот блог описывает Reducing MySQL durability for testing. Вы не увидите официальную рекомендацию MySQL для этого в любых целях, кроме тестирования!
Вот краткое описание изменений, которые вы можете сделать в вашем /etc/my.cnf:
[mysqld]
# log_bin (comment this out to disable the binary log)
# sync_binlog=0 (irrelevant if you don't use the binary log)
sync_frm=0
innodb_flush_log_at_trx_commit=0
innodb_doublewrite=0
innodb_checksums=0
innodb_support_xa=0
innodb_log_file_size=2048M # or more
Он также рекомендует увеличить innodb_buffer_pool_size, но размер зависит от доступной оперативной памяти.
Для чего это стоит, я недавно попытался установить innodb_flush_log_at_trx_commit=0 в конфигурации в ящике Vagrant по умолчанию, который я построил для разработчиков в моей команде, но мне пришлось отменить это изменение, потому что это вызывало слишком много времени для разработчиков, которые были повреждены базы данных. Просто пища для размышлений. Иногда это не хороший компромисс.
Это не делает то, что вы просили (сохраняйте последние 1 ГБ данных в ОЗУ), поскольку он все еще работает с InnoDB с протоколом транзакций и сбрасывает журнал на диск один раз в секунду. В MySQL нет возможности отключить это.
Вы можете попробовать использовать MyISAM, который использует буферизованные записи для данных и индекса, и полагается на буфер файловой системы.Поэтому может кэшировать некоторые ваши данные (на практике я обнаружил, что буфер сбрасывается на диск довольно быстро, так что вы вряд ли будете иметь полный 1 ГБ в ОЗУ в любое время). MyISAM имеет другие проблемы, такие как отсутствие поддержки транзакций. Разработка с помощью MyISAM, а затем использование InnoDB в производстве может поднять вас на некоторые неудобные сюрпризы.
Вот несколько других изменений, которые вы могли бы внести в свои сеансы MySQL ради производительности, но я не рекомендую их даже для разработки, потому что это может изменить поведение вашего приложения.
set session unique_checks=0;
set session foreign_key_checks=0;
Некоторые люди рекомендуют использовать двигатель хранения MEMORY. У этого есть свои проблемы, такие как ограничения по размеру, блокировка таблицы и отсутствие поддержки транзакций.
Я также экспериментировал с попыткой поставить таблицы или tmpdir на tmpfs, но я обнаружил, что вы не ожидаете увеличения производительности. В RDBMS есть накладные расходы, которые напрямую не связаны с дисковым вводом-выводом.
Возможно, вам также захочется поэкспериментировать с MyRocks, версией MySQL, включая механизм хранения RocksDB для MySQL. Facebook разработал его и выпустил в виде open-source. См. Facebook rocks an open source storage engine for MySQL (InfoWorld). Они обещают, что он сокращает объемы ввода-вывода, он сжимает данные и делает другие аккуратные вещи.
Но опять же, это правильное эмпирическое правило, чтобы ваша среда разработки была как можно ближе к вашей производственной среде. Использование другого механизма хранения создает риск не обнаруживать некоторые ошибки до тех пор, пока ваш код не достигнет производительности.
Итог: настройка MySQL не является волшебной пулей. Возможно, вам стоит подумать о разработке своего приложения, чтобы больше использовать микросервисы, кеши и очереди сообщений, а также меньше полагаться на прямые SQL-запросы.
Кроме того, я бы рекомендовал всегда предоставлять вашим разработчикам самую быструю рабочую станцию на базе SSD, которую вы можете себе позволить. Идите в верхнюю часть строки на CPU и RAM и скорость диска.
Какие запросы идут? Одна из моих мантр: «Вы не можете настроить свой выход из проблемы с производительностью».
Вот одна вещь, которая ускоряет InnoDB, WRT операции:
innodb_flush_log_at_trx_commit = 2
Существует простой способ ускорить однорядные вставки на коэффициент 10.
некоторых «составных» индексов может ускорить SELECT на коэффициент 100.
переформулировав WHERE иногда может ускорить запрос на коэффициент 100.
Я использовал составной индекс, чтобы ускорить один запрос в коде моей компании в 94 миллиона! :-) –
@Bill Ответ Карвина имеет полезные настройки mysql для повышения производительности. Я использовал их все и смог добиться улучшения в 2 раза.
Однако то, что дало мне наибольшее повышение производительности (почти в 15 раз быстрее) для моего варианта использования - которое было перезагрузкой дампа mysql - заключалось в том, чтобы смонтировать базовую файловую систему (ext4) с помощью опции nobarriers.
mount -o remount,nobarrier /
Вы должны рассмотреть это, только если у вас есть отдельный раздел (или логический том), установленный в/вар/Lib/MySQL, так что вы можете сделать это компромиссом только для MySQL, а не всей вашей системы.
Вам действительно нужно настроить конфигурацию для своего приложения, для вашего сервера - нет универсального решения – Clive
Это не происходит на сервере. Это происходит на машине разработки. Невозможно настроить конфигурацию для приложения, так как программа не выполнена: она разрабатывается - все это является точкой разработки машины. Сохранение последних 1 ГБ транзакций в ОЗУ без их очистки на диске в моем случае будет достаточным. –
Я не уверен, почему этот вопрос занижен. Это интересный вариант использования, когда скорость MySQL имеет приоритет над надежностью. Механизм MyISAM или движок памяти могут работать хорошо. tpmfs также может быть полезным. – zedfoxus