Roberto M. Oliva

Voy a empezar a escribir esta entrada y no la voy a terminar, en breve, ya que la voy a utilizar como herramienta de investigación e irá creciendo a la par que voy adentrándome en el mundo de los Document-oriented Database.

Las Document-oriented Databases suponen un enfoque distinto de almacenamiento de datos al que proponen las tradicionales RDBMS (Relational Data Base Management System). No pretenden suplantar a éstas, sino más bien presentar una solución diferente a una serie de problemas comunes en el tratamiento de datos como puedan ser los cambios constantes de estructura, la tolerancia a fallos o la clusterización, por decir algunos.

Las diferencias básicas entre ambos tipos de bases de datos se pueden ver en la siguiente tabla (Obtenida de What_is_Couch):

SQL -> CouchDB
Esquema explícito predefinido -> Esquema implícito dinámico
Tablas de datos uniformes -> Coleccion de documentos con estructura variable
Normalizado. Los objetos se expanden en varias tablas. Dulicacioón reducida -> Desnormalizado. Los documentos se autocontienen. Los datos suelen estar duplicados.
Se debe de conocer el esquema antes de escribir o leer un objeto completo -> Solo es necesario conocer el nombre del documento.
Consultas dinámicas de esquemas estáticos -> Consultas estáticas de esquemas dinámicos.

Me ha gustado mucho el siguiente enlace: Is the Relational Database Doomed?. En él, el autor, expone los siguientes apuntes:
- Las bases de datos RDBMS han cumplido de manera eficaz las mayor parte de las necesidades de las aplicaciones. Simplicidad, seguridad, flexibilidad, rendimiento, escalabilidad y compatibilidad han sido sus vritudes generales, siendo algunas mejores en algunos puntos que en otros. Lo que ha ocurrido es que, a día de hoy, una de estas necesidades ha adquirido un protagonismo mucho más critico que el de todas las demás. Concretamente el de la escalabilidad.
- Los beneficios principales de una base de datos orientada a documento son los siguientes: Muy adecuado para funcionar en la nube y encaja de una manera más natural con el código.
- Por contra, los inconvenientes son los siguientes: El modelado del código no recae en la base de datos, sino en la aplicación (capa de negocios) y limitaciones en las consultas.
- Por último, recomienda usar estas bases de datos cuando: Los datos estén muy orientados a documento (obviamente), el entorno de desarrollo sea muy orientado a objetos, el almacen de datos sea “barato” y este bien integrado en el servicio de hosting y, por último, que la mayor preocupación se centre en ofrecer una aplicación altamente disponible y con gran velocidad de acceso a datos.

También es interesante la comparación de herramientas que realiza la siguiente entrada: Anti-RDBMS: A list of distributed key-value stores. Aparte de que la introducción es graciosa (pero con sustancia). Motivos por los cuales elegir una base de datos orientada a documento:
1. Sufres de Aplicación-en-la-nubemanía.
2. Necesitas una excusa para utilizar Erlang (Varias de estas DB’s están desarrolladas utilizando Erlang).
3. Has oido que CouchDB mola.
4. Odias MySQL y, aunque PostgreSQL está mucho mejor, no tiene ningún mecanismo de replicación decente y no hay posibilidad de comprar las licencias de Oracle.
5. Tus datos se almacenan y se obtienen, casi siempre, a través de su clave primaria y sin utilizar consultas complejas.
6. Tienes una cantidad de datos nada trivial y te da miedo manejar estructuras de RDBMS con sistemas de replicación y tolerancia a fallos.

Garcias a estas dos páginas y a alguna más, he encontrado la siguiente lista de bases de datos orientadas a documentos:

ThruDB
Project Volemort
MonetDB
Neptune
Redis
Tokyo Tyran + Tokyo Cabinet
HBase
Dynomite
Scalaris
Ringo
CouchDB
MongoDB
Cassandra

También ha bvisto otros sistemas de BD’s a tener en cuenta:
Virtuoso
Zope Object Database
Schemafree (MySQL Addon)
neo4j
Vertica
Drizzle

Como primer resúmen (dado desde la visión superficial que tengo actualmente) se podría decir que si las necesidades de la aplicación pasan por ser muy rápida y muy escalable (considerando si se va a trabajar con ingentes cantidades de registros) y si la estructura va a variar bastante a costa de necesitar una mayor inversión en desarrollo del modelo (aquí me gustaría incidir en que, si los testeos ya de por si son importantes, aquí lo son más aún) este tipo de bases de datos es una muy buena opción. Lo que esta claro es que cada tipo de base de datos tiene su lugar y hay que aprender a diferencia cuando conviene un tipo sobre otro.

A través de este blog y, siempre que el tiempo me lo permita, iré añadiendo datos sobre mis pesquisas sobre este mundo que está resurgiendo poco a poco y que es, cuando menos, bastante interesante.