Как сделать базу данных MySQL полностью запущенной в памяти?
Я заметил, что мой сервер базы данных поддерживает механизм базы данных памяти. Я хочу создать базу данных, которую я уже сделал, запущен InnoDB полностью работать в памяти для производительности.
Как мне это сделать? Я изучил PHPMyAdmin, и я не могу найти функциональность "change engine".
Ответы
Ответ 1
Предполагая, что вы понимаете последствия использования движка MEMORY, упомянутого в комментариях, и здесь, а также некоторые другие, которые вы найдете по поиск (безопасность транзакций, проблемы с блокировкой и т.д.) - вы можете действовать следующим образом:
Таблицы MEMORY хранятся иначе, чем InnoDB, поэтому вам нужно будет использовать стратегию экспорта/импорта. Сначала выгружайте каждую таблицу отдельно в файл с помощью SELECT * FROM tablename INTO OUTFILE 'table_filename'
. Создайте базу данных MEMORY и заново создайте таблицы, которые вы будете использовать. Затем вы можете импортировать свои данные с помощью LOAD DATA INFILE 'table_filename' INTO TABLE tablename
для каждой таблицы.
Ответ 2
Также возможно разместить каталог данных MySQL в tmpfs, тем самым ускоряя вызовы записи и чтения базы данных. Возможно, это не самый эффективный способ сделать это, но иногда вы не можете просто изменить механизм хранения.
Вот моя запись fstab для моего каталога данных MySQL
none /opt/mysql/server-5.6/data tmpfs defaults,size=1000M,uid=999,gid=1000,mode=0700 0 0
Я также написал сообщение, которое объясняет настройку более подробно. Я использую эту настройку для тестов базы данных.
http://jotschi.de/2014/02/03/high-performance-mysql-testdatabase/
Вы также можете посмотреть настройку innodb_flush_log_at_trx_commit = 2. Возможно, это ускорит ваш MySQL.
innodb_flush_log_at_trx_commit изменяет поведение при загрузке диска mysql. Когда установлено значение 2, он будет очищать буфер только каждую секунду. По умолчанию каждая вставка вызывает флеш и, следовательно, вызывает больше нагрузки ввода-вывода.
Ответ 3
Memory Engine - это не то решение, которое вы ищете. Вы потеряете все, что попало в базу данных, в первую очередь (например, ACID).
Вот несколько лучших альтернатив:
- Не используйте объединения - очень мало крупных приложений делают это (например, Google, Flickr, NetFlix), потому что это отстой для больших наборов объединений.
- Убедитесь, что в столбцах, на которые вы ссылаетесь, есть индексы. Используйте EXPLAIN, чтобы подтвердить, что они используются.
- Используйте и увеличивайте свой Query_Cache и пространство памяти для своих индексов, чтобы получить их в памяти и хранить частые запросы.
- Денормализовать вашу схему, особенно для простых объединений (т.е. получить fooId из barMap).
Последняя точка - ключ. Раньше я любил объединения, но затем приходилось запускать объединения на нескольких столах со 100M + строками. Не хорошо. Лучше не вставляйте данные, к которым вы присоединяетесь, в эту целевую таблицу (если это не так уж много) и запрос к индексированным столбцам, и вы получите свой запрос за несколько мс.
Я надеюсь, что это поможет.
Ответ 4
Если ваша база данных достаточно мала (или если вы добавляете достаточно памяти), ваша база данных будет эффективно работать в памяти, так как ваши данные будут кэшироваться после первого запроса.
Изменение определений таблиц базы данных для использования механизма памяти, вероятно, сложнее, чем вам нужно.
Если у вас достаточно памяти для загрузки таблиц в память с помощью механизма MEMORY
, вам достаточно настроить параметры innodb, чтобы все кэшировать.
Ответ 5
"Как это сделать? Я изучил PHPMyAdmin, и я не могу найти функциональность" change engine ".
В прямой реакции на эту часть вашего вопроса вы можете выдать ALTER TABLE tbl engine=InnoDB;
, и он воссоздает таблицу в правильном движке.
Ответ 6
Вместо механизма хранения памяти можно рассмотреть MySQL Cluster. Говорят, что он дает аналогичную производительность, но для поддержки работы с дисковой поддержкой для долговечности. Я не пробовал, но выглядит многообещающим (и был в разработке в течение нескольких лет).
Здесь вы можете найти официальную документацию MySQL Cluster.