Modelización de datos: índices secundarios manuales

A menudo describimos Couchbase Server como una base de datos de documentos. Es una buena descripción: Couchbase funciona magníficamente como almacén de documentos JSON.

Al modelar nuestros datos para Couchbase Server, sin embargo, puede ayudar pensar en él más como un almacén de valores clave.

Pensamiento clave-valor frente a pensamiento documento

Entonces, ¿cuál es la diferencia práctica entre los almacenes de valores clave y los almacenes de documentos? Principalmente, se trata de cómo se consultan los datos.

Las bases de datos clave-valor tienden a almacenar los datos como unidades opacas, ofreciéndole un índice: la propia clave. Los datos se almacenan y recuperan en fragmentos discretos utilizando únicamente la clave. Suelen ser rápidas porque no son complicadas, pero también son una herramienta bastante contundente.

En cambio, los almacenes de documentos ofrecen índices adicionales sobre los datos del documento, por lo que la libertad de consulta es mucho mayor. Por supuesto, la consulta en cualquier sistema de base de datos conlleva un coste de recursos.

Al diseñar nuestro modelo de datos, tenemos que elegir qué enfoque adoptar. Para ello, tenemos que entender las ventajas y desventajas.

Las compensaciones

Couchbase se siente igual de cómodo ofreciéndote acceso clave-valor que acceso de tipo consulta documental a tus datos.

Ambos enfoques tienen sus ventajas y sus inconvenientes:

Con las vistas de Couchbase hoy y pronto N1QLLa consulta en Couchbase te da una enorme flexibilidad. Una vez que N1QL esté disponible en general, y la indexación para apoyarlo, tal vez gran parte de este blog será obsoleto.

Sin embargo, ahora mismo podemos mantener todos los beneficios del modelo clave-valor de Couchbase - consistencia inmediata, tiempos de respuesta en caché de sub-milisegundos, perfil de escalado lineal, etc - sin renunciar a mucha flexibilidad de consulta. La forma de hacerlo es crear índices secundarios manuales.

Todo gira en torno a la búsqueda

Imagina que estamos almacenando perfiles de usuario en Couchbase. La primera decisión que tenemos que tomar es cómo codificarlos.

Digamos que nuestros usuarios se conectan a nuestro sistema utilizando su dirección de correo electrónico. Eso significa que, como mínimo, cuando alguien se conecta sabemos esa única cosa sobre él. Si tecleamos los perfiles de nuestros usuarios por dirección de correo electrónico, obtendremos un proceso de inicio de sesión parecido a este:

1. El usuario introduce su dirección de correo electrónico (por ejemplo, lily@example.com) y su contraseña en el formulario de acceso.
2. Obtenemos el documento de Couchbase que tiene la clave lily@couchbase.com
3. Verificamos la contraseña con el hash del perfil de usuario.
4. Si tiene éxito, completamos el inicio de sesión y Lily sigue a lo suyo.

Genial, ha sido fácil.

Al cabo de un tiempo, Lily cambia su dirección de correo electrónico y quiere actualizarla en nuestro sistema. Naturalmente, querrá utilizar su dirección de correo electrónico actualizada para iniciar sesión.

Tenemos tres opciones para manejar esto:

• crear un documento de perfil de usuario completamente nuevo, con la nueva dirección de correo electrónico como clave, y destruir el antiguo
• crear un documento de redirección
• desde el principio, utilice documentos de consulta para crear un índice secundario manual.

La primera opción parece poco elegante. Por ejemplo, si hubiéramos estado haciendo referencia al documento en otra parte de nuestro sistema, esas referencias serían ahora callejones sin salida.

Redirecciona

Podríamos, en cambio, tomar la segunda opción y crear un nuevo documento con la clave de la nueva dirección de correo electrónico. El contenido del documento sería simplemente la antigua dirección de correo electrónico. Por supuesto, también tendríamos que colocar la nueva dirección de correo electrónico dentro del propio documento de perfil de usuario para que no necesitáramos el documento de búsqueda para asociar esa dirección de correo electrónico con este usuario.

Ahora nuestro proceso de inicio de sesión se vería así:

1. El usuario introduce su dirección de correo electrónico (por ejemplo, lily@newdomain.com) y su contraseña en el formulario de acceso.
2. Obtenemos el documento de Couchbase que tiene la clave lily@newdomain.com.
3. Vemos que el documento es otra dirección de correo electrónico (lily@example.com), en lugar de un perfil de usuario completo.
4. Obtenemos el documento lily@example.com.
5. Verificamos la contraseña con el hash del perfil de usuario.
6. Si tiene éxito, completamos el inicio de sesión y Lily sigue a lo suyo.

Esto podría funcionar. Pero nos complica un poco las cosas: ya no sabemos qué recibiremos cuando hagamos un GET en una dirección de correo electrónico.

En su lugar, podríamos empezar utilizando documentos de consulta desde el principio.

Utilizar un índice secundario manual

Es muy probable que una parte de nuestros usuarios cambie de dirección de correo electrónico a lo largo de la vida de su cuenta. Por lo tanto, tiene sentido que gestionemos esta probabilidad desde el principio.

En lugar de introducir la dirección de correo electrónico en los documentos de perfil de nuestros usuarios, debemos introducir algo único que permanezca constante. Como buscamos algo que no cambie, lo ideal es que la clave en sí no esté relacionada con nada sobre los propios usuarios. Couchbase Server nos da una manera fácil de manejar esto: contadores atómicos.

Podemos llamar a contadores atómicos con un incremento o un decremento, más una cantidad, y luego obtenemos de vuelta el número resultante. Si incrementamos el contador en uno cada vez que creamos un nuevo perfil de usuario, obtendremos una clave única e invariable.

Veamos cómo funciona:

1. Nuestro usuario completa el proceso de registro.
2. Incrementamos el contador y nos devuelve 1001.
3. Creamos nuestro documento de perfil de usuario utilizando la clave 1001.

Ahora, los cambios en el perfil del usuario no afectan a la clave. Sin embargo, hay un problema: a menos que queramos que nuestros usuarios memoricen un nombre de usuario numérico -como 1001-, tendremos que encontrar otra forma de hacer coincidir un nombre de usuario amigable con el perfil del usuario.

Ahí es donde entra en juego nuestro índice secundario manual. Vamos a añadir otro paso a nuestro proceso de registro:

4. Creamos un documento de búsqueda basado en la dirección de correo electrónico del usuario, con el valor 1001.

Ahora, nuestro proceso de inicio de sesión tiene este aspecto:

1. El usuario introduce su dirección de correo electrónico (por ejemplo, lily@newdomain.com) y su contraseña en el formulario de acceso.
2. Obtenemos el documento de Couchbase que tiene la clave lily@newdomain.com.
3. Vemos que el valor de ese documento es 1001, así que GET el documento de perfil de usuario con la clave 1001.
4. Verificamos la contraseña con el hash del perfil de usuario.
5. Si tiene éxito, completamos el inicio de sesión y Lily sigue a lo suyo.

Con la mayoría de los sistemas de bases de datos, eso podría introducir un retraso inaceptable, pero con Couchbase la búsqueda adicional debería estar por debajo del milisegundo. Esto abre un amplio abanico de índices manuales que podríamos introducir: Manejadores de Twitter, números de teléfono, ciudades, etc.

Por supuesto, en introduce un poco más de trabajo en la capa de aplicación pero, a cambio, obtenemos la flexibilidad de los índices secundarios conservando toda la velocidad y escalabilidad que nos hizo elegir Couchbase Server en primer lugar.

La próxima vez me fijaré en los nombres de las teclas.