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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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