Comments 44
и почему они, интересно, не сделали это в стандартном API?
Наверное потому, что это приведет к падению производительности, а задача memcache — быть максимально быстрым
Советую смотреть в сторону memcachedb, возможно там есть нужный функционал
Советую смотреть в сторону memcachedb, возможно там есть нужный функционал
В MemcacheDB тоже нет такого функционала.
Я бы советовал смотреть в сторону Redis'a [ code.google.com/p/redis/ ]
Я бы советовал смотреть в сторону Redis'a [ code.google.com/p/redis/ ]
я бы не советовал смотреть ни в редис ни в мемкешбд
А на что тогда?
key-value для таких задач не предназначены т.к. идеология в том что сложность операций при работе с ними не больше O(1). Кеш сканировать по идее не нужно. Если все-таки нужно то где-то ошибка в архитектуре приложения.
мемкешбд и редис кроме всего прочего сами по себе на практике довольно кривые.
Если нужно сканирование то надо использовать бд а не кеш и нормальные индексы — это либо в реляционных бд, либо в документоориентированных бд.
мемкешбд и редис кроме всего прочего сами по себе на практике довольно кривые.
Если нужно сканирование то надо использовать бд а не кеш и нормальные индексы — это либо в реляционных бд, либо в документоориентированных бд.
может сиськи?
Мы использовали его в качестве хранилища счетчиков и отказались из-за deadlockов, получаемых при сбросе данных из памяти в хранилище.
memcached — это сервер кешинга в памяти, он может использоваться несколькими приложениями. Мне кажется это из соображений безопасности.
Мдас, перешурстите мои пару миллионов ключей с десятка серверов кешеда.
Повторюсь конечно, но молимся на тэги smira
Повторюсь конечно, но молимся на тэги smira
UFO just landed and posted this here
Спасибо за решение.
Может быть теперь получится реализовать очистку кеша по маске.
Может быть теперь получится реализовать очистку кеша по маске.
Вы не представляете, как я вам благодарен.
А не проще ли хранить все нужные тебе ключи в массиве по отдельному ключу, ну т. е. пользоваться стандартными средствами мемкешеда?
Т. е. записал в мемкешед ключ1-значение1, ключ2-значение2, ..., ключN-значениеN, а по ключу keys-[ключ1, ключ2, ..., ключN] или даже keys-[ключ1-времяЖизни1, ключ2-времяЖизни2, ..., ключ3-времяЖизни3].
В процессе работы просто пушим в массив keys новые ключи, а когда нужно, считываем, агрегируем (чтобы исключить уже умершие ключи) и обновляем keys в самом мемкешеде.
Т. е. записал в мемкешед ключ1-значение1, ключ2-значение2, ..., ключN-значениеN, а по ключу keys-[ключ1, ключ2, ..., ключN] или даже keys-[ключ1-времяЖизни1, ключ2-времяЖизни2, ..., ключ3-времяЖизни3].
В процессе работы просто пушим в массив keys новые ключи, а когда нужно, считываем, агрегируем (чтобы исключить уже умершие ключи) и обновляем keys в самом мемкешеде.
>В процессе работы просто пушим в массив keys новые ключи, а когда нужно, считываем, агрегируем (чтобы исключить уже умершие ключи) и обновляем keys в самом мемкешеде.
1) если ключей данное поле станет большим и не поворотливым
2) и вообще это работать не будет, тк в случае одновременного запроса к элементу keys 2х или более процессов, и последующем обновлении, целостность данных нарушится
1) если ключей данное поле станет большим и не поворотливым
2) и вообще это работать не будет, тк в случае одновременного запроса к элементу keys 2х или более процессов, и последующем обновлении, целостность данных нарушится
1. Уверен, что контент который в обычных условиях храниться в мемкеше намного привысит по объему массив самих ключей, даже если у Вас этот массив будет в несколько кБ.
2. Тут так же применимы все техники работы при конкурентном доступе.
Т. е. Вы считаете, что метод топикстартера лучше будет работать с большими объемами ключей и в условиях конкурентного доступа?
2. Тут так же применимы все техники работы при конкурентном доступе.
Т. е. Вы считаете, что метод топикстартера лучше будет работать с большими объемами ключей и в условиях конкурентного доступа?
считаю (уверен), что оба варианта работать при больших объемах и конкуренции работать не будут.
нужен другой подход, по типу хеш-таблицы. В общем, в комментарии суть не вместить, как будет время, напишу пост
нужен другой подход, по типу хеш-таблицы. В общем, в комментарии суть не вместить, как будет время, напишу пост
Где вы хеш-таблицу хранить думаете? И как реализацию делать? Если все делать стандартными средствами и хранить данные в самом мемкеше — так я о том и писал, просто реализацию самую простую предложил.
А если дорабатывать сам мемкеш, добавляя ему соответствующий функционал, так проще не изобретать велосипед, а применить другой инструмент, из тех что тут в комментах опоминали или поискать другой.
А если дорабатывать сам мемкеш, добавляя ему соответствующий функционал, так проще не изобретать велосипед, а применить другой инструмент, из тех что тут в комментах опоминали или поискать другой.
Вот, то что Вам нужно. Linux
PHP Client Comparison
Как я понял есть 2 разных библиотеки для работы с memcache из под php (pecl/memcache и pecl/memcached). А в чем их принципиальное отличие? (сорри с английским не всё так хорошо)
Как я понял есть 2 разных библиотеки для работы с memcache из под php (pecl/memcache и pecl/memcached). А в чем их принципиальное отличие? (сорри с английским не всё так хорошо)
Это конечно замечательно, но ахтунг: stats cachedump выдает лишь часть данных (что-то коло 200к ключей, насколько я помню). Если у вас весь кэш помещается в это количество, тогда ура, если нет — нарветесь на проблемы, если будете рассчитывать, что возращен весь кэш.
Кроме того, выполнение cachedump полностью блокирует на время выполнения все остальные запросы, что совершенно некошерно на неблокирующем по определению кэшере.
Именно по этим причинам этих функций и нет в различных API. Формально memcached ничего не знает о структуре хранимых им ключей.
Кроме того, выполнение cachedump полностью блокирует на время выполнения все остальные запросы, что совершенно некошерно на неблокирующем по определению кэшере.
Именно по этим причинам этих функций и нет в различных API. Формально memcached ничего не знает о структуре хранимых им ключей.
Чтобы к такой проблеме прийти — нужно вначале нагадитьнакодить так чтобы эти ключи потерять.
Последнее время memcached применяют где надо и где не надо. Почитайте FAQ на сайте memcached, там ясно написано почему не стоит выгребать все ключи из сервера.
Хм, ваша функция возвращает пустой массив, а getStats('cachedump') — FALSE.
Всё на локалхосте.
Интересно, почему?
Всё на локалхосте.
Интересно, почему?
Ужс! Представляю как приложение, использующее этот метод сломается, как только кол-во ключей зашкалит за 10К.
Не стоит изобретать велосипед. используйте теги
Не стоит изобретать велосипед. используйте теги
Sign up to leave a comment.
Memcached. Как найти ключи по паттерну?