А если разнести алгоритмически ключи по нескольким редис серверам?

даже запустив их на одном железном сервере, на разных портах

ну если редису не нравится когда ключей много

Он у меня как кеш использоваться будет.

Если сделать предположения о количестве ключей в кеше то там даже может можно реализовать быстрый логарифмический поиск

Выражайся конкретнее, а то 'изъян' - нет такого термина в ойти

Например вот это: http://php.net/manual/ru/memcached.getallkeys.php Очень не рекомендуется использовать, т.к. оно может тупо не вернуть все ключи, зависит от положения марса и настроения сервера... Как у редиса с возвратом всех ключей?

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

Ага, если жаров говорит что там все ключи выбираются для поиска

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

Если сделать предположения о количестве ключей в кеше то там даже может можно реализовать быстрый логарифмический поиск

module:function: засунуть в хешмап с ключом module: все ключи module:function:* и получать сразу все ключи модуля

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

А по какому критерию они стухают?

ну если редису не нравится когда ключей много

Мемкеш же как то живёт с десятками лимонов ключей... Даже статитьи видел где крупные дяди делают класстеры мемкеш серверов, и у них почти всё отдаётся с них, т.е. база дёргается только когда ОЧЕНЬ надо, живой журнал вроде их использует активно.

Если сделать предположения о количестве ключей в кеше то там даже может можно реализовать быстрый логарифмический поиск

Да мне даже не столько по иск нужен, сколько удаление, но удаление по паттерну я что то не нашёл в документации.

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

Выше написал зачем оно мне.

Мемкеш же как то живёт с десятками лимонов ключей... Даже статитьи видел где крупные дяди делают класстеры мемкеш серверов, и у них почти всё отдаётся с них, т.е. база дёргается только когда ОЧЕНЬ надо, живой журнал вроде их использует активно.

У меня есть проект, там конечно не десятки милионов, но наверно о 3 млн можно говорить. Никаких тормозов не наблюдаю. Но это же мемкеш, а не редис.

Удаляй явно

У меня есть проект, там конечно не десятки милионов, но наверно о 3 млн можно говорить. Никаких тормозов не наблюдаю. Но это же мемкеш, а не редис.

А на редисе есть тормоза?

Я редис не юзал серьезно. Но думаю что не должно быть, с чего бы.

ну может в какомто частном случае и есть

Да мне даже не столько по иск нужен, сколько удаление, но удаление по паттерну я что то не нашёл в документации.

разнеси по базам в редисе и очищай базу

module:function: засунуть в хешмап с ключом module: все ключи module:function:* и получать сразу все ключи модуля

Не совсем понял.

А по какому критерию они стухают?

По обновлению инфы, например появилась свежая новость, ключи полных выборок новостей оставляем, а вот ключи листов ID нужно убить, причём их количество нам не известно, т.к. cat_N_page_N

Ладно мне уже надоело обсуждать несформулированную задачу

Тебе известен список ключей? Убивай. Несуществующие тоже убивай, ничего не сломается.

У меня есть проект, там конечно не десятки милионов, но наверно о 3 млн можно говорить. Никаких тормозов не наблюдаю. Но это же мемкеш, а не редис.

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

фиг знает. Мемкеш простой как топор.

шлеп шлеп

и в продакшн

разнеси по базам в редисе и очищай базу

Дак я так и в мемкеше могу) НО этот подход не подходит, т.к. очещать нужно выборочно, а иерархия кеша у меня 4-6.

какие базы в мемкеше?

даже теоретически, задача получить 10млн записей о кеше и найти в них одну и убить её - это тупость. Можно сразу убить.

фиг знает. Мемкеш простой как топор.

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

я про логические базы https://redis.io/commands/select

какие базы в мемкеше?

А кто сказал про базы? Я же выше написал что это кеш.

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

cat_N_page_N page это видимо страница, а cat это что? каталог?

cat_N_page_N page это видимо страница, а cat это что? каталог?

Это ID категории.

