Pull to refresh

Comments 22

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

Если речь все еще идет о Redis, то конечно есть. maxmemory-policy allkeys-lru LeastRecentlyUsed — наименее часто используемые

Странный доклад.
В ответе на этот вопрос:
А насколько в среднем быстрее получается memcached? 10%, 20%, 50%?

Ответ вообще не понятен, везде утверждает что memcache быстрее, а тут говорит что скорости сопоставимы.

на самом деле memcache быстре, но в реальных условиях — это ничтожно малое ускорение, не стоящее того, чтобы отказаться от повсеметсного использования redis

Быстрее в каком случае?
При массовом сохранении/выборке N ключей из того же HASH, Redis будет быстрее за счёт того, что делается 1 запрос, вместо N.


Не говоря уже о том, что в статье ни слова нет про zipmap/ziplist (а общее впечатление от опуса я оставлю при себе)

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

свое общее впечатление я положу рядом с вашим, я уверен, они подружатся

Я тоже так и не смог понять, зачем может понадобиться такая связка redis+memcached. Проблемы у них не в скорости, а в чем-то еще, по словам докладчика. Вначале, для себя попытался найти следующее объяснение, что есть модуль в nginx который позволяет использовать memcached. Но погуглив нашел что есть решения позволяющие подружить nginx и redis. Но возможно эти решения не так хороши, как memcached + nginx.
А так, со стороны, кажется что ДЛЯ НИХ memcached лишний.

я так понял, что memcache используется nginx'ом напрямую (а redis так не умеет? я не читал) и если тут хит — то оно даже не идет на бекенд

Мне вот интересно, когда memcache или redis отвалится что будет?
И причем здесь rabbitmq?

когда отвалятся — будут просто запросы в mysql базу

Сначала думал показалось, но нет! Вы «сериализацию» называете «стерилизацией»? :)
Этот доклад — расшифровка одного из лучших выступлений на конференции разработчиков высоконагруженных систем HighLoad++.


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

По сути это неполный пересказ документации о memcache, redis и, особенно RabbitMQ без каких-то интересных кейсов или неочевидных особенностей.

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

Это действительно по мнению _участников_ один из лучших докладов 2014-го года. Но если вам хочется чего-то похардкорнее, то у нас для вас ещё 9-ть потоков с докладами, проходящими параллельно :)

Чтобы в этом ориентироваться мы ввели в этом году метку «Для новичков/ средний / для экспертов».
Как обычно, про Aerospike все забыли, хотя среди конкурентов вроде единственная k/v бд, которая позволяет вместо ram использовать ssd. Да и по скорости неплохо обгоняет ту же редиску по крайней мере.
В прошлом году вспоминали. Говорят, неплохо, но не без неприятных (если об этом заранее не позаботиться) фич.
https://habrahabr.ru/company/oleg-bunin/blog/313364/
полностью отказались от memcached просто чтобы не сопровождать две программы

а с rabbit мне как администратору больше всего головной боли доставляет неаккуратность разработчиков — то очередь создадут да забудут (в результате очередь раздувается и ест память), то типы неверные (в результате при падении одной ноды, приложение перестало работать), то ключи для шовелов не согласовали между командами (ищем все вместе почему не доходят события).
условно падал один раз — одна нода в кластере перестала создавать новые очереди, хотя уже подключенные консьюмеры работали. Что за фокус так и не нашли. На случай повторения написали скрипт, который подключается->создает очередь->отправляет сообщение->получает->отключается->отчитывается в zabbix.
Хороший доклад, нового не так уж и много, но читать всё равно было очень приятно. Спасибо за то, что расписали текстом!
В первом примере суде по всему используется хранение картинок в MySQL — так себе решение для хайлоуд.
Libmemcached имеет больше возможностей реализовывать данные, по умолчанию стерилизуют их при помощи PHP, но можно определить стерилизатор JSON, например.

Я гляжу, к кованию контента на хабре теперь причастны люди, которые даже на слух термины не разбирают.
Ну а что, стерилизовали — теперь не наплодят проблем (:
А может кто в курсе, как можно связаться с автором? Есть вопрос о пересечении множеств в Redis. Мы в проекте используем подобную схему и столкнулись с тем, что пересечение двух множеств в Redis если там много элементов (100к) очень долгая операция.
Sign up to leave a comment.