Ключевой вопрос: «Почему именно выбрали Memcached»?
Понятно, что это вариант пришедший на ум сразу у вас, но ведь есть и другие варианты. Почему выбран был этот вариант? Какие причины заставили остановиться на нем?
Очень надеюсь, что выбор пал не по принципу «вот я тут вспомнил про Memcached»…
Если честно, больше выбирать особо не из чего.
Есть файлы. Есть xCache. Есть другие, более редкие способы.
С memcached я работал и ранее, правда, немного менее плотно. Он работает на куче сайтов, начиная от хабра, заканчивая facebook.com и livejournal.com (для которого и разрабатывался). Поэтому, выбор пал именно на него.
В России большинство (точных данных у меня нет) ездит на ВАЗе. Не потому что это хорошая машина, а потому что доступная. Аналогично и с софтом: доступный, популярный, легкий в освоении — не значит лучший.
В моей работе на данный момент важна стабильность и уверенность в технологии. Поэтому я выберу мемкешед. Не потому что он лучший, а потому что знаю его лучше всего.
Как только у меня будет проект, где можно будет вволю экспериментировать, я буду искать нечто другое. Например, меня совершенно не устраивает отсутствие нормальной репликации и тех же самых тегов.
Очень легко критиковать не предлагая ничего взамен.
Имеете на примете лучшую систему? Имеете опыт работы с другими более удобными?
Тогда предложите, или напишите статью. А так ваш коментарий демагогия.
В чём преимущества?
Почему кто-то должен выбрать именно ваше решение?
Для каких приложений лучше использовать?
Чего пытаетесь достичь?
Пока не будет ответов, а их нет на сайте, это будет вашей личной самоделкой которой маловероятно что кто-то воспользуется.
Кто говорил о моём решении? Список API для работы с shared memory (и аналогами) видели? Вот что-нибудь из этого и используйте.
Строчка копирайта там потому что именно так оформлялись PEAR модули в то время. А ваши слова про профи и школьников забавны :) Вы, вероятно, не знаете кто я :)
memcached обладает рядом недостатков, поэтому выбирать его нужно осознавая его отрицательные стороны, а именно:
1) «корзины», это значит данные на 1025 байт займёт 2КБ
2) выталкивание, когда заканчивается память: вы не контролируете какая из корзин исчезнет, когда закончатся корзины какого-то размера
3) работа через сокет, что оправдано, если память используется на другой машине и не оправдано, если использовать локально.
осталось дописать две вещи
1. «не уничтожение» устаревших тэгов если генерация уже идет( читаем тогоже смиру про одновременое перестроение)
2. «полное уничтожение данных» — так как евикшен у мемкешеда скажем так хреновый — реализуем свой обход всех сотен миллионов ключей и стирание лишнего.
про это скоро напишу топик — но крайне не желательно чтобы кешед был заполнен более чем на 75%( максималка у него 85%) так как он начинает дропать ключи малек не верно — иногда новые дропает а не старые
Memcached и метки. Реализация для фреймворка Kohana