La nueva generación (de bases de datos)

Segunda parte de este interesante artículo sobre el presunto declive de las bases de datos relacionales.
Artículo anterior: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php
Fuente: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php?p=2


Este nuevo tipo de sistema de gestión de bases de datos es conocido comúnmente como almacenamiento por clave/valor. De hecho, no existe aún un nombre oficial, por lo que puedes obtener referencias tales como "orientado a documento", "orientado a Internet", "orientado a atributos", "base de datos distribuida" (aunque esto puede ser también una base de datos relacional), "colecciones de fragmentos ordenados", "tablas hash distribuidas" y "bases de datos clave/valor". Cada uno de estos nombres apuntan a un rasgo específico en esta nueva propuesta, todas son variaciones en un mismo tema, por lo cual las llamaremos bases de datos clave/valor.

Sea cual sea el nombre con que las llames, este "nuevo" tipo de base de datos ha sido ya usado durante mucho tiempo por aplicaciones especializadas para las cuales las bases de datos relacionales eran deficitariamente adecuadas. Pero sin la escala que las aplicaciones web y la nube han traído éstas habrían permanecido como un subconjunto en su mayor parte no utilizado. En la actualidad, el desafío es reconocer si una base de datos relacional es la mejor opción para una aplicación en particular.

Las bases de datos relacionales y las bases de datos clave/valor son fundamentalmente diferentes y diseñadas para cumplir diferentes necesidades. Una comparación cara a cara nos acerca el entendimiento de estas diferencias:

DEFINICION DE BASE DE DATOS
Base de datos relacional	Base de datos clave/valor
La base de datos contiene tablas, las tablas contienen columnas y filas, y las filas están compuestas de valores de columna. Todas las filas dentro de una tabla tienen el mismo esquema. El modelo de datos está bien definido por adelantado. Un esquema está fuertemente definido y tiene restricciones (constraints) y relaciones que fuerzan la integridad. El modelo de datos está basado en una representación "natural" de los datos que contiene, no en la funcionalidad de la aplicación. El modelo de datos está normalizado para eliminar la duplicación de datos. La normalización establece relaciones de tablas. Las relaciones asocian datos entre tablas.	Los dominios pueden ser inicialmente asociados como tablas, pero a diferencia de las tablas, no se define ningún esquema para un dominio. Un dominio es básicamente un cubo en donde se meten elementos en su interior. Los elementos dentro de un dominio simple pueden tener diferentes esquemas. Los elementos son identificados por claves, y un elemento dado puede tener adjunto un conjunto dinámico de atributos. En algunas implementaciones, todos los atributos son cadenas de texto (string). En otras implementaciones, los atributos tienen tiene tipos simples que reflejan tipos de código, tales como enteros (int), colecciones de cadena de texto y listas. Ninguna relación es definida explícitamente entre dominios ni en el interior de un dominio dado.

Sin entidades unidas
Las bases de datos clave/valor está orientadas a elementos, lo que significa que todos los datos relevantes relacionados con un elemento están almacenados dentro del elemento. Un dominio (en el cual puedes pensar como una tabla) puede contener vastamente elementos diferentes. Por ejemplo, un dominio puede contener elementos de clientes y elementos de pedidos. Esto significa que los datos están comúnmente duplicados entre los elementos de un dominio. Esto es una práctica aceptada debido a que el espacio de disco es relativamente barato. Pero este modelo permite que un elemento simple pueda contener todos los datos relevantes, lo cual mejora y aumenta la escalabilidad eliminando la necesidad de unir (join) datos desde múltiples tablas. Con una base de datos relacional tales datos necesitan ser unidos para ser capaz de reagrupar los atributos relevantes.

Pero mientras la necesidad de las relaciones es reducida enormemente con bases de datos clave/valor, algunas de éstas son certeramente inevitables. Estas relaciones existen normalmente entre entidades centrales o comunes. Por ejemplo, un sistema de pedidos debería tener elementos que contengan datos sobre clientes, productos y pedidos. Tanto si éstos residen en el mismo dominio o en dominios diferentes es irrelevante, pero cuando un cliente realiza un pedido, probablemente no querrías almacenar tanto los atributos de cliente como de producto en el mismo elemento del pedido.

