Redis dbN - Любой выигрыш? [Дубликат]
Используйте @import url('css4.css') на одной из ваших существующих страниц css. Затем используйте спецификацию для выделения вашего нового кода:
Html:
<ul class='ulclass'>
<li class='liclass'>
<a class='aclass>The text</a>
</li>
</ul>
css1.css:
.aclass{
color : red;
}
css4.css:
ul.ulclass li.liclass a.aclass{
color: green;
}
Тогда у вас будет green цвет в вашем элементе a
6 ответов
В принципе, базы данных Redis в одном экземпляре не отличаются от схем в экземплярах базы данных РСУБД.
Итак, со всем сказанным, почему / когда я когда-нибудь захочу использовать несколько Redis вместо того, чтобы просто добавить лишний экземпляр Redis для каждой дополнительной базы данных, которую я хочу?
Есть одно явное преимущество использования баз данных redis в том же экземпляре redis, и это управление. Если вы создадите отдельный экземпляр для каждого приложения и предположим, что у вас есть 3 приложения, это три отдельных экземпляра redis, для каждого из которых, вероятно, потребуется ведомое устройство для HA, поэтому это шесть общих экземпляров. С точки зрения управления, это становится беспорядочным, потому что вам нужно контролировать все из них, делать обновления / исправления и т. Д. Если вы не планируете перегружать redis при высоких вводах-выводах, один экземпляр с ведомым проще и легче управлять, если оно соответствует вашему SLA.
-
1– Cmag 31 March 2016 в 03:57
Вы не хотите использовать несколько баз данных в одном экземпляре redis. Он устарел и, как вы отметили, несколько экземпляров позволяют вам использовать преимущества нескольких ядер. Если вы используете выбор базы данных, вам придется реорганизовать ее при обновлении. Мониторинг и управление несколькими экземплярами не является сложным и болезненным.
В самом деле, вы бы получили гораздо лучшие показатели для каждого db путем сегрегации на основе экземпляра. Каждый экземпляр имел бы статистику, отражающую этот сегмент данных, который может обеспечить лучшую настройку и более гибкий и точный мониторинг. Используйте последнюю версию и отделите свои данные по экземпляру.
Как сказал Джонатон, не используйте команду keys. Если вы просто создадите ключевой индекс, вы получите гораздо лучшую производительность. При добавлении ключа добавьте имя ключа в набор. Команда клавиш не очень полезна, как только вы увеличиваете масштаб, так как для возврата потребуется значительное время.
Пусть шаблон доступа определяет, как структурировать ваши данные, а не хранить его так, как вы думаете, работает, а затем работать над тем, как получить доступ и продолжить его позже. Вы увидите гораздо лучшую производительность и часто обнаруживаете, что код, потребляющий данные, намного чище и проще.
Что касается одиночной резьбы, считайте, что redis предназначен для скорости и атомарности. Уверенные действия, изменяющие данные в одном db, не должны ждать другого db, но что, если это действие сохраняется в файле дампа или обрабатывает транзакции на ведомых? В этот момент вы начинаете проникать в сорняки программирования параллелизма.
Используя несколько экземпляров, вы превращаете многопоточную сложность в более простую систему стилей передачи сообщений.
-
1– ostergaard 19 October 2013 в 07:29
-
2– Kenny Evitt 7 August 2014 в 20:40
-
3– coredump 2 September 2014 в 19:50
-
4– AgDude 21 January 2015 в 15:41
-
5– Kees de Kooter 4 December 2017 в 10:39
- Я не знаю никаких преимуществ наличия нескольких баз данных в одном экземпляре. Я думаю, это полезно, если несколько служб используют один и тот же сервер (ы) базы данных, поэтому вы можете избежать столкновений ключей.
- Я бы не рекомендовал строить вокруг, используя команду
KEYS, так как это O (n) и что не очень хорошо масштабируется. Что вы используете для этого, что вы можете выполнить по-другому? Возможно, redis не подходит для вас, если функциональность, такая какKEYS, жизненно важна. - Я думаю, что они упоминают преимущества одного многопоточного сервера в своем FAQ, но главное - простота - вы не 't нужно беспокоиться о параллелизме любым реальным способом. Каждое действие блокируется, поэтому две вещи не могут одновременно изменять базу данных. В идеале у вас будет один (или более) экземпляр на ядро каждого сервера и используйте последовательный алгоритм хэширования (или прокси) для разделения ключей между ними. Конечно, вы потеряете некоторую функциональность - трубопровод будет работать только на вещи на одном сервере, сортировки становятся более сложными и т. Д.
-
1– Eli 25 April 2013 в 19:56
Я использую redis для реализации черного списка адресов электронной почты, и у меня разные значения TTL для разных уровней черного списка, поэтому использование разных БД в одном экземпляре мне очень помогает.
-
1– Cmag 31 March 2016 в 04:02
-
2– user2717436 12 July 2017 в 10:07
-
3– kommradHomer 12 July 2017 в 20:26
Даже Сальваторе Санфилиппо (создатель Редиса) считает, что использовать Red Hat в нескольких базах данных неплохо. См. Его комментарий здесь:
https://groups.google.com/d/topic/redis-db/vS5wX8X4Cjg/discussion
Я понимаю, как это может быть полезно, но, к сожалению, я считаю ошибки Redis множественной базы данных самым худшим решением в дизайне Redis вообще ... без какого-либо реального выигрыша, это делает внутренности намного сложнее. Реальность заключается в том, что базы данных не масштабируются по ряду причин, например, по истечении срока действия ключей и виртуальной машины. Если выбор БД можно выполнить со строкой, я вижу, что эта функция используется как масштабируемый слой словаря O (1), а это не так.
С номерами БД, по умолчанию из нескольких БД, мы лучше сообщаем, что это за функция и как можно использовать, я думаю. Надеюсь, что в какой-то момент мы можем вообще отказаться от поддержки нескольких БД, но я думаю, что, возможно, слишком поздно, поскольку многие люди полагаются на эту функцию для своей работы.
Базы Redis могут использоваться в редких случаях развертывания новой версии приложения, где новая версия требует работы с разными объектами.