Соглашения об именовании ключей Redis?

каковы обычные правила именования ключей в redis? Я видел значения, разделенные : но я не уверен, что такое нормальная конвенция, или почему.

для пользователя вы бы сделали что-то вроде...

user:00

если идентификатор пользователя был 00

вы можете запросить только начало ключа, чтобы вернуть всех пользователей?

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

4 171
naming-conventions redis

4 ответа:

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

Да, знак двоеточие : - Это соглашение при именовании ключей. В этой учебник на сайте redis указано:попробуйте придерживаться схемы. Например "object-type:id:field" может быть хорошая идея, как в "user: 1000: password". Мне нравится использовать точки для поля с несколькими словами, например "comment:1234:reply.to".

вы можете запросить только начало ключа, чтобы вернуть все пользователи?

если вы имеете в виду что-то вроде прямого запроса для всех ключей, который начинается с user: есть ключи для этого. Однако эта команда должна использоваться только для отладки, так как это O (N) потому что он ищет через все ключи strored в базе данных.

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

144

мы используем двоеточие (:) в качестве разделителя пространства имен и хэш ( # ) для id-частей ключей, например:

logistics:building#23
22

соглашение, кажется, двоеточие (:)но Я веб-разработчик, поэтому лично я предпочитаю Слэш ( / ) для разделителя. Слэш уже так важен разделитель внутри URL-адресов, которые должны быть Унифицированные Указатели Ресурсов так что вид ключей для ресурсов. Зачем использовать другой подход с двоеточием (:)? Это что-нибудь помогает?

Рассмотрим пример:

у нас есть спокойный API для игрушечных объектов. Есть один:

http://example.com/api/toy/234

где мы его хранили? Мы используем Redis и косые черты, поэтому ключ очевиден:

toy/234

это уникальный ключ для игрушки. Ключ теперь можно использовать и на стороне клиента:

{
    key: "toy/234",
    color: "red",
    url: function () {
        return API_BASE_URL + this.key;
    }
}

пользователь запрашивает объект с ключом toy/666. Как получить его от Redis? узел.связанные JS пример:

redis.get(key, function reply_callback(error, toystring) {
    var toy = JSON.parse(toystring);
    ...
}

нет необходимости конвертировать косые черты в двоеточия и наоборот. Удобно, не правда ли?

Примечание: всегда убедитесь, этот пользователь может получить доступ только к тем вещам, которые вы намеревались. подход raw URL-to-key выше способен извлекать user/1/password также, как отмечают комментаторы. Это не должно быть проблемой, если вы используете Redis в качестве публичного чтения кэша.

12

Я не знаю, действительно ли существуют широко распространенные "лучшие практики" для именования ключей Redis.

я экспериментировал с использованием символов ASCII NUL в качестве моих разделителей (поскольку Redis и Python являются 8-битными чистыми). Это выглядит немного уродливо, если вы смотрите на необработанные ключи, но идея заключается в том, чтобы скрыть его за слоем абстракции. Символы двоеточия и трубы являются очевидными альтернативами, если компоненты вашего пространства имен либо гарантированно не используют их, либо вы готовы кодировать каждый компонент по мере необходимости. Однако, если вы будете кодировать их, то вы хотите разработать уровень абстракции и избежать просмотра необработанных ключей в любом случае ... что привело меня прямо к использованию \0 в моих рассуждениях.

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

5