En lugar de ello, los pedidos necesitarían contener las claves relevantes que apunten al cliente y al producto. Mientras que esto es perfectamente factible en una base de datos clave/valor, estas relaciones no están definidas dentro del propio modelo de datos, así que el sistema de gestión de base de datos no puede forzar la integridad de las relaciones. Esto significa que puedes eliminar clientes y productos que han sido utilizados en pedidos. La responsabilidad de asegurar la integridad de datos cae enteramente en la aplicación.

ACCESO A DATOS
Base de datos relacional	Base de datos clave/valor
Los datos son creados, actualizados, borrados y recuperados usando SQL. Las consultas SQL pueden acceder a datos desde una tabla simple o desde múltiples tablas usando uniones de tablas. Las consultas SQL incluyen funciones para agregar y filtros complejos. Normalmente contiene medios de lógica embebida cerrada para almacenamiento de datos, tales como triggers, procedimientos almacenados y funciones.	Los datos son creados, actualizados, borrados y recuperados usando llamadas a métodos de una API. Algunas implementaciones proveen sintaxis básica similar a SQL para definir criterios de filtro. A menudo pueden aplicarse predicados básicos de filtro (tales como =, !=, <, >, >= y <=). Toda la lógica de aplicación y de integridad lógica de datos está contenida en el código de la aplicación.

INTERFAZ DE APLICACION
Base de datos relacional	Base de datos clave/valor
Tiende a tener su propia API específica, o hace uso de una API genérica, tal como OLE-DB o ODBC. Los datos son almacenados en un formato que representa su estructura natural, así que debe estar mapeada entre la estructura de código de la aplicación y la estructura relacional.	Tienden a proveer SOAP y/o REST APIs sobre los cuales pueden ser realizadas las llamadas de acceso a datos. Los datos pueden estar más eficientemente almacenados en código de aplicación que es compatible con su estructura, requiriendo solamente código relacional a modo de "tubería" para el objeto.

Almacenamiento clave/valor: lo bueno
Hay dos claras ventajas de las bases de datos clave/valor con respecto a las bases de datos relacionales.

Idoneidad para nubes
El primer beneficio es que son simples y de este modo para escalar son mucho mejores que las bases de datos relacionales actuales. Si estás juntando un sistema en casa y tienes la intención de lanzar docenas o centenares de servidores detrás para el almacenamiento abasto de tus datos esperando una demanda masiva en escala, entonces considera un almacenamiento clave/valor.

Debido a que las bases de datos clave/valor escalan fácil y dinámicamente, son también las bases de datos que los vendedores eligen para proveer sistemas multi-usuario y plataforma de almacenamiento de datos para servicios web. La base de datos provee una plataforma de almacenamiento de datos relativamente económica con un potencial masivo para escalar. Los usuarios típicamente pagan sólo por aquello que usan, pero su uso puede incrementarse y también sus necesidades. Mientras tanto, el vendedor puede escalar la plataforma dinámicamente basado en el total de la carga del usuario, con pequeñas limitaciones en el tamaño completo de la plataforma.


Más ajuste natural en código
Los modelos de datos relacionales y los Modelos de Objetos de Código de Aplicación se construyen normalmente de forma diferente, lo que lleva a incompatibilidades. Los desarrolladores sobrellevan estas incompatibilidades con código que mapea los modelos relacionales con sus modelos de objeto, un proceso comúnmente referido como "mapeo de objeto a relacional". Este proceso, el cual acumula esencialmente código a modo de "tubería" y que no tiene un claro e inmediato valor, puede tomar un trozo importante del tiempo y del esfuerzo dedicado al desarrollo de la aplicación. Por otro lado, muchas bases de datos clave/valor retienen datos en una estructura que mapea más directamente los objetos de clase usados en el código de la aplicación, lo cual reduce significativamente el tiempo de desarrollo.


