Comments 19
Эм… А теги чем не угодили?
насколько я помню, теги — плюшка от ZF?
Лично мне с ним работать не по душе, от того и использую свои велосипеды (может кому пригодится). А вообще принцип работы практически идентичен.
Лично мне с ним работать не по душе, от того и использую свои велосипеды (может кому пригодится). А вообще принцип работы практически идентичен.
Ни разу…
Просвятите дурака?
dklab.ru/lib/Dklab_Cache/ — как пример. Вообще, инфы в сети много, мне «в наследство» досталась либа для мемкеша с тегами. ZF не использую, сравнить не могу.
К сожалению, memcached не поддеживает тэгирование ключей, а потому код, следящий за валидностью кэша, подчас становится очень сложным.
Если в вашем проекте Zend Framework не используется (в том числе по принциальным соображениям), не расстраивайтесь. Совершенно не обязательно подключать весь Zend Framework, чтобы работать с его подсистемой кэширования. Вы можете взять только несколько необходимых файлов; они, в частности, содержатся в дистрибутиве данной статьи. Конечно, вам следует вначале прочитать документацию по кэшированию в Zend Framework на русском языке.
Как бы намекает о принадлежности к ZF
Как-бы я пример дал =). github.com/kohana/cache — тогда это посмотрите, точно ZF не используется.
Да, это уже интереснее. Вот плагин, используемый в кохана, если вдруг кому интересно http://code.google.com/p/memcached-tag/wiki/HowToUseMemcachedTag. Но мой велосипед мне нравится больше (наверное потому, что родной:))
Теги все-же удобнее получаются — не надо следить за параметрами и пр. Ну и база для параметров не нужна.
Возможно. Но лично я бы не был так категоричен. Сравнить бы производительность кеша с и без тегов, тогда будет разговор. А так… удобнее вообще ничего не делать:)
В той реализации, которую я использую, сторонние плагины не используются. Все на уровне php. Да и ссылку по кохане Вы дали неверную, вот правильная: code.google.com/p/memcached-tags/
По поводу скорости — я не говорил про скорость работы, хотя и думаю, что с тегами будет быстрее, особенно на большом количестве пользователей, т.к. у вас понадобятся несколько подключений к mongodb. Я говорил про удобство — с тегами удобнее, чем ваш пример. Вот простая иллюстрация:
// Записываем список пользователей, с id = users и тегами (users, user_1, user_2, user_3, user_4, ...)
$cache -> save('users', $users, array_merge(array('users'), extract_array($users, '{n}.id', 'user_')));
// удаляем кеш, который сохранили выше
$cache -> clean('user_10');
Разве не удобно? При этом, работаем только с памятью.
По поводу скорости — я не говорил про скорость работы, хотя и думаю, что с тегами будет быстрее, особенно на большом количестве пользователей, т.к. у вас понадобятся несколько подключений к mongodb. Я говорил про удобство — с тегами удобнее, чем ваш пример. Вот простая иллюстрация:
// Записываем список пользователей, с id = users и тегами (users, user_1, user_2, user_3, user_4, ...)
$cache -> save('users', $users, array_merge(array('users'), extract_array($users, '{n}.id', 'user_')));
// удаляем кеш, который сохранили выше
$cache -> clean('user_10');
Разве не удобно? При этом, работаем только с памятью.
Одна из вариаций реализации тегов — это просто автоинкрементные счётчики. Т.е. для сброса всех данных, принадлежащих кэшу, нужно будет лишь сделать inc(tagname).
«Mongodb + memcached» — в этой цитате что-то коробит, а что — не могу понять.
может быть эта картинка
www.mongodb.org/download/attachments/590394/featuresPerformace.png?version=12&modificationDate=1258579871490
сбила меня с толку и намекает, что использование мемкеша для монго — бесполезная в плане буста производительности трата времени программиста?
может быть эта картинка
www.mongodb.org/download/attachments/590394/featuresPerformace.png?version=12&modificationDate=1258579871490
сбила меня с толку и намекает, что использование мемкеша для монго — бесполезная в плане буста производительности трата времени программиста?
если использовать монго в качестве всего backend хранилища и отказаться от кеширования, то вам грозит очень быстрый расход оперативной памяти при больших объемах объектов. Мемкеш по сравнению с монго ест намного меньше.
К слову, в своих проектах выборки из монго я так же кеширую в мемкеш, что дает не большой, но всеже прирост в производительности.
К слову, в своих проектах выборки из монго я так же кеширую в мемкеш, что дает не большой, но всеже прирост в производительности.
И кстати в статье описывается использование монго для мемкеша, а не наоборот. Простите, сразу не приметил)
>В наше время огромного количества числа людей, которые думаю что у них высоконагруженные проекты…
починил.
починил.
Да, вы думайте — это полезно. И да, кстати, проектов таки реально много: народ массово с денди в интернет лезет. Вот такая вот несправедливость.
Понимаете, само понятие «высокая нагрузка» сравнительное. Оно подразумевает отличие от нагрузки большинства других сайтов. Таких проектов не может быть много по определению.
Я бы переформулировал так:
«в наше время, когда народ пытается из 100$-ового сервера выжать производительность 1000$-го, только кеширование всего на свете, как наиболее дешевое решение с точки зрения затрат на разработку, спасает положение».
Я бы переформулировал так:
«в наше время, когда народ пытается из 100$-ового сервера выжать производительность 1000$-го, только кеширование всего на свете, как наиболее дешевое решение с точки зрения затрат на разработку, спасает положение».
По поводу «высокой нагрузки»: если понимать это в прямом смысле, то да вы правы. Но принято нынче любой проект с более менее высокой посещаемостью называть высоконагруженным (причем посещаемость для попадания в «высоконагруженные» каждый определяет по собственным предпочтениям:) )
А перефразировка годится. Тем более в наше нелегкое кризисное время :)
А перефразировка годится. Тем более в наше нелегкое кризисное время :)
Sign up to leave a comment.
Умное удаление кеша (php 5 + Mongodb + memcached)