Мой сайт иногда имеет довольно предсказуемые всплески трафика, которые увеличивают пропускную способность в 100 раз больше, чем обычно.Например, нас собираются показать на телевизионном шоу, и я ожидаю, что через час после шоу я получу более чем в 100 раз больше трафика, чем обычно.
Насколько я понимаю, MySQL (InnoDB) обычно хранит мои данные в разных местах:
- Буферы ОЗУ
- commitlog
- двоичный журнал
- фактические таблицы
- Все вышеперечисленные места на моем ведомом компьютере БД
Это слишком большая "долговечность", учитывая, что я нахожусь на узле EC2, и большая часть вещей проходит через один и тот же сетевой канал (файловые системыподключены к сети).Плюс диски просто медленные.Данные не имеют большого значения, и я предпочел бы воспользоваться небольшим шансом потери данных в течение нескольких минут, а не иметь высокую вероятность сбоя при прибытии толпы.
Во время этих всплесков трафика я хотел быделайте все эти операции ввода / вывода только , если я могу себе это позволить.Я хотел бы просто сохранить как можно больше оперативной памяти (у меня достаточно оперативной памяти по сравнению с объемом данных, который будет затронут в течение часа).Если буферов становится мало, или канал ввода-вывода не слишком перегружен, тогда, конечно, я бы хотел, чтобы что-то пошло в commitlog или двоичный журнал для отправки на ведомое устройство.Если и только если канал ввода-вывода не перегружен, я бы хотел выполнить обратную запись в реальные таблицы.
Другими словами, я бы хотел, чтобы MySQL / InnoDB использовал «обратную запись».«алгоритм кэширования, а не алгоритм сквозной записи».Могу ли я убедить это сделать это?
Если это невозможно, меня интересуют общие советы по оптимизации производительности записи MySQL.Большинство документов посвящено оптимизации производительности чтения, но когда я собираю толпу пользователей, я создаю учетные записи для всех из них, так что это большая нагрузка на запись.