Memcached. Как найти ключи по паттерну?

[zed_0xff]

и почему они, интересно, не сделали это в стандартном API?

[Andrey_Rogovsky]

Наверное потому, что это приведет к падению производительности, а задача memcache — быть максимально быстрым
Советую смотреть в сторону memcachedb, возможно там есть нужный функционал

[kutsy]

В MemcacheDB тоже нет такого функционала.
Я бы советовал смотреть в сторону Redis'a [ code.google.com/p/redis/ ]

[pgrishin]

я бы не советовал смотреть ни в редис ни в мемкешбд

[kutsy]

А на что тогда?

[pgrishin]

key-value для таких задач не предназначены т.к. идеология в том что сложность операций при работе с ними не больше O(1). Кеш сканировать по идее не нужно. Если все-таки нужно то где-то ошибка в архитектуре приложения.

мемкешбд и редис кроме всего прочего сами по себе на практике довольно кривые.

Если нужно сканирование то надо использовать бд а не кеш и нормальные индексы — это либо в реляционных бд, либо в документоориентированных бд.

[Becoming_Insane]

согласен.

юзайте теги и не будет вам нужды найти «по маске»

[aib]

может сиськи?

[prn]

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

[pgrishin]

а что используете теперь?

[prn]

просто memcache, с последующим переносом данных в субд

[pgrishin]

данные потерять не страшно? почему тогда редис не используете — он примерно так же работает?

[prn]

Потеря данных с той долей вероятностью, с которой это может произойти допустима. С редисом из команды ни кто не знаком, а на эксперименты и тестирование новых продуктов время не всегда есть
Перенос в бд происходит раз в сутки, поэтому это «примерно» также работает

[ustav]

memcached — это сервер кешинга в памяти, он может использоваться несколькими приложениями. Мне кажется это из соображений безопасности.

[zed_0xff]

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

[kashey]

Мдас, перешурстите мои пару миллионов ключей с десятка серверов кешеда.
Повторюсь конечно, но молимся на тэги smira

[kutsy]

Тэги smira?
Если можно — по-подробнее.

[kashey]

великий и ужастный

[kutsy]

Спасибо.

Проблема в том, что если так делать, то увеличится количество запросов, а отсюда — и нагрузка.
А используя скрипт — нагрузка будет большой (тут не отрицаю), но не постоянной.

[kutsy]

Ну я и не говорю что это довольно быстро, особенно на паре миллионов записей на десятке мемкэш-серверов при полной нагрузке., но альтернатив получения всех (или по уканному паттерну) ключей с Мемкэша я пока не видел :-)

[josser]

А вот если использовать теги? Ну я вот не специалист вообще в этом, знаю только принцип работы и пару раз баловался.

[MpaK999]

В дальнейшем надо будет подумать о кэшировании этих кэш ключей :)))

[copist]

Думали уже неоднократно. Всё упиралось в «гонки». Есть ли в мемкэше понятие эксклюзивной записи с блокировками? А осилит ли этот кэш ключей (псевдо «регистр ключей») значение в два-три миллиона записей?

[CodeMaker]

Спасибо за решение.
Может быть теперь получится реализовать очистку кеша по маске.

[artch]

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

[hemule]

Вы не представляете, как я вам благодарен.

[kutsy]

Всегда пожалуйста! ;-)

[igamity]

А не проще ли хранить все нужные тебе ключи в массиве по отдельному ключу, ну т. е. пользоваться стандартными средствами мемкешеда?

Т. е. записал в мемкешед ключ1-значение1, ключ2-значение2, ..., ключN-значениеN, а по ключу keys-[ключ1, ключ2, ..., ключN] или даже keys-[ключ1-времяЖизни1, ключ2-времяЖизни2, ..., ключ3-времяЖизни3].

В процессе работы просто пушим в массив keys новые ключи, а когда нужно, считываем, агрегируем (чтобы исключить уже умершие ключи) и обновляем keys в самом мемкешеде.

[prn]

>В процессе работы просто пушим в массив keys новые ключи, а когда нужно, считываем, агрегируем (чтобы исключить уже умершие ключи) и обновляем keys в самом мемкешеде.
1) если ключей данное поле станет большим и не поворотливым
2) и вообще это работать не будет, тк в случае одновременного запроса к элементу keys 2х или более процессов, и последующем обновлении, целостность данных нарушится

[igamity]

1. Уверен, что контент который в обычных условиях храниться в мемкеше намного привысит по объему массив самих ключей, даже если у Вас этот массив будет в несколько кБ.

2. Тут так же применимы все техники работы при конкурентном доступе.

Т. е. Вы считаете, что метод топикстартера лучше будет работать с большими объемами ключей и в условиях конкурентного доступа?

[prn]

считаю (уверен), что оба варианта работать при больших объемах и конкуренции работать не будут.
нужен другой подход, по типу хеш-таблицы. В общем, в комментарии суть не вместить, как будет время, напишу пост

[igamity]

Где вы хеш-таблицу хранить думаете? И как реализацию делать? Если все делать стандартными средствами и хранить данные в самом мемкеше — так я о том и писал, просто реализацию самую простую предложил.

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

[EXSlim]

Вот, то что Вам нужно. Linux

[kutsy]

О! Спасибо.
Посмотрим, посмотрим.

[vladimir_gorobets]

PHP Client Comparison
Как я понял есть 2 разных библиотеки для работы с memcache из под php (pecl/memcache и pecl/memcached). А в чем их принципиальное отличие? (сорри с английским не всё так хорошо)

[artch]

Это конечно замечательно, но ахтунг: stats cachedump выдает лишь часть данных (что-то коло 200к ключей, насколько я помню). Если у вас весь кэш помещается в это количество, тогда ура, если нет — нарветесь на проблемы, если будете рассчитывать, что возращен весь кэш.

Кроме того, выполнение cachedump полностью блокирует на время выполнения все остальные запросы, что совершенно некошерно на неблокирующем по определению кэшере.

Именно по этим причинам этих функций и нет в различных API. Формально memcached ничего не знает о структуре хранимых им ключей.

[copist]

Таким образом топик и решение — бред. Будет только хуже, чем перезапуск сервиса.

[koshpavel]

Чтобы к такой проблеме прийти — нужно вначале нагадитьнакодить так чтобы эти ключи потерять.

[Art1x]

Последнее время memcached применяют где надо и где не надо. Почитайте FAQ на сайте memcached, там ясно написано почему не стоит выгребать все ключи из сервера.

[zeromodule]

Хм, ваша функция возвращает пустой массив, а getStats('cachedump') — FALSE.
Всё на локалхосте.
Интересно, почему?

[kutsy]

IP и порт верны?
А если телнетом зайти (telnet 127.0.0.1 11211) и написать к примеру "stats slabs"? Что пишет?

[zeromodule]

STAT 5:chunk_size 232
STAT 5:chunks_per_page 4519
STAT 5:total_pages 1
STAT 5:total_chunks 4519
STAT 5:used_chunks 4519
STAT 5:free_chunks 0

…

END

[SaveTheRbtz]

Ужс! Представляю как приложение, использующее этот метод сломается, как только кол-во ключей зашкалит за 10К.

Не стоит изобретать велосипед. используйте теги