example - ¿Convenciones de nombres clave de Redis?

redis structure

Question

¿Cuál es la convención de nomenclatura normal para las claves en redis? He visto valores separados por : pero no estoy seguro de cuál es la convención normal, o por qué.

Para un usuario, harías algo como ...

user:00

si la identificación del usuario era 00

¿Puede consultar solo el comienzo de la clave para devolver a todos los usuarios?

Principalmente estoy esperando evitar problemas futuros investigando las formas en que funcionan para las personas y por qué los eligieron.

Answer 1

¿Cuál es la convención de nomenclatura normal para las claves en redis? He visto valores separados por: pero no estoy seguro de cuál es la convención normal, o por qué.

Sí, signo de colon : es una convención al nombrar claves. En this tutorial en el sitio web redis se afirma: Trate de seguir con un esquema. Por ejemplo, "object-type: id: field" puede ser una buena idea, como en "user: 1000: password". Me gusta usar puntos para campos de palabras múltiples, como en "comment: 1234: reply.to".

¿Puede consultar solo el comienzo de la clave para devolver a todos los usuarios?

Si te refieres a algo como consultar directamente todas las claves que comienzan con el user: hay un comando de keys para eso. Sin embargo, este comando debe usarse solo para fines de depuración ya que es O(N) porque está buscando a través de todas las claves almacenadas en la base de datos.

La solución más adecuada para este problema es crear una clave dedicada, vamos a nombrar a los users , que almacenará todas las claves de los usuarios, por ejemplo, en la list o set la estructura de datos.

Answer 2

No sé si realmente existen "mejores prácticas" generalizadas para la denominación clave de Redis.

He experimentado con el uso de caracteres ASCII NUL como mis separadores (ya que Redis y Python son ambos de 8 bits limpios). Se ve un poco feo si estás mirando claves en bruto, pero la idea es esconderlo detrás de una capa de abstracción. Los símbolos de puntos y columnas son alternativas obvias siempre que los componentes de su espacio de nombres estén garantizados para no usarlos o esté dispuesto a codificar cada componente según sea necesario. Sin embargo, si los codificara, querría desarrollar la capa de abstracción y evitar ver claves sin procesar de todos modos ... lo cual me devolvió a usar / 0 en mi razonamiento.

Seré interesante para ver si hay otras opiniones articuladas sobre esto.

Answer 3

Una convención parece ser dos puntos (:) pero soy un desarrollador web, así que personalmente prefiero la barra inclinada (/) para el separador. Slash ya es un separador tan importante dentro de las URL que deben ser localizadores uniformes de recursos, así que son claves para los recursos. ¿Por qué tomar un enfoque diferente con dos puntos (:)? ¿Ayuda algo?

Considera este ejemplo:

Tenemos una API RESTful para objetos de juguete. Hay uno:

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

Donde lo tenemos almacenado? Usamos Redis y barras diagonales, por lo que la clave es obvia:

toy/234

Esta es la clave única para el juguete. La clave ahora se puede usar también en el lado del cliente:

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

Un usuario solicita un objeto con la clave toy/666 . ¿Cómo obtenerlo de Redis? Un ejemplo relacionado de Node.js:

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

No es necesario convertir barras en dos puntos y viceversa. Conveniente, ¿no crees?

Nota: siempre asegúrese de que el usuario pueda acceder solo a las cosas que desea. El enfoque anterior de URL a clave anterior también puede obtener el user/1/password , como lo notaron los comentaristas. Esto no debería ser un problema si usa Redis como un caché público de solo lectura.

Answer 4

Usamos dos puntos (:) como separador de espacio de nombres y un hash (#) para las partes id de las claves, por ejemplo:

logistics:building#23