viernes, 18 de diciembre de 2009

Contendientes en bases de datos no relacionales

Tercer y último artículo sobre bases de datos no relacionales, basados en el original de Tony Bain. Al final del artículo me he permitido la licencia de actualizar algunos datos y de añadir otras alternativas (el resto está íntegro).
Artículo 1: ¿Están condenadas las bases de datos relacionales? (http://rafinguer.blogspot.com/2009/12/estan-condenadas-las-bases-de-datos.html)
Artículo 2: La nueva generación (de bases de datos) (http://rafinguer.blogspot.com/2009/12/la-nueva-generacion.html)
Fuente: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php?p=3


CONTENDIENTES EN SERVICIOS DE NUBE

Ya hay un número de vendedores de servicios web que ofrecen en la actualidad bases de datos clave/valor multi-inquilino bajo conceptos de "paga según utilizas". La mayor parte de ellos conocen los criterios discutidos en estos artículos, pero cada uno ofrece características únicas y variaciones respecto a los estándares generales aquí descritos. Echemos un vistazo a bases de datos particulares, tales como SimpleDB, Google AppEngine Datastore y SQL Data Services.


Amazon: SimpleDB
SimpleDB es una base de datos clave/valor orientada a atributos disponible en la plataforma de Amazon Web Services. SimpleDB es todavía una Beta pública. Mientras tanto, los usuarios pueden registrarse para una versión "gratuita" - limitada por uso.

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ñao 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
Google AppEngine Datastore está construído 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, inluyendo 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.


Microsoft SQL Data Services
SQL Data Services es parte de la plataforma Azure Web Services de Microsoft. El SDS es un servicio que está en versión Beta y es gratuito con algunas limitaciones en el tamaño de las bases de datos. SQL Data Services es en sí misma una aplicación situada en lo alto de muchos servidores SQL, los cuales crean el almacenamiento de datos por debajo de la plataforma SDS. Mientras que el almacenamiento por debajo pueda ser relacional, tú no tienes acceso a éste; SDS es un almacenamiento clave/valor, como otras plataformas discutidas anteriormente.

Microsoft parece estar sóla entre los tres tipos de vendedores en reconocimiento de que mientras el almacenamiento clave/valor es fenomenal para la escalabilidad, acarrea un gran gasto de gestión de datos cuando es comparado con RDBMS. La aproximación de Microsoft parece ser deshacer hasta los huestos pelados para obtener un buen mecanismo de escalación y distribución, y entonces transcurrido el tiempo fortalecerse, añadiendo características que ayuden a puentear los huecos entre el almacenamiento clave/valor y la plataforma de base de datos relacional.


CONTENDIENTES EN SERVICIOS QUE NO SON DE NUBE

Fuera de la nube existen vendedores de software de base de datos que pueden ser instalados "en casa". Casi todos estos productos son todavía jóvenes, todavía en versiones alpha o beta, pero en su mayoría son software libre (open source); pudiendo tener acceso al código, tú puedas quizás ser más consciente de cuestiones potenciales y de las limitaciones que tú podrías tener con vendedores de soluciones cerradas.


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.



Proyecto Voldemort
El proyecto Voldemort es una base de datos clave/valor distribuida que tiene previsto escalar horizontalmente a través de un gran número de servidores. Está engendrado a partir del trabajo realizado en LinkedIn y, según se informa, utilizado allí donde muchos sistemas tengan requerimientos de escalabilidad muy altos. El Proyecto Voldemort también utiliza un modelo de consistencia eventual, basado en el de Amazon.


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.



Drizzle
Drizzle puede ser considerado como una contrarrestación-propuesta para los problemas que los almacenamientos clave/valor tienen que resolver. La vida de Drizzle comenzó como un resultado indirecto de la base de datos MySQL (6.0). En los últimos meses, sus desarrolladores han removido las características no centrales (no-core) de un host (incluyendo vistas, triggers, sentencias preparadas, procedimientos almacenados, caché de consultas, ACL, y varios tipos de datos), con el objetivo de crear un sistema de base de datos más ligero, simple y rápido. Drizzle puede todavía almacenar datos relacionales. Como apuntó Brian Aker, de MySQL/Sun, "no hay razón de sacar al bebé del agua del baño". El objetivo es construir una plataforma de base de datos semi-relacional a medida para la web y para aplicaciones basadas en la nube ejecutándose en sistemas con 16 cores o más.



TOMAR UNA DECISION
Ultimamente, existen cuatro razones por las cuales deberías optar por una plataforma de base de datos no relacional clave/valor para tus aplicaciones:
1) Tus 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) Tu entorno de desarrollo está fuertemente orientado a objetos, y una base de datos clave/valor podría reducir la necesidad de código "tubería".
3) El almacenamiento de datos es económico y se integra fácilmente con la plataforma de servicios web de tu proveedor.
4) El asunto más importante es que es bajo demanda, con alta escalabilidad final -- esto es, gran escala, escalabilidad distribuida, del tipo que no puede ser conseguida simplemente mediante escalar añadiendo.

Para tomar una decisión hay que recordar las limitaciones de las bases de datos y los riesgos que corres por bifurcación con respecto del plan relacional.

Para el resto de requerimientos, tu mejor opción sea una buena y vieja RDBMS. Así pues, ¿están condenadas las bases de datos relacionales? Claramente, no. Al menos, no todavía.


REFLEXION ADICIONAL
Esta información ha sido incluida al final del artículo, y no forma parte del artículo original.

A lo largo de este y los dos anteriores posts, hemos echado un vistazo a esta filosofía de almacenamiento, sus virtudes, sus defectos y la comparativa con las RDBMS para podernos hacer una imagen más exacta de cuáles pueden ser nuestras mejores opciones a la hora de emprender un proyecto.

Ha surgido un movimiento denominado NOSQL, con carácter rebelde, criticando las RDBMS y ensalzando las virtudes de las nuevas alternativas (recomiendo mi anterior artículo: Movimiento NOSQL: la alternativa a las bases de datos relacionales. No caigamos en el error de la anarquía. Las RDBMS han estado tanto tiempo con nosotros porque funcionan y son necesarias. Recomiendo conocer ambas filosofías, sus pros, sus contras. Recomiendo probar y hacernos una idea más exacta de qué va a ser lo que necesitemos y de que va a ser lo mejor para nuestros proyectos.

Es cierto que algunas grandes compañías que generan su negocio en Internet, utilizan las bases de datos no relacionales, y que incluso ellas mismas han desarrollado su propio sistema, como Google, Microsoft, Amazon o Facebook. Hay que ver que su negocio es la red, y que su filosofía es la nube. Su negocio es inmenso y requieren de miles de servidores repartidos por todo el mundo. Hemos de comprobar si éste es nuestro escenario o si, por el contrario, nuestro escenario se reduce a un simple servidor al modo tradicional, o a unos pocos servidores en cluster localizados en el mismo edificio, para lo cual, otras alternativas RDBMS van a ser las más adecuadas, como Oracle, SQL Server, MySQL o PostgreSQL.

Quisiera terminar este artículo añadiendo otras bases de datos no relacionales, y que no se comentaron en el artículo final. Espero que os haya sido de interés y de utilidad.


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).

En la actualidad aún está en desarrollo. Es utilizado por Facebook, Digg, Rackspace y otras compañías.

Enlace: http://incubator.apache.org/cassandra/

Recomiendo ver el vídeo y las slides para más información.


HyperTable

Hypertable es una plataforma de base de datos de alto rendimiento para accesos masivos en paralelo, de alta escalabilidad web.

Enlace: http://hypertable.org/