No todo es relacional
Antes de nada quisiera explicar que no soy un experto en bases de datos y que voy a explicar algunos conceptos muy por encima, por lo que cometeré imprecisiones y puede que meta la pata en algo. Espero que les sirva la idea general y que no se intenten buscar una clase de bases de datos en este texto. De todas formas, si ven algo que está equivocado, no duden en decírmelo para corregirlo.
Existen muchos tipos de bases de datos, pero quizás desde hace unos años casi que sólo se hablaba (salvo en entornos muy concretos) de bases de datos relacionales. Las más conocidas quizás en el mundo del software libre son MySQL, PostgreSQL o incluso SQLite. Pero hay otro tipo de base de datos que lleva ya un par de años empezando a oírse más. Se trata de las bases de datos orientadas a documentos.
Creo que se podría decir que la principal diferencia entre una base de datos relacional y una orientada a documentos es que en esta última los registros no tienen que ser uniformes. Es decir, que no hay una estructura fija en las tablas que hay que respetar a la hora de introducir nuevos datos, sino que se añaden los datos de forma estructurada en un campo del registro, pero el número de campos o el contenido de los mismos no tiene que estar preestablecida.
En estas bases de datos los documentos son objetos que tienen propiedades y éstas pueden irse añadiendo o quitando sin que sea necesario volver a definir las estructuras de la tabla.
Quizás parezca un tanto raro sin un ejemplo. Pongamos que queremos hacer una base de datos de libros e, inicialmente, hemos pensado que los datos que queremos guardar son el «títulos», el «autor» y una breve «descripción».
| Id | Título | Autor | Descripción |
| 01 | El Ocho | Katherine Nevilla | Una historia de... |
| Id | Documento |
| 01 | Titulo:El Ocho ; Autor: Katherine Neville ; Descripción: Una historia de... |
A continuación comenzamos a introducir libros, pero resulta que cuando llevamos 100, nos damos cuenta de que queremos guardar también la «temática». Veamos cómo se solucionaría el problema con un modelo relacional y con uno orientado a documentos.
Con el modelo relacional, se modificaría la estructura de la tabla y ya se podrían meter esos nuevos datos. Hay que tener en cuenta que es necesario bloquear la escritura de nuevos datos en la tabla, antes de empezar a modificar dicha estructura, de otro modo podrían producirse inconsistencias
En el modelo orientado a documentos, simplemente se añadiría el nuevo campo «temática» en aquellos libros en los vayamos a introducir algún valor. Al no tener una estructura fija, no es necesario modificarla, simplemente añadir el nuevo campo en los registros que lo necesiten.
Bien, todo esto era para hablar de una base de datos libre orientada a documentos y que está bastante de moda últimamente. Se trata de CouchDB.
Esta base de datos tiene muy buena pinta y la están usando en entornos muy diversos, pero casi siempre relacionado con la web. Esto es básicamente porque es una base de datos distribuida que posee una API (Application Programming Interface) RESTful (Representational State Transfer) en JSON (JavaScript Object Notation) que puede ser accedida vía peticiones de HTTP (HyperText Transfer Protocol).
Aparte de esta API y las características propias de estar orientada a documentos, tiene algunas otras características que la hacen interesante, como que es muy fácil de replicar, tiene una alta tolerancia a fallos y posee un sistema de vistas basado en funciones JavaScript que permite definir diferentes estructuras, para los mismos datos, con las que vamos a mostrar los datos. Esto último viene a suplir esa falta de estructura de la que hablaba antes, pero dando la flexibilidad de poder definir la estructura bajo demanda y de poder definir varias.
Quizás porque suelo trabajar mucho con sistemas de control de versiones, hay algo en esta base de datos que me recuerda mucho a ellos. En concreto a los distribuidos. Y es que CouchDB asigna un identificador único a cada registro y los versiona. Estos son los únicos dos campos obligatorios en cualquier «documento» de esta base de datos, el «_id» y el «_rev». Además el identificador es un «hash» único, no un índice auto-incremental. Esto permite que se puedan añadir registros en dos servidores diferentes y luego mezclarlos sin que se pisen los índices. Y con las revisiones siempre se puede volver a versiones anteriores del «documento».
Para que se hagan una idea del tipo de cosas que se pueden hacer con esta tecnología, tienen varios ejemplos como el Ubuntu One, que lo usa para sincronizar archivos, contactos y notas entre distintos dispositivos. Cada uno de esos objetos es un documento dentro de la base de datos de Ubuntu One. Pero existe una base de datos local, en cada uno de los equipos que se quiera sincronizar, y otra en el servidor central que da este servicio. Con esto lo que se tiene es una base de datos replicada en distintos sitios y que pueden trabajar desconectadas unas de otras, pero que sincronizan de forma bidireccional sus registros una vez se conectan.
La verdad es que he estado jugando un poco con CouchDB y resulta sencillo probarlo con su interfaz web «Futon», pero también desde Python, JavaScript o Ruby. Además, existe un proyecto dentro de Freedesktop.org del que vi una charla en el Fosdem que se llama DesktopCouch y que sirve para usar CouchDB en aplicaciones de escritorio. Esto es muy interesante para tener aplicaciones nativas en el escritorio, el móvil o en donde sea cuyos datos se puedan almacenar en algún servidor (en la nube...) y que se vayan sincronizando.
En este sentido podríamos hablar de aplicaciones de contactos, fotos, sincronización de documentos, de enlaces, de notas, un blog, microbloging o algún tipo de herramienta colaborativa en la que necesitas cierta flexibilidad en la estructura de los documentos que manejas, al tiempo que debes sincronizar datos de varias fuentes diferentes.
En fin, que ideas hay muchas y seguro que veremos muchos ejemplos ingeniosos sobre cómo sacarle partido a estas bases de datos. Claro que tampoco habrá que caer ahora en el típico «tengo un martillo, luego todos mis problemas son... ¡documentos!» ;-)
Comentarios
cifunet:
Hola, me ha sido de mucha utilidad este post, no sabía que era un proceso llamado destopkcouch-service (ya pensaba en troyanos y eso) que hoy me dejó petao el Lucid cuando pulse altGr con algo mas.
Supongo que Murphy andará detrás y el ubuntu one.
No estaría de mas poner un cerrojo por ahí para evitar sustos al personal.
Buen trabajo.
fontanon:
Se que couchdb tiene 'features' como autorreplicación. Estaba pensando si sería posible utilizar esa característica para la recolección automática de datos desde diversos equipos a un recolector.
Imagina diversos equipos corriendo una aplicación cuyos datos se tratan con couchdb. Una máquina externa recolectora podría ir recibiendo cada vez que se aplica un cambio en cada uno de los equipos fuente. Quiero investigar si esto es posible.
"No existen los hechos, solo las interpretaciones" La verdad es conquista de la voluntad de poder. (Nietzsche)
jojeda:
Bueno, la idea es que se «autoreplican» las bases de datos, es decir, es la misma base de datos.
Lo veo muy interesante. Lo único que tienes que tener en cuenta es que las bases de datos en cada una de las máquinas es la misma. Es decir, son instancias de la misma base de datos, no es como un LDAP que puede cada nodo ser una rama del árbol total.
Te lo digo porque la base de datos completa estaría en todos los nodos (máquinas) y eso tendría que tenerse en cuenta por temas de espacio (si son muchos datos y máquinas la base de datos podría crecer mucho) y por seguridad (todas las máquinas tendrían en local el contenido completo de la base de datos).
De resto, lo único que necesita el sistema realmente para funcionar es que la máquina «recolectora» vea vía HTTP a las otras, puesto que la replicación se hace vía REST.
Juanje
drodriguez:
Un abrazo. Agur.
David Rodríguez Vicente