memcached представляет собой высокопроизводительную распределенную систему кэширования объектов в оперативной памяти.

Оформлена она в виде классического daemon'а, слушающего подключения на одном из TCP-портов (по-умолчанию: 11211). Работа же с ним осуществляется с помощью клиентских библиотек, доступных практически для всех популярных языков программирования.

memcached не использует конфигурационные файлы, но все же может быть в какой-то степени настроен под свои нужды с помощью параметров, указываемых при запуске daemon'а, и переменных окружения. Например, часто используется параметр -m, позволяющий указать объем используемой для хранения объектов оперативной памяти.
По сути кэширование с помощью memcached представляет собой некое подобие глобального ассоциативного массива, то есть набора соответствий ключ → объект.

Как же оно работает?

Принцип очень прост: после установления соединения между клиентом (произвольное приложение, воспользовавшееся услугами одной из клиентских библиотек) и сервером (распределенной системой, состоящей из daemon'ов), клиенту предоставляется возможность выполнять четыре примитивных действия для организации кэширования:

• set — установить соответствие между ключом и указанным объектом;
• add — аналогично set, но только при условии, что объекта с таким ключом в кэше нет;
• replace — абсолютная противоположность add, выполняется только если такой объект в кэше есть;
• get — получить объект из кэша по указанному ключу.

Вывод напрашивается лишь один: проще не придумаешь.

В сравнении

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

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

На практике

Использование memcached на практике в написании приложений ничуть не сложнее, чем в теории. Например, если говорить о PHP, то для доступа к daemon'y достаточно установить соответствующий PECL extension, который предоставит класс Memcached. С помощью его методов осуществляется доступ ко всем возможностям memcached, о которых я уже упоминал: connect, set, add, get и так далее.

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

О чем не стоит забывать

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

В заключении

...хотелось бы сказать, что эта технология является очень производительным и эффективным решением вопроса кэширования для масштабных интернет-проектов. Возможности по ее применению не ограничиваются Сетью, ведь она реализована в виде обычного daemon'а, что открывает ее для всего спектра программного обеспечения, так или иначе следующего «Unix way».

Добавить в социальные закладки

• Blink
• del.ici.ous
• Digg
• Furl
• Google
• Simpy
• Spurl
• Y! MyWeb
• БобрДобр
• Мистер Вонг
• Яндекс.Закладки
• Текст 2.0
• News2
• AddScoop
• RuSpace
• RUmarkz
• Memori
• Закладки Google
• Писали
• СМИ 2
• Моё Место
• Сто Закладок
• Ваау!
• Technorati
• RuCity
• LinkStore
• NewsLand
• Lopas
• Закладки - I.UA
• Connotea
• Bibsonomy
• Trucking Bookmarks
• Communizm
• UCA

[quote comment="233"]Скажите а есть ли еще какие-то столь же простые и удобные технологии для повышения производительности в нагруженных проектах? Которые можно например использовать в связке с мemcached?[/quote]

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

Как обычно я выступлю с вопросом о примере юзкейса. Техническая сторона освещена, но как это используется в интернет проектах на практике?

Ну хоть один пример.

Спасибо.

Про LJ спасибо посмотрел. Все же как-то поверхностно

Сейчас я попытаюсь пояснить суть своего вопроса.

У меня есть прогрмма в разработке: математическая модель фирмы. Данная программа имеет большой объем данных, которые вычисляются рекурентно. Я пошел по пути полной нормализации - хранятся только управляющие параметры, все остально считается. Если не использовать никаких методик повышения производительности, то расчеты проводятся чудовищно долго. Кеширование НЕИЗМЕННЫХ данных на каждом уровне рекурсии повзволяет на порядки повысить производительность (эдак порядка на 4 )

У меня примерно так - перед расчетом я проверяю не увеличился ли timestamp со времени последнего расчета? Если увеличился, то делаю перерасчет, если нет, то использую старые данные.

К чему это я и почему я выделил слово «неизменных»? Потому, что я в своей модели знаю, что данные неизменны, потому я их и кеширую.

ТЕПЕРЬ О MEMCAHCED. Под примером я просил вот что. При использовании систем кеширования возникает вопрос - пересчитывать ли данные или брать из кеша. Как это сделано у меня я сказал. Мне был бы интересен в деталях пример того, как, скажем, тот же LJ, решает - обращаться ли к MySql или брать из кеша. Какой критерий можно использовать? Как узнать, что данные с момента последнего расчета не изменились и их можно брать из кеша?

—

Прошу прощения за ошибки. Просто у меня в оперет размер символов равен примерно 5-6 кеглей (как муравьи ).

Идейно, я думаю, здесь сложно выразиться не ясно: идейно все ясно и понятно.

Я алгоритм представляю примерно так:

1. Клиент обращается с запросом — например, вывести состояние корзины заказов.

2. Сервер строит результат. Результат возвращается клиенту.

3. Сервер создает на основе параметров запроса некий ключ (хоть CRC считает). Под этим ключом данные попадают в кеш.

4. При следующем запросе сервер сначала ищет ключ в кеше, если нашел, то возвращает результат клиенту, если не нашел, то см. п. 2.

При этом — каким образом данные обновляются в кеше? Я так понимаю, что в пред. список надо добавить п. 3.5: клиент изменил позиции в своей корзине, при этом нужно: а) сделать изменения в БД; б) удалить все возможные кешированные данные, которые зависят от проводимых в БД изменений.

