Переход от BLOB до filestorage - MySql ухищрений

Question

Я взял проект некоторое время назад, когда двоичные файлы файла хранились в BLOB-. Это были размеры от 0,5 до 50 Мб, поэтому эта таблица была затронута как можно меньше (-> eBeans lazyloading и т. Д.). Материал BLOB работал достаточно хорошо, пока вся система работала на одном выделенном сервере, как только мы переключились на экземпляры AWS EC2 + RDS, все было (очевидно) медленнее.

Поэтому я переключился хранение данных от BLOB до S3 (+ ссылки на ведре/ключ, хранящийся в БД), что намного быстрее, для нашего внутреннего интерфейса и наших клиентов.

Теперь мой вопрос, очевидно, программист перед настройкой базы данных mySQL для обработки больших фрагментов данных (max packagesize и т. Д.), И я также наткнулся на некоторое обсуждение размера пула соединений.

Какие критические параметры, чтобы проверить в настройках MySql, и каковы эффективные способы их оценки?

Answer 1

Наиболее вероятный ответ на ваш вопрос «ничего не меняется.»

MySQL имеет много, много, много «перестраиваемых» параметров, и есть абсолютное богатство плохих советов доступных в Интернете о «оптимизации» их. Но это искушение лучше всего избегать.

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

Настройки, такие как max_allowed_packet, если они установлены слишком малыми, сломают некоторые вещи (например, крупные капли), но если набор больше, чем необходимо, будет иметь мало или совсем не повлияет ... «избыток» не выделяется или иным образом вреден. В случае max_allowed_packet это налагает ограничение на использование памяти, ограничивая объем памяти, который сервер когда-либо должен будет выделять для одного пакета, но поскольку это ограничение кирпичной стены, вы не обязательно хотите его сжать. Если вы не отправляете большие пакеты, это ничего не болит.

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

http://dev.mysql.com/doc/refman/5.7/en/packet-too-large.html

Другие параметры, однако, могут иметь резко против intuitice negative effects потому что диапазон «допустимых» значений является подмножеством диапазона «оптимальных» значений. Ключевым примером этого является кеш запросов. «Но это больше кеш! Как это может быть плохо?» Ну, больший дом увеличивает объем домашней работы, которую вы должны сделать, а кеш запросов - большой дом с одной крошечной метлой (глобальный мьютекс, который каждый поток поддерживает при входе и выходе).

Третьи, как innodb_buffer_pool_size только действительно есть один относительно небольшой оптимальный диапазон значений для данного сервера. Слишком малое будет увеличивать дисковый ввод-вывод и ухудшать производительность, потому что пул меньше, чем может поддерживать система, слишком большой увеличит дисковый ввод-вывод из-за того, что сервер использует пространство подкачки или полностью разбил его, исчерпав систему из каждых последних доступных килобайт свободной ОЗУ.

Возможно, у вас есть идея.

Если у вас нет определенного параметра, который, по вашему мнению, может быть субоптимально настроен, оставьте рабочую систему работать. Если вы меняете вещи, меняйте их по одному и доказывайте или опровергаете, что каждое изменение было хорошей идеей, прежде чем продолжить. Если вы используете значение, отличное от значения по умолчанию, рассмотрите значение по умолчанию как потенциально хорошее значение кандидата.

И держитесь подальше от «тюнинговых сценариев», которые вносят предложения по параметрам, которые вы должны изменить. На них интересно посмотреть, но их советы часто опасны. Я часто думал о написании своего собственного, но все, что он сделал бы, это проверить значения, не установленные по умолчанию, и сообщить пользователю, чтобы они объясняли себя или возвращали обратно. :) Может быть, это поймает.