Redis Key именования? - PullRequest
       8

Redis Key именования?

199 голосов
/ 06 августа 2011

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

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

user:00

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

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

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

Ответы [ 5 ]

173 голосов
/ 07 августа 2011

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

Да, знак двоеточия : - это соглашение при именовании ключей. В этом руководстве на сайте Redis указано: Попробуйте придерживаться схемы. Например, «тип объекта: идентификатор: поле» может быть хорошая идея, как в "пользователь: 1000: пароль". Мне нравится использовать точки для поля, состоящие из нескольких слов, например "comment: 1234: reply.to".

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

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

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

25 голосов
/ 30 марта 2013

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

logistics:building#23
15 голосов
/ 15 июля 2013

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

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

У нас есть RESTful 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? Пример, связанный с Node.js.

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

Нет необходимости преобразовывать косую черту в двоеточие и наоборот. Удобно, тебе не кажется?

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

5 голосов
/ 09 августа 2011

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

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

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

0 голосов
/ 16 июня 2019

Мне кажется, что для вашего использования лучше подойдет HSET / HGET . Также есть команда HKEYS .

Все эти команды имеют ту же сложность, что и GET / SET / KEYS, так почему бы не использовать их?

Тогда вы могли бы иметь такую ​​структуру:

  • пользователи> 00> значение
  • пользователи> 01> значение

или

  • пользователи: имя пользователя> 00> значение
  • пользователи: имя пользователя> 01> значение

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

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