Наверное примерно так?

Зачем такие сложности? Алгоритм работы в общем случае укладывается в мой предыдущий комментарий, а конкретно для Вашего примера достаточно просто приделать memcached к PHP в качестве обработчика сессий, в котороых и хранить состояние корзины (дублирование в базу данных до подтверждения заказа излишне).

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

[quote comment="251"]>> (дублирование в базу данных до подтверждения заказа излишне)

ну это зависит от задачи. www.books.ru, например, хранит мою корзину без подтверждения.[/quote]Только хранит ее не сайт, а браузер в виде cookies.

[quote comment="251"]ну собственно один из алгоритмов, которые я нарыл за последние 2 часа таков: если нужно актуализировать состояние кеша в соответствии с изменениями в БД, то можно сделать тригер, в котором сливать изменения в спец. таблицу, потом вытигивать данные из таблицы и затирать устаревшие значения в кеше.[/quote]Не вижу ни одного преимущества такого подхода перед занесением в кэш новой информации одновременно с запросом в базу данных. Хотя конечно же это не означает, что их нет...

[quote comment="253"]хранит их все-таки сервер. я обычно карзину набираю в течении месяца с 3 разных компьютеров. не в кукисах дело. к тому же я их чищу раз в неделю везде.[/quote]Хм, возможно конечно, но мою он благополучно очистил, после удаления соответствующих cookies (возможно просто так как я не удосужился зарегистрироваться). Хотя не в этом конечно суть, если магазин считает содержимое корзины важной информацией, то никто запретить ему хранить эту информацию не может.

[quote comment="259"]> возможно просто так как я не удосужился зарегистрироваться

ну это же чертовски логично — под каким ключем сервер должен держать ваши данные, если нет регистрации? серийный номер винта? мак-адрес?[/quote]Сложно поспорить, хотя я если честно вообще не вижу смысла эту информацию хранить =)

[quote comment="259"]Однако вопрос инвалидации кеша стоит все же остро. О сбросе кеша я задумывался и раньше, когда думал о кеше. И в общем случае не нашел решения, кроме того, чтобы в деталях разбирать КАЖДЫЙ updata или insert в БД, а имеено — на какие данные он повлияет. Нужно определять ВСЕ возможные сохраненные данные, которые зависят от проводимого update или insert.[/quote]Я для себя этот вопрос решил просто исключением возможности нормализацией базы ровно до той степени, что необходимость в подобных проверках отпала (правда я это заранее сделал, но не суть...)

[quote comment="259"]ВОПРОС. Иван, не заете ли Вы открытых исходников, которые используют MC?[/quote]Да все тот же LiveJournal, на их сайте из SVN можно забрать.

Возможно мы о чем-то разном говорим, я как раз стараюсь избегать зависимости хранимых данных от чего-либо, кроме Primary Key в таблице, или ключа в кэше (в Вашем примере — курса), что собственно говоря в теории реляционных СУБД и называют нормализацией. Где я не прав?

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

[quote comment="490"]Насчет сброса кеша: самый простой и эффективный алгоритм — задавать время жизни кэша. То есть сидит некий демонок, у которого записано: вот эту группу ключей хранить 1 минуту, а вот эту — день. как время истекло, он трёт соотв. ключи. Если они никому бельше не нужны были — и ладно, если данные в кеше востребованы, то они перегенерятся заново из БД.

Да, есть накладки по производительности (если данные не изменились, но были потёрты — запрос опять к СУБД пойдет), но они решаются грамотным распределением времен жизни кэша.[/quote]

Memcached прекрасно это умеет собственными средствами, не об этом разговор был...

Неужели ответ: Выделенный сервер с 1 ТБ оперативки , слушающий на TCP 11211 ?

А если веб серверов становится уже 100 и один memcached сервер с ними не справляется, то нужно делить веб сервера на группы с отдельными memcached серверами?

Хотелось бы почитать чьё-то мнение по этому поводу...

2Дмитрий Тимохов:

если вам не обязательно соблюдать требования свободного ПО для своей задачи, вполне возможно подойдут «материализованные представления» Оракла (предпочтительнее), или «индексированные представления» MS SQL

