Какой смысл в нескольких базах данных Redis?


159

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

Если я сегментирую на несколько баз данных, все по-прежнему будет однопоточным, и я все равно смогу использовать только одно ядро. Если я просто запускаю другой экземпляр Redis на том же компьютере, я получаю дополнительное ядро. Кроме того, я не могу назвать базы данных Redis или дать им какой-либо более логичный идентификатор. Итак, с учетом всего вышесказанного, почему / когда я захочу использовать несколько баз данных Redis вместо того, чтобы просто раскрутить дополнительный экземпляр Redis для каждой дополнительной базы данных, которую я хочу? И, соответственно, почему Redis не пытается использовать дополнительное ядро ​​для каждой дополнительной базы данных, которую я добавляю? В чем преимущество однопоточности между базами данных?


в вашем приложении Node.js сделайте это ---> module.exports = {"1": "ваше имя для redis db one", "2": "ваше имя для redis db two", "3": "your название для redis db three "} и т. д., или переключайте ключи и значения, как вам нужно
Александр Миллс

1
В Redis 2.8.0 и более поздних версиях рекомендуется использовать SCAN вместо KEYS, поскольку он выполняет итерации по небольшому количеству элементов за раз (таким образом, не блокируя сервер в течение длительных периодов времени).
TryHarder,

Ответы:


85

В принципе, базы данных Redis в одном экземпляре не отличаются от схем в экземплярах базы данных RDBMS.

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

Есть одно явное преимущество использования баз данных Redis в том же экземпляре Redis, и это управление. Если вы раскручиваете отдельный экземпляр для каждого приложения и, скажем, у вас есть 3 приложения, это 3 отдельных экземпляра Redis, каждому из которых, скорее всего, понадобится ведомое устройство для HA в производственном процессе, то есть всего 6 экземпляров. С точки зрения управления это очень быстро запутывается, потому что вам нужно следить за всеми ними, делать обновления / исправления и т. Д. Если вы не планируете перегружать Redis с высоким I / O, отдельный экземпляр с ведомым устройством проще и легче управлять при условии, что он соответствует вашему SLA.


25
Несколько экземпляров Redis - это всегда путь. Период. Запускайте параллельные запросы для разных данных. Если ваш конвейер CICD не создает кластеры кеша для вас, исправьте это, а не ..... Вы получаете точку
Cmag

3
Это не касается пунктов OP: (1) почему Redis не пытается использовать дополнительное ядро ​​для каждой дополнительной базы данных? (2) В чем преимущество однопоточности между базами данных?
Ives

93

Вы не хотите использовать несколько баз данных в одном экземпляре Redis. Это устарело, и, как вы заметили, несколько экземпляров позволяют использовать преимущества нескольких ядер. Если вы используете выбор базы данных, вам придется провести рефакторинг при обновлении. Мониторинг и управление несколькими экземплярами не сложно и не болезненно.

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

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

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

Что касается однопоточных, учтите, что Redis предназначен для скорости и атомарности. Конечно, действия по изменению данных в одном БД не должны ждать на другом БД, но что, если это действие сохраняет в файл дампа или обрабатывает транзакции на ведомых устройствах? В этот момент вы начинаете увлекаться программированием параллелизма.

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


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

27
Некоторые (убедительные) доказательства от «владельца» Redis (в соответствии с Кодексом Google), что «... базы данных не будут устаревшими, даже если я в прошлом утверждал, что они будут».
Кенни Эвитт

3
Вы не сможете использовать более одной базы данных Redis на кластере Redis. Помимо этого, несколько баз данных все равно будут существовать.
coredump

26
-1 для устаревшего заявления. Несколько баз данных могут не поддерживаться и не поддерживаться в Redis-кластере, но они не рекомендуется.
AgDude

1
@ the-real-bill Как вы можете «создать ключевой индекс»?
Кейс де Кутер

57

Даже Сальваторе Санфилиппо (создатель Redis) считает плохой идеей использовать несколько БД в Redis. Смотрите его комментарий здесь:

https://groups.google.com/d/topic/redis-db/vS5wX8X4Cjg/discussion

