Что такое точка множественных баз данных Redis?

Ответ 1

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

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

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

Ответ 2

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

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

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

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

Что касается одиночной резьбы, считайте, что redis предназначен для скорости и атомарности. Уверенные действия, изменяющие данные в одном db, не должны ждать другого db, но что, если это действие сохраняется в файле дампа или обрабатывает транзакции на ведомых? В этот момент вы начинаете впадать в сорняки программирования concurrency.

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

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