из - http://www.readwriteweb.com/hack/2011/04/you-got-nosql-in-mysql-memcach.php
(поправьте меня, если не имеет смысла)
потенциальные преимущества
сохранение сложного расчета запроса в распределенной среде
Избегайте повторных запросов и, вероятно, наиболее выгодно при наличии нескольких серверов (более 5 серверов баз данных) - запросите один раз, сохраните в memcached и повторно используйте навсегда
innodb имеет размер внутреннего буферного пула,
имеет ли смысл использовать memcached в качестве дистрибьютора?
однако я думаю, что доступ к локальной RAM намного быстрее, чем в распределенной среде
Есть предположения?
ИМХО, эти два механизма должны быть правильно сбалансированы и никогда не должны рассматриваться как взаимоисключающие. Причина ???
memcached - это хорошо управляемая схема памяти для хранения данных с использованием пользовательских тегов. Это устраняет необходимость в интенсивном дисковом вводе-выводе.
InnoDB - это ACID-совместимый механизм хранения, который использует MVCC (мультиверсионный контроль параллелизма), чтобы разрешить тяжелые транзакционные операции чтения и записи. Имея достаточно памяти, вы можете хранить свой рабочий набор данных в ОЗУ, исключив дисковый ввод-вывод.
Если вы объедините их в полную силу, их сильные стороны в лучшем случае сведут на нет преимущества друг друга. Я могу заявить с абсолютной уверенностью, потому что InnoDB будет кэшировать все данные и индексировать страницы, к которым осуществляется доступ, в то время как memcached будет хранить те же пользовательские данные.
Memcached не будет хранить информацию индексной страницы, которую InnoDB будет иметь в своем буферном пуле.
Memcached будет хранить только точные необходимые данные. Страницы данных InnoDB могут содержать данные из других строк таблицы.
InnoDB упрощает получение диапазонов данных лучше, чем memcached, поскольку memcached должен проходить через уровень БД в качестве дополнительного шага.
Два продукта должны стать похожими на супружескую пару (Простите за метафору, я счастлива в браке 16 лет). Каждый партнер должен настроить свои сильные стороны, чтобы приспособиться к другому и достичь идеального баланса во всем. Так и с InnoDB (сильная жена) и Memcached (сильный муж).
InnoDB может выделить столько оперативной памяти, сколько необходимо, исходя из суммы всех страниц данных и индексов или 75% установленной оперативной памяти, в зависимости от того, что меньше. Memcached, хотя и требует меньше предварительной памяти, может потребовать некоторой формы прогнозирования, чтобы выяснить, сколько памяти нужно подготовить для обработки.
Также имейте в виду, что когда дело доходит до тяжелых чтений, страницы данных и индекса в InnoDB станут довольно устаревшими в использовании (но актуальными по содержанию) из-за доступа к частям ОЗУ вне пула буферов InnoDB для того же данные, которые также находятся в буферном пуле InnoDB. Таким образом, запись в memcached, которая затем риккоширует данные в InnoDB, по-прежнему будет запускать возможный дисковый ввод-вывод. Способность InnoDB обеспечивать быстрое чтение забирается memcached. В том же потоке управления InnoDB требуется только при записи и регистрации небольших транзакций, чтобы обеспечить восстановление после сбоя. (ЧЧЧММММ, это действительно похоже на мужа (он делает все заранее и должен признавать и любить свою жену) и жену (выручает мужа, но сохраняет его достоинство), не так ли ???)
ВЫВОД
Если вы правильно спрогнозируете, сколько данных будет хранить memcached, вы можете масштабировать InnoDB в процентах от общей необходимой оперативной памяти memcached (то есть, если вы планируете использовать 8 ГБ ОЗУ для memcached, работайте с 6 ГБ или меньше для пула буферов InnoDB). В совокупности их использование памяти должно быть меньше общего установленного ОЗУ. Как только этот баланс будет достигнут, InnoDB и memcached будут полностью дополнять друг друга.