[quote comment="516"]Все просто:

...

Быстро и эффективно.[/quote]

Спасибо!!!

[quote comment="525"]Можете еще раз в трех словах объяснить принцип? Допустим у меня есть база из нескольких таблиц размером в 1000 000 записей. При этом выборка с объединением по некоторым условиям производится долго. Что мне нужно, чтобы проверить — если такой результат уже выбран — берем из кеша, если нет — задаем запрос?

То есть в трех словах, как это работает на пальцах. И еще — каким образом информировать, что база была обновлена, а именно, что участвующие в результате запроса записи обновлены и надо их удалить из кеша?[/quote]

Кэшируются не запросы, а объекты любого языка программирования, с кэшированием запросов прекрасно справляются сами СУБД.

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

Правда сомневаюсь что такой подход наиболее эффективен (особенно при частых обновлениях старых данных), я обычно предпочитаю делать выборки по id строк, а потом уже каждую строку отдельно вытаскивать из memcached, а кэширование выборок оставить на совести СУБД (или вообще без него обойтись).

[quote comment="532"][quote comment="525"]...При этом выборка с объединением по некоторым условиям производится долго. ...[/quote]

Тут появилась идея что в случае удаления кэша несколько веб-процессов одновременно могут постараться его обновить, а так как процесс генерации долгий, то это может нагрузить базу одинаковыми запросами от разных клиентов. Я бы отдал задачу обновления кэша асинхронному процессу с собственной логикой слежения. В данном варианте веб-скрипты должны читать только кэш, а к базе не обращаться.[/quote]Если данные приложения обновляются настолько часто, что возможно возникновения таких ситуаций, то стоит задуматься об отказе от кэширования этих данных. А асинхронные процессы конечно тоже можно инициализировать, но нужно ли?

[quote comment="717"]А как решать вопрос транзакций? Т.е. обновляем данные в базе, в кеше.

Но в случае ролбека данные в кеше остаются недостоверные.[/quote]От конкретного приложения зависит... либо не трогать кэш до commit'а, либо обновлять его параллельно с транзакцией, но в случае rollback'а принудительно синхронизировать с откатившейся базой все потенциально затронутые этим процессом объекты. Или, как вариант, можно держать в кэше две версии нужной части данных: текущую и на момент на начала транзакции, в случае rollback'а достаточно будет просто подменить одну другой (но это будет эффективно, возможно, только при большой вероятности окончания транзакции rollback'ом).

До каких пор кэшировать... Тут вопрос в том что есть базовые сущности — объекты которые безусловно кэшируются (по сути сроки таблиц: мембера, заметки, ресторана и тд), и есть допустим «вспомогательные» сущности(модели), которые формируются из разных таблиц путем объединения, и тд. Их тоже хранить? или писать статические «классы-хелперы», которые будут выбирать и компоновать «вспомогательные» сущности непосредственно в коде из закэшированых базовых сущностей.

Пока писал, кое что понял), но интересно ваше мнение — кэшировать строки таблицы и/или «вспомогательные» сущности(модели) которые более затратны по выборке, но менее используемы?

Примерное месяца назад стал использовать мемкэш для разработки системы обмена сообщений между пользователями сайта. Вместе с UPDATE и memcache оказалось очень эффективной системой.

Если кэш вдруг исчезнет то всегда придет на помощь база данных.

Выигрыш: при частом обмене сообщений — только один быстрый запрос на UPDATE и ВСЕ!!!

при мыслях об использовании мемкеша помните важные ограничения:

ключи не более 250 байт,

данные не более 1мб на ключ.

[quote comment="1433"]при мыслях об использовании мемкеша помните важные ограничения:

ключи не более 250 байт,

данные не более 1мб на ключ.[/quote]

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

[quote comment="1434"]народ, подскажите плиз, можно ли использовать memcached для хранения сессий если серверов несколько? у меня есть один прокси сервер и 3 backend сервера которые обрабатывают только PHP запросы. сейчас сессии лежат в БД что существенно присаживает базу (отдельный сервер). хочу перенести сессии в кеш, но как их синхронизировать между серверами — незнаю. и как-то не нашел никаких толковых решений. переопределял сам обработку сессиий в РНР, коннектился ко всем демонам, клал туда одинаковые данные...

чувствую что-то здесь не так [/quote]Зависит от языка программирования, но в целом можно, при желании можно даже нагуглить готовые решения.

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

По поводу инвалидации, можно сделать кэширование запросов, касающихся определенного пользователя (пользоватлей), а при записи, зная, какой (какие) пользователи затрагиваются, вычищать кэш. Не очень сложно, но довольно эффективно, т.к. даже при частых записях в БД, каждый конкретный пользователь почти всё время читает.

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

CyberMax, не будут, смысл есть.