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

Question

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

Answer 5

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

Answer 6

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

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

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

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