Я понимаю, как это может быть полезно, но, к сожалению, я считаю, что множественные ошибки в базе данных Redis - самое худшее решение в дизайне Redis ... без какой-либо реальной выгоды, это делает внутреннее устройство намного более сложным. Реальность такова, что базы данных плохо масштабируются по ряду причин, таких как активный срок действия ключей и виртуальная машина. Если выбор БД может быть выполнен со строкой, я вижу, что эта функция используется в качестве масштабируемого уровня словаря O (1), а это не так.

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


4
Подожди, значит, использование выбора БД на самом деле менее эффективно, чем просто использование префикса? Это то, что означает это предложение (кто-то может уточнить)? «Если выбор БД может быть выполнен с помощью строки, я вижу, что эта функция используется в качестве масштабируемого уровня словаря O (1), а это не так».
Дван

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

  2. Я бы не рекомендовал использовать KEYSкоманду, так как это O (n), и она плохо масштабируется. Что вы используете для этого вы можете сделать по-другому? Может быть, Redis не лучший вариант для вас, если функциональность, как KEYSэто важно.

  3. Я думаю, что они упоминают о преимуществах однопоточного сервера в своих часто задаваемых вопросах, но главное - это простота - вам не нужно беспокоиться о параллелизме каким-либо реальным способом. Каждое действие блокирует, поэтому никакие две вещи не могут изменить базу данных одновременно. В идеале вы должны иметь один (или несколько) экземпляров на ядро ​​каждого сервера и использовать согласованный алгоритм хеширования (или прокси-сервер) для разделения ключей между ними. Конечно, вы потеряете некоторую функциональность - трубопроводы будут работать только для одного и того же сервера, сортировки станут сложнее и т. Д.


В ответ на 2: я использую команду ключей только тогда, когда мне нужны все ключи. Я использую его так же, как и Hgetall. Оба являются O (n). Ключи - это плохо, если вам нужно искать в огромном наборе ключей какое-то регулярное выражение, но это прекрасно, если вам нужно выполнить какую-то операцию со всеми ключами в некоторой базе данных. В ответ на 3: я понимаю преимущества однопоточности в одной базе данных. Я не понимаю этого во многих базах данных, поскольку действие над одной базой данных никогда не должно блокировать действие над другой базой данных AFAIK.
Эли

3

Я использую Redis для реализации черного списка адресов электронной почты, и у меня разные значения TTL для разных уровней черного списка, поэтому наличие разных БД в одном экземпляре мне очень помогает.


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

@ user2717436 Я не уверен, что то, что я делаю, связано с твоим, но я использую разные базы данных как разные наборы, всегда устанавливая TTL ключей, когда я их вставляю. как есть в черном списке A на redis.get (1), и всякий раз, когда я устанавливаю там ключ, я устанавливаю срок действия 5000. и есть черный список B на redis.get (2), и всякий раз, когда я устанавливаю там ключ, я устанавливаю expire на 10000
kommradHomer

2

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


1

Использование нескольких баз данных в одном экземпляре может быть полезно в следующем сценарии:

Различные копии одной и той же базы данных могут быть использованы для производства, разработки или тестирования с использованием данных в реальном времени. Люди могут использовать реплику для клонирования экземпляра Redis для достижения той же цели. Тем не менее, первый подход облегчает существующим работающим программам просто выбрать правильную базу данных для переключения в намеченный режим.


1

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

Если вы используете «облачный Redis» от вашего любимого облачного провайдера, вы, вероятно, имеете минимальный объем памяти и будете платить за то, что вы выделяете. Однако, если ваш набор данных меньше этого, то вы будете тратить немного средств и, следовательно, тратить немного денег.

Используя базы данных, вы можете использовать один и тот же облачный экземпляр Redis для предоставления услуг, скажем, для dev, UAT и производства, или для нескольких экземпляров вашего приложения, или для чего-либо еще - таким образом, используя больше выделенной памяти и, таким образом, немного больше затрат. эффективный.

У сценария использования, на который я смотрю, есть несколько экземпляров приложения, каждый из которых использует 200-300 Кбайт, но минимальное выделение для моего облачного провайдера составляет 1 млн. Мы можем объединить 10 экземпляров на одном Redis без каких-либо ограничений, что позволит сэкономить около 90% стоимости хостинга Redis. Я ценю, что есть ограничения и проблемы с этим подходом, но подумал, что стоит упомянуть.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.