В какой момент точная настройка MySQL INNODB становится требованием?

Я взглянул на это:
http://www.mysqlperformanceblog.com/2009/01/12/should-you-move-from-myisam-to-innodb/
и:
http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/

Они отвечают на многие мои вопросы относительно INNODB и MyISAM. Я не сомневаюсь, что INNODB - это то, что мне нужно. Однако я работаю сам и для разработки создал виртуальный сервер LAMP (ubuntu 10.10 x64). В настоящее время сервер имеет 2 ГБ памяти и один диск SATA 20 ГБ. Я могу без особых проблем увеличить обе эти величины примерно до 3–3,5 ГБ памяти и накопителя на 200 ГБ.

Причины, по которым я не решаюсь переключиться на INNODB:
A) В статьях выше упоминается, что INNODB значительно увеличит размер таблиц, и он рекомендует гораздо больший объем оперативной памяти и дискового пространства. . Хотя в производственной среде я не возражаю против этого увеличения, в среде разработки, боюсь, я не могу приспособиться.
Б) Я действительно не вижу смысла в тонкой настройке движка INNODB на моей виртуальной машине. Скорее всего, мне даже не позволят делать это в моей производственной среде. В статьях звучит так, будто INNODB обречен на провал без точной настройки.

У меня такой вопрос. В какой момент INNODB станет жизнеспособным? Сколько оперативной памяти мне потребуется для запуска INNODB на моем сервере (только с моими данными для тестирования. Этот сервер не открыт для всех, кроме меня)? а также безопасно ли для меня предположить, что производственная среда, которая не позволяет мне точно настроить БД, вероятно, уже сама ее настроила?

Кроме того, я слишком много думаю о вещах?


mysql virtual-machine innodb lamp
person Barak Gall    schedule 09.03.2011    source источник

Ответы (2)


arrow_upward
15
arrow_downward

IMHO, это становится требованием, когда у вас есть десятки тысяч строк или когда вы можете спрогнозировать скорость роста данных.

Вам нужно сосредоточиться на настройке пула буферов innodb и размера файла журнала. Также убедитесь, что у вас включен innodb_file_per_table.

Чтобы получить представление о размере пула буферов innodb в КБ, выполните этот запрос:

SELECT SUM(data_length+index_length)/power(1024,1) IBPSize_KB
FROM information_schema.tables WHERE engine='InnoDB';

Вот оно в МБ

SELECT SUM(data_length+index_length)/power(1024,2) IBPSize_MB
FROM information_schema.tables WHERE engine='InnoDB';

Вот он в ГБ

SELECT SUM(data_length+index_length)/power(1024,3) IBPSize_GB
FROM information_schema.tables WHERE engine='InnoDB';

Я писал статьи о таком тюнинге

ЕСЛИ вы ограничены объемом оперативной памяти на вашем сервере, не превышайте более 25% установленной ради ОС.

person RolandoMySQLDBA    schedule 09.03.2011
comment
Спасибо за исчерпывающий ответ. Я все это пройду и, наверное, перейду на INNODB. - person Barak Gall; 10.03.2011
comment
Ух ты, этот расчет - безумный объем памяти для моей среды. Это рассчитывается исходя из объема памяти, который вы должны назначить пулу буферов в МБ? Вы уверены, что это не КБ? - person Tim Meers; 09.03.2012
comment
@RolandoMySQLDBA, каковы преимущества включения innodb_file_per_table? И в каких случаях они применимы? Спасибо. - person Halil Özgür; 15.05.2012

arrow_upward
1
arrow_downward

Я думаю, что вы слишком много думаете. Это правда, что INNODB любит ram, но если ваша база данных мала, я не думаю, что у вас будет много проблем. Единственная проблема, с которой я столкнулся с MYSQL или любой другой базой данных, заключается в том, что по мере роста данных возрастают требования к быстрому доступу к ним. Вы также можете использовать сжатие таблиц, чтобы они были меньше, но INNODB намного лучше, чем MYISAM, с точки зрения целостности данных.

Я также не стал бы беспокоиться о настройке вашего приложения, пока вы не столкнетесь с узким местом. Написание эффективных запросов и проектирование базы данных кажется более важным, чем память, если вы не работаете с очень большими наборами данных.

person Zen Devel    schedule 09.03.2011
comment
Спасибо за понимание. Я обязательно учту их. - person Barak Gall; 10.03.2011