Redis большой номер канала производительности - PullRequest
0 голосов
/ 29 июня 2018

Я хочу использовать Redis для кэширования. Один набор данных состоит из нескольких ключей. Эти ключи имеют другой размер. Самый большой - около 20 тысяч тонн. Для варианта использования было бы лучше, если бы комбинация этих клавиш составляла ключ канала Redis. Таким образом, я могу сбросить только небольшую часть данных, если будут сделаны обновления. Чем больше набор сохранен в канале, тем больше кеширования я потеряю.

Но мне интересно, есть ли минус в наличии большого количества каналов. Если я использую только этот самый большой ключ, то это около 20 КБ. Если я возьму другой ключ, который умножается примерно в 15 раз. Третий канал снова может умножить его на 3 в настоящее время, но может увеличиться до 20 или более. Тогда это 6 миллионов каналов.

Могу ли я столкнуться с проблемами при использовании многих каналов?

Пример: Я кеширую информацию о разных видах транспорта. Таким образом, я мог бы создать такие каналы, как:

  1. легковых, грузовых автомобилей, мотоциклов, ...
  2. синий автомобиль, красный автомобиль
  3. синие машины, красные машины, синие грузовики, красные грузовики, синие велосипеды, красные велосипеды, ...
  4. ...

При очистке первой структуры переадресации по каналу я «потеряю» всю информацию об автомобиле или всю информацию о грузовике и так далее. При очистке второй структуры по каналу я потеряю только информацию обо всех синих транспортных средствах, т.е. И последний пример только потеряет всю информацию о синей машине и так далее. Тем не менее, даже канал, содержащий только синие автомобили, будет означать, что есть много синих автомобилей. Но в отношении других структур, которые я бы потерял, придется перестраивать еще больше информации.

1 Ответ

0 голосов
/ 03 июля 2018

См. Документы:

ПОДПИСАТЬСЯ на канал [канал ...]

Доступно с 2.0.0.

Сложность времени: O (N), где N - количество каналов для подписки. к.

-

Сообщение канала PUBLISH

Доступно с 2.0.0.

Сложность времени: O (N + M), где N - количество клиентов, подписанных на принимающий канал, а М - общее количество подписанных шаблонов (любым клиентом).

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

Или рассмотрите эту альтернативу:

Используйте один канал и передайте некоторую информацию о том, какая часть кэша должна быть признана недействительной. Это может быть растровое изображение. Например, 1-й бит красный, второй - зеленый, N + 1-й - автомобиль, N + 2-й - шина, N + M + 1 - новый, N + M + 2 - используется и т. Д. Установка битов в одну категорию означает ИЛИ, в разные категории - И. Операции с растровыми изображениями очень быстрые, поэтому, когда все сделано правильно, поставщики кеша не должны сильно разбирать его. Было бы идеально, если бы на стороне Redis вы могли создавать каналы, которые бы рассылали сообщения нужным поставщикам данных. И провайдеры будут анализировать сообщение и получать инструкцию о том, какую часть сделать недействительной.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...