Что такое обычное соглашение об именах для ключей в redis? Я видел значения, разделенные :, но я не уверен, что такое нормальное соглашение, или почему.
Для пользователя вы бы сделали что-то вроде...
user:00
если идентификатор пользователя был 00
Вы можете запросить только начало ключа, чтобы вернуть всех пользователей?
В основном я просто надеюсь избежать любых будущих проблем, исследуя способы, которые работают для людей и почему они выбрали их.
Что такое обычное соглашение об именах для ключей в redis? я видел значения разделены: но я не уверен, что такое нормальное соглашение, или почему.
Да, знак двоеточия : является соглашением при именовании ключей. В этот приведено руководство по веб-сайту redis: попробуйте придерживаться схемы. Например, "object-type: id: field" может быть
хорошая идея, например, в "user: 1000: password". Мне нравится использовать точки для
многословные поля, например, в комментарии: 1234: reply.to ".
Можно ли запросить только начало ключа, чтобы вернуть все пользователи?
Если вы имеете в виду что-то вроде прямого запроса для всех ключей, начинающихся с user:, для этого есть keys. Однако эта команда должна использоваться только для цели отладки, поскольку она O (N), поскольку она выполняет поиск по всем ключам, хранящимся в базе данных.
Более подходящим решением для этой проблемы является создание выделенного ключа, пусть имя users, которое будет хранить все ключи пользователей, например, в list или set.
Мы используем двоеточие (:) как разделитель пространства имен и хеш (#) для id-частей ключей, например:
logistics:building#23
Соглашение, кажется, двоеточие (:), но я веб-разработчик, поэтому я лично предпочитаю косую черту (/) для разделителя. Slash уже настолько важный разделитель внутри 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 в качестве общедоступного кэша только для чтения.
Я не знаю, действительно ли существуют распространенные "лучшие практики" для именования ключей Redis.
Я экспериментировал с использованием символов ASCII NUL в качестве моих разделителей (поскольку Redis и Python оба являются 8-битными). Это выглядит немного уродливым, если вы смотрите на необработанные ключи, но идея заключается в том, чтобы скрыть его за слоем абстракции. Символы Colon и pipe являются очевидными альтернативами, если компоненты вашего пространства имен либо не гарантируют их использования, либо вы готовы кодировать каждый компонент по мере необходимости. Однако, если бы вы их кодировали, вам нужно было бы разработать слой абстракции и вообще избегать просмотра необработанных ключей... что привело меня к использованию только \0 в моих рассуждениях.
Мне будет интересно узнать, высказываются ли какие-либо другие мнения по этому поводу.
Мне кажется, что для вашего случая лучше подойдет HSET/HGET. Также есть команда HKEYS.
Все эти команды имеют ту же сложность, что и GET/SET/KEYS, так почему бы не использовать их?
Вы могли бы иметь эту структуру тогда:
или же:
Просто извлеките ID пользователя и используйте его в качестве хеш-ключа. Лично я предпочитаю этот подход, так как он приятнее, и вы также можете легко запросить существующие идентификаторы пользователей.