Доклад на PHPConf 2008: Технология тэгирования для memcached в высоконагруженных

Доклад Д.Котерова ...

  • включить в программу

    Голосов: 5 33,3%
  • тема для флипчарта

    Голосов: 9 60,0%
  • не включать

    Голосов: 1 6,7%
  • укажу в топике

    Голосов: 0 0,0%

  • Всего проголосовало
    15
  • Опрос закрыт .

confguru

ExAdmin
Команда форума
Доклад на PHPConf 2008: Технология тэгирования для memcached в высоконагруженных

Так как программа уже почти сформирована - выношу на голосование в массы..


Технология тэгирования для memcached в высоконагруженных
проектах

Дмитрий Котеров [dk]
МойКруг: сооснователь, руководитель разработки
автор книг «Самоучитель PHP4» и «PHP5»,
ведущий проекта «Лаборатория dk» (http://dklab.ru/)

Работа с типичной кэширующей системой (в том числе с memcached) заключается
в выполнении трех основных операций: save(data, id, lifetime), load(id) и
remove(id). Когда источник данных, сохраняемых в кэш, изменяется,
соответствующие ячейки кэша очищаются отледбным запром remove(). На практике
логика отслеживания зависимостей и проверки, какие ячейки кэша нужно
очищать, а какие ― нет, в сложных приложениях становится крайне запутанной
(а то и вовсе нереализуемой). Ситуацию усложняет то, что в нагруженной
системе данные в таблицах БД могут меняться десятки и сотни раз в секунду,
поэтому "грубых" алгоритмов очистки кэша (например, по дате последнего
изменения таблицы БД) становится явно недостаточно.

Технология тэгирования кэша, описанная в докладе, предоставляет решение этой
проблемы. Каждый раз, когда данные записываютя в некоторую ячейку кэша, мы
помечаем их тэгами ― пометками, представляющими зависимости этих данных от
других частей системы. Тэги как бы позволяют объединять ячейки в
множественные пересекающиеся группы. В дальнейшем мы можем дать команду
"очистить все ячейки, помеченные определенным тэгом". Добавить
функциональность тэгирования кэша позволяет рассмотренное в докладе
семейство библиотек Dklab_Cache_Backend, работающее совместно с подсистемой
Zend_Cache из Zend Framework.
http://dklab.ru/lib/Dklab_Cache/

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

-~{}~ 28.04.08 10:18:

голосуем активнее..
 

Фанат

oncle terrible
Команда форума
В прошлый раз, насколько я помню, котеров совсем облажался с докладами. не будет ли и в этот раз изложение общеизвестных фактов и "приходите к нам работать" в конце?

И уж по мемкешу, по-моему, у нас и своих спецов имеется. Лучше бы их, может быть, пригласить?
 

korchasa

LIMB infected
Не очень понятно при чем здесь memcache. Главная идея - управление данными в кэше с помошью тэгов. Причем, ИМХО, не очень большая тема, и вряд ли на доклад тянет.
 

confguru

ExAdmin
Команда форума
Флипчарт автор не хочет.. не уложится во время..
И программа уже опубликована.. :)
 

fixxxer

К.О.
Партнер клуба
г-н Котеров любит на пустом месте развести полемику на три часа... :)
по сути вопроса - тем, кому это надо достаточно ссылки http://code.google.com/p/memcached-tag/, а остальным просто не надо =)

-~{}~ 29.04.08 22:57:

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

-~{}~ 30.04.08 17:26:

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