Almacenamiento clave/valor: lo malo
Las restricciones inherentes de una base de datos relacional asegura que los datos en el nivel más bajo tengan integridad. Los datos que violan las restricciones de integridad no pueden ser introducidas en la base de datos de forma física. Estas restricciones no existen en una base de datos clave/valor, así que la responsabilidad de asegurar la integridad de los datos cae enteramente en la aplicación. Pero el código de aplicación a menudo acarrea errores. Una base de datos relacional correctamente diseñada no lleva a errores en cuestión de integridad de datos; una base de datos clave/valor, sin embargo, lleva fácilmente a errores en cuestión de integridad de datos.

Otro beneficio clave de una base de datos relacional es que te fuerza a seguir un proceso de modelado de datos. Si está bien hecho, este proceso de modelado crea en la base de datos una estructura lógica que refleja los datos que contiene, en lugar de reflejar la estructura de la aplicación. Entonces los datos se hacen independientes de la aplicación, lo que significa que otras aplicaciones pueden usar los mismos datos y la lógica de la aplicación puede ser cambiada sin perturbar el modelo de datos que hay por debajo. Para facilitar este proceso con una base de datos clave/valor, intenta reemplazar un ejercicio de modelado de datos relacional con un ejercicio de modelado de clase, el cual genere clases genéricas basadas en la estructura natural de los datos.

Y no olvidemos la compatibilidad. A diferencia de las bases de datos relacionales, las bases de datos orientadas a nube tienen poco de estándares compartidos. Mientras que todas ellas comparten conceptos similares, cada una tiene su propia API, interfaces de consulta específicas, y peculiaridades. De esta manera, necesitarás confiar realmente en tu vendedor, porque no serás simplemente capaz de cambiar la línea si no estás satisfecho con el servicio. Y debido a que casi todas las bases de datos clave/valor aún están desarrollándose la confianza es más arriesgada que con una base de datos relacional de la vieja escuela.


Limitaciones en analíticas
En la nube, las bases de datos clave/valor son normalmente multi-inquilino, lo cual significa que muchos usuarios y aplicaciones usarán el mismo sistema. Para prevenir cualquier proceso de sobrecarga del entorno compartido, la mayor parte de los almacenes de datos en nube limitan estrictamente el impacto total que cualquier consulta simple pueda causar. Por ejemplo, con SimpleDB tú no puedes ejecutar una consulta que tome más de 5 segundos. Con Google's AppEngine DataStore, no puedes recuperar más de mil elementos por cada consulta.

Estas limitaciones no son un problema para la lógica de tu aplicación (añadir, actualizar, eliminar y recuperar un número pequeño de elementos). Pero, ¿qué ocurre cuando tu aplicación se convierte en exitosa? Has atraído a muchos usuarios y has pedido muchos datos y ahora quieres crear nuevos valores para tus usuarios o quizá usar los datos para generar nuevos ingresos. Puedes encontrarte a tí mismo limitado en ejecutar consultas sencillas de estilo analítico. Con este tipo de plataforma de base de datos, cosas como rastreo de patrones de uso y recomendaciones de provisión basadas en historias de usuario difíciles en el mejor de los casos, imposibles en el peor.

En este caso, es probable que tengas que implementar una base de datos analítica por separado, en la cual las analíticas puedan ser ejecutadas. ¿Pensar por adelantado de dónde y cómo deberías ser capaz de hacer ésto? ¿Deberías hospedarla en la nube o invertir en una infraestructura on-site? ¿Podría la latencia entre tú y el proveedor del servicio en nube plantear un problema? ¿Tu base de datos clave/valor basada en nube soportar ésto? Si tienes 100 millones de elementos en tu base de datos clave/valor, pero sólo puedes sacar 1000 elementos a un tiempo, ¿cuantas consultas se deberían realizar?

En última instancia, mientras escalar es una consideración, no antepongas tu habilidad de convertir los datos en un activo propio. Todas las escalas en el mundo son inútiles si tus usuarios se han ido a tu competidor porque tiene frescura y tiene más características personalizadas.