Luego he preparado un test con PHP basado en una lista de 1000 frases generadas con el famoso “lorem ipsum”. El test consiste en insertar 1.000.000 de entradas del tipo id1=texto, id2=texto….id1000000=texto. Para comparar he hecho el mismo test contra MySQL.

El equipo de pruebas es el portátil que tengo, un Dell Inspiron 6400 de hace un tiempo con un Core Duo a 1.7Gh con 1GB de RAM, corriendo Ubuntu 8.04.

Los resultados no han sido satisfactorios: MySQL 1 minuto 30 segundos, Redis 1 minuto 20 segundos. Yo lo achaco a que el cliente PHP para Redis no está optimizado, tampoco se integra “dentro” de PHP como si lo hace el cliente MySQL, que se carga como un módulo.

He dejado una nota en la página de Benchmarks de Redis.

Por si alguien le interesa, aqui dejo el código utilizado: testredis.tar.gz Si alguien encuentra algún fallo en el código le agradecería que me lo indicara.

Actualización: Mientras he escrito este post, antirez, el creador de Redis, me ha respondido en el wiki.

Posts relacionados:

1. Más bases de datos ligeras
2. Minipost: Excelente artículo sobre escalabilidad

Drizzle viene a ser MySQL pero aligerado, muy orientado a lo que se necesita en un servidor web. Pero parece que su desarrollo aún está verde.

Redis, que he descubierto gracias a carrero, es una base de datos clave-valor, que tiene muy buena pinta y que quiero probar pronto. Hay un ejemplo desarrollado, y muy bien explicado, de un clon de Twitter.

Posts relacionados:

1. Bases de datos clave-valor
2. Probando Redis

Todo se deja a la aplicación, siendo la base de datos, simplemente donde guardamos los datos. No se verifican integridades, no se comprueban referencias cruzadas, todo eso se ha de implementar a nivel de aplicación, de código cliente.

En un sistema relacional tenemos bases de datos y dentro de cada base de datos tenemos tablas formadas por filas y columnas. En un sistema clave-valor tenemos contenedores, también se les llama cabinets, en cada contenedor podemos tener tantas parejas de clave-valor como queramos, hay sistemas que permiten tener claves duplicadas y hay que no, o que se puede indicar que no queremos que se dupliquen. En cada contenedor podemos tener datos de la misma naturaleza (por ejemplo productos, pedidos, clientes, etc) o totalmente diferente (podríamos tener un contenedor por cliente), eso depende de nosotros, de la aplicación.

A cada clave se asocia un valor (clave=valor), por ejemplo: “Nombre=Jose”, “Apellido=Hernandis”. Pero claro, eso no tiene mucho potencial, si queremos añadir otra persona, ¿cómo lo hacemos? El truco está en la “clave”.

Vamos a suponer que estamos montando un sistema que requiere de identificación de usuarios, vamos a suponer que tenemos un contenedor para los usuarios y otro para los datos de estos (nombre completo, email, fecha nacimiento, etc.). Podríamos hacer que en el primer contenedor la clave fuera el nombre de usuario y el valor la contraseña, así (esto es una versión simplificada):

[users.cab]

pepe=patata
juan=minino
mario=ferrari

En otro contenedor podríamos tener los datos de los usuarios:

[user_data.cab]

pepe_nombre=Jose Alberto
pepe_email=ja@ja.com
pepe_fecha=19700315
juan_nombre=Juan Antoni
juan_email=juan@hatmail.com
juan_fecha=19800218
mario_nombre=Mario Garcia
mario_email=mgarcia@micorreo.es

Esto es una versión simplificada, hay bases de datos clave-valor más sofisticadas, llamadas orientadas a documentos, como CouchDB. Otras permiten estructuras más complejas como almacenar arrays asociados a una clave. Incluso “simular” tablas con sus columnas.

Como se ve la clave se forma por el usuario+dato (usuario_dato), de esa forma, al loguearse un usuario podemos preguntar al primer contenedor que nos devuelva la contraseña del usuario, si no devuelve nada el usuario no existe, si devuelve algo verificamos la contraseña y si es correcta podemos recuperar el resto de valores.

Una alternativa sería en el contenedor user.cab poner el usuario y un ID único, tipo un GUID y utilizar ese GUID para poner la clave a los valores del segundo contenedor.

Hay sistemas que permiten utilizar comodines a la hora de recuperar valores, por ejemplo se puede pedir que devuelva una lista con las claves que coincidan con juan_* de forma que recuperemos juan_nombre, juan_email y juan_fecha. Como se puede ver, del usuario mario no tenemos fecha de nacimiento, si dicho usuario no la ha proporcionado, no tenemos porque almacenarla.

En algunos sistemas los valores se guardan siempre como cadenas, en otros los valores están tipificados: cadena, entero, flotante, fecha, etc.

Las bases de datos clave-valor no están pensadas para el análisis de datos, sino para el almacenamiento puro y duro. Si necesitamos analizar los datos almacenados así, mejor que los pasemos primero a un sistema relacional o, mejor todavía, a un OLAP.

Esto mismo se puede implementar en una base de datos relacional, de hecho es algo que se viene haciendo desde hace años, básicamente para guardar configuraciones. Se trata de utilizar un diseño vertical en lugar de horizontal, me explico:

Horizontal:

Vertical:

Se requieren dos tablas para esta variante, al igual que se requerían dos contenedores para el sistema clave-valor.

Usuarios

DatosUsuarios

Cada uno de los modelos tiene su pros y sus contras: El horizontal es más sencillo de entender, es más habitual, pero más dificil si crece o se requieren cambios de estructura. El vertical se complica un poco, requiere de unas conversiones de tipos de datos puesto que todo se almacena como cadena o no es sencillo hacer consultas que devuelvan los datos en formato tabla, pero a cambio tenemos unas ventajas como que no es preciso que todos los usuarios tengan los mismos datos, que es inmediato añadir o eliminar datos sin necesidad de reestructurar la tabla, o que cada tabla podría estar en un servidor diferente.

Una lista de los diversos sistemas de bases de datos clave-valor: Anti-RDBMS

Posts relacionados:

1. Más bases de datos ligeras

A través de ese blog he encontrado un excelente artículo que trata varios temas de como escalar una aplicación típica web basada en LAMP: Database sharding at Netlog

Posts relacionados:

1. Minipost: Velocidad vs Calidad
2. Minipost: JSON vs. XML