Ну вот страницу как минимум ты можешь сделать себе хеш-множеством

и будет у тебя 'cat_N' => { page1, page2, page3 } Из редиса ты можешь выбирать отдельную запись по ключу cat_N и по ключу страницы page2, при этом можешь одной командой грохнуть все множество cat_N

заведи реестр ключей в том же редисе

Если у тебя надо было выбирать M_cat * N_pages ключей и каждый удалять, то в такой схеме надо будет выбирать всего лишь M_cat категорий

ключ со списокм ключей

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

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

можно наврено действительно хранить список ключей. Но это опять же.. какаято шляпа.

у меня проще, у меня ttl кеша и безусловное удаление по истечению ttl. В моменте нагрузка снижена, кеш живет максимум 10 минут и существует только для того, что запрашивают юзеры.

Тут проблема в том что может быть примерно вот так: /cms/$site_id/apps/$app_id/$module_id/$function_id/$sub_function_id/cat_$cat_id_page_$page_id.tmp Я у себя пути строю подобно файловым что бы удобнее с ними логически работать, да и дробить по слешам можно удобно. $module_id, $function_id, $sub_function_id могут быть как названиями, так и название и числовой ID.

вообще классически в мемкеше делают иначе... и ничего не мешает поступить так же в редисе заводишь ключ namespace = 1 и все кеш ключи создаешь как cache:$namespace:xxx... Тогда что бы "сбросить кеш", достаточно сделать $namespace++

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

ключ со списокм ключей

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

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

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

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

Я сделал обёртку которая таймштампом метит каждую кеш запись, и проверяет потом актуальный тайм штамп для раздела кеша, если он там поменялся, то при обработке обёрткой он будет признан тухлым и удалён, попутно потом новый заведётся сразу же.

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

у меня проще, у меня ttl кеша и безусловное удаление по истечению ttl. В моменте нагрузка снижена, кеш живет максимум 10 минут и существует только для того, что запрашивают юзеры.

А что если у тебя новый контент появился, он не выводится до сброса кеша? Это же не правильно, у меня есть отложенная публикация, где такое не пройдёт, и кеш у меня живёт гораздо дольше.

вообще классически в мемкеше делают иначе... и ничего не мешает поступить так же в редисе заводишь ключ namespace = 1 и все кеш ключи создаешь как cache:$namespace:xxx... Тогда что бы "сбросить кеш", достаточно сделать $namespace++

Щас так и сделано по сути, только несколько иначе, теги хранятся прямо в теле JSON массива ключа.

А что если у тебя новый контент появился, он не выводится до сброса кеша? Это же не правильно, у меня есть отложенная публикация, где такое не пройдёт, и кеш у меня живёт гораздо дольше.

да, в течение 10 минут может быть лаг. Есть кнопка убить весь кеш. Поскольку данные попадают ко мне из сторонних источников (из фидов) никто точно не знает во сколько появилсь данные, поэтому мне все равно. Если бы это было завязано на действия юзера, юзеры бы затрахали

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

Дак как это спасёт от того что в один момент времени 10 отдельных потоков будут пытаться внести туда свои изменения?

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

У меня полностью получается, разбирается, и сравнивается таймштамп, и потом уже принимается решение о тухлости кеша.

У меня полностью получается, разбирается, и сравнивается таймштамп, и потом уже принимается решение о тухлости кеша.

выглядит так, что это тормозно

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

да, в течение 10 минут может быть лаг. Есть кнопка убить весь кеш. Поскольку данные попадают ко мне из сторонних источников (из фидов) никто точно не знает во сколько появилсь данные, поэтому мне все равно. Если бы это было завязано на действия юзера, юзеры бы затрахали

А у меня ВСЁ кешируется, так что отправил пост на форуме, юзер же не будет ждать 10 минут таймера до появления поста)

нов целом инвалидация кеша - задача очень объемна и многогранна, увы... что бы там было универсальное решение

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

Это тоже видел, но оно усложнит обёртку до невозможности, тут даже я уже без пол литра в своём коде не разберусь)

мы вот стали в админке для менеджеров в часы пик отключать часть функционала, ибо он кеш сбрасывает активно ;)

Так а какие проблемы с текущим решением? Что за желание сломать то, что работает

работает и пусть работает

выглядит так, что это тормозно

Ну скажем по скорости множественной выборки оно соотвествует редису, на чистом мемкеше оно было бы раз в 10 быстрее, вот и хочется переехать на редис, что бы убрать излишнюю обёртку и повысить скорость.

это повышение в 10 раз необходимо?

не, ну если хочется, то можно конечно

мы вот стали в админке для менеджеров в часы пик отключать часть функционала, ибо он кеш сбрасывает активно ;)

Дак вы собирайте кеш из кусочков, это позволяет не так страдать, правда на PHP нагрузка возрастает, зато базе дишиться легче)

Так а какие проблемы с текущим решением? Что за желание сломать то, что работает

Скорость падает про слишком при больших выборках, например получения списка из 1000 записей вызовет порядка 10К обращений в кеш.

ERROR: S client not available

разнеси на два сервера

на три на 5

Накладных расходов много.

разнеси на два сервера

Дело не в серверах, дело в количестве образщений.

то етсь тормозит не мемкеш?

то етсь тормозит не мемкеш?

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

на сравнение временной метки? Или на транспорт до сравнения

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

Грубо говоря очень низкий КПД из-за прослойки, но без неё КПД кеширования стремиться к нулю, т.к. если храним готовый кеш, он будет сбрасываться по любому чиху.

нов целом инвалидация кеша - задача очень объемна и многогранна, увы... что бы там было универсальное решение

А что, нет какого-то суперхранилища с тегированным кешем ?

Да и готовый HTML меня не устраивает, нужны сырые данные.

А что, нет какого-то суперхранилища с тегированным кешем ?

Было бы, я бы наверное взял готовое)

Я думаю что есть

всякие там кассандры кафки это не то?

Вообще по логике работы мне бы подошёл тупо аналог RAM диска, т.к. логика удаления ключей похожа на удаление директорий с кеш файлами.

всякие там кассандры кафки это не то?

Да я там сопьюсь пока разберусь в них, нужно что то полегче)

А что, нет какого-то суперхранилища с тегированным кешем ?

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

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

Так я и говорю, по идее должно быть такое чудо хранилище которое решает эти проблемы :)

хз... все настолько индивидуально мне кажется...

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

У меня уровни сброса, можно сбросить весь кеш всех сайтов, тупо сделать флуш мемкеша, можно сбросить кеш сайта, можно сбросить кеш приложения, можно кеш модуля приложения, можно кеш функции модуля приложения и т.д.

т.е. деление по слешам пути по сути.

интересно а можно ли к редису писать экстеншены

я вот давно думал сравнить мемкеш с майскулем в мемори и тюнингованым конфигом

и постоянным конектом

хз... все настолько индивидуально мне кажется...

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

я вот давно думал сравнить мемкеш с майскулем в мемори и тюнингованым конфигом

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

Если бы я юзал InnoDB, он бы втух давно.

критично медленней? Имхо мемкеш не используется в алгоритме с сравнением какиехто таймстампов и на 10% своей скорости. Единственное что мемкеш делает быстро - отвечает короткими данными на короткий ключ. Так быстро, что прямо шок.

А что ты кодишь то? Реестр запрещенных сайтов?

Да, хочет под нг опять в дикси кассы заблокировать, чтобы пенсионеры бунтовали

критично медленней? Имхо мемкеш не используется в алгоритме с сравнением какиехто таймстампов и на 10% своей скорости. Единственное что мемкеш делает быстро - отвечает короткими данными на короткий ключ. Так быстро, что прямо шок.

Мне мемкеш туда не подходил, по этому я и не делал этого и не сравнивал.

А что ты кодишь то? Реестр запрещенных сайтов?

CMS пилю)