En este artículo no se plantean las posibilidades del cloud computing.

Cada vez son más los profesionales que se plantean el uso de bases de datos no relaciones para optimizar el rendimiento de sus Aplicaciones Web. La llegada al mercado de los ORM ha simplificado la portabilidad y dependencia de las aplicaciones web.

En base a mi experiencia, los entornos con miles de usuarios concurrentes en los que la mayor parte de la información se genera en base a las acciones de los usuarios experimentaran un mejor rendimiento a nivel de sistemas ( servicios y hardware) con un sistema no relacional.

Integración de Aplicaciones

Cada vez es más corriente encontrar el concepto de Integración por Base de Datos Compartida, en donde se integran múltiples aplicaciones mediante el uso compartido de una única base de datos. Cuando se tiene estas Bases de Integración, es importante que todas las aplicaciones puedan recuperar fácilmente todos los datos compartidos, de ahí la importancia del acceso a los datos.

Ya es un hecho que las aplicaciones hablen entre ellas a través de documentos de texto (en general, XML, SOAP, JSON) sobre HTTP.

Si tomamos como protocolo de integración HTTP, podremos cambiar el modelo de Bases de Integración por Bases de Aplicación. Este cambio es profundo. Como primer paso permite un enfoque mucho más simple para el mapeo objeto-relacional. Rompe con la necesidad de los modelos de datos relacionales. Al integrar aplicaciones a través de  HTTP, deja de importar cómo una aplicación almacena sus datos, lo que a su vez significa que una aplicación puede elegir el modelo de datos que tiene más sentido para sus necesidades.

Sistemas de Base de Datos, hoy

¿Cuáles son las opciones que tenemos a la hora de escoger un sistema de base de datos para una aplicación web?

Bases de datos relacionales clásicas

• MySql
• PostgreSQL
• Oracle
• MSSql Server

No comentaré sus características porque considero que son bastante conocidas por la mayoría  del público que lea este artículo

Bases de datos no relacionales / orientada a objetos

SimpleDB

Tiene algunas limitaciones. La primera es que una consulta no puede durar más de 5 segundos. La segunda, que no hay más tipos de datos que cadenas de texto. Cada almacenamiento, recuperación o comparación se realiza en formato de cadena de texto (string), por lo que las comparaciones de fechas no funcionan a menos que se éstas se conviertan al formato ISO8601. La tercera, el tamaño máximo de cada cadena de texto es de 1024 caracteres, lo cual limita mucho los textos (como descripciones de productos, etc.) que puedes almacenar un atributo simple. Pero debido a que el esquema es dinámico y flexible, puedes superar esta limitación añadiendo atributos “DescripcionProducto1″, “DescripcionProducto2″, etc.  El límite por cada elemento es de 256 atributos. Mientras SimpleDB sea Beta, los dominios no pueden ser más grandes de 10GB, y las bases de datos enteras no pueden superar 1TB.

Una característica clave de SimpleDB es que utiliza un modelo de consistencia eventual. Este modelo de consistencia es bueno para la concurrencia, ya que después de haber cambiado un atributo en un elemento, los cambios no serán reflejados en las operaciones de lectura inmediatas a dicho cambio. Esto hay que tenerlo muy en cuenta en casos como, por ejemplo, cuando no quieras vender la última entrada de un concierto en el sistema de reserva para cinco personas debido a que los datos no fueron consistentes en tiempo de venta.

Google AppEngine Datastore (BigTable)

Google AppEngine Datastore está construido con BigTable, el sistema de almacenamiento interno de Google para la manipulación de datos estructurados. En sí mismo, Google AppEngine Datastore no es un mecanismo de acceso directo a BigTable, si no una especie de interfaz simplificada superpuesta a BigTable.

El AppEngine Store soporta muchos más tipos de datos y elementos que SimpleDB, incluyendo tipos de lista, que contiene colecciones dentro de un elemento simple.

Sin embargo, no podrás realizar interfaces con el AppEngine Datastore (o con BigTable) utilizando aplicaciones externas a la plataforma de servicios web de Google.

CouchDB

CouchDB es una base de datos orientada a documentos, open source y gratuita. Derivada del almacenamiento clave/valor, utiliza JSON para definir el esquema de un elemento. CouchDB está concebida para tender un puente al hueco que existe entre bases de datos relacionales y bases de datos orientadas a documentos gracias a las “vistas”, que pueden ser creadas dinámicamente a través de JavaScript. Estas vistas mapean los datos del documento en estructuras similares a tablas que pueden ser indexadas y consultadas.

Mongo

Mongo es el sistema de base de datos desarrollada en 10gen por Geir Magnusson y Dwight Merriman (recordemos de DoubleClick). Como CouchDB, Mongo es una base de datos orientada a documentos JSON, salvo que está diseñada para ser una verdadera base de datos de objetos, más que para un almacenamiento de clave/valor puro. Originalmente, 10gen enfocó poner juntos una pila completa de servicios web, aunque sin embargo, más recientemente ha tenido que ser reenfocado principalmente en la base de datos Mongo.

Cassandra

Este sistema de base de datos fue desarrollado por Facebook, abandonando el prestigioso MySQL. Este sistema ya forma parte de la incubadora de proyectos de Apache. Cassandra es open source, altamente distribuido, y tiene un modelo de datos similar al de BigTable (Google). Entre sus características cabe destacar la alta disponibilidad, consistencia eventual, escalabilidad incremental, replicación optimista, administración mínima. Posee API para acceder desde lenguajes de programación tales como C++, C#, Java, Perl o PHP (entre otros).

Por qué escoger una base de datos no relacional

Entre otras, destacaría cinco puntos por los cuales se debería optar por una plataforma de base de datos no relacional clave/valor para una aplicación:
1) Los datos están fuertemente orientados a documentos, haciéndolos más acordes y naturales con el modelo de datos clave/valor que con el modelo de datos relacional.
2) El entorno de desarrollo está fuertemente orientado a objetos (ORM), y una base de datos clave/valor podría reducir la necesidad de código “tubería”.
3) El almacenamiento de datos (escritura) es económico y se integra fácilmente con la plataforma de servicios web de tu proveedor.
4) Disponen de una escalabilidad distribuida.

5) El futuro del almacenamiento de datos es necesariamente distribuido y con una o varias capas de caches de gran tamaño
Esto no significa el fin de las bases de datos relacionales, de hecho son la elección apropiada para muchos escenarios pero si se debe tener en cuenta como profesional cuál es la elección apropiada para las necesidades y perspectivas de crecimiento y negocio del cliente.

La escalabilidad, el rendimiento y la integración forman ya parte de las características de un negocio en Internet.