Fuente: http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php
Recientemente, un cierto número de bases de datos no relacionales han surgido tanto dentro como fuera de la nube. Un mensaje clave nos envían: "si quieres algo vasto o extenso, escalabilidad bajo demanda, entonces necesitas una base de datos no relacional".
Si esto es cierto ¿es ésto una señal de que las bases de datos relacionales tienen una grieta en su armadura?. ¿Es ésto una señal de que las bases de datos relacionales han tenido ya sus días y declinarán ante su prórroga?. En este post echaremos un vistazo a las actuales tendencias para migrar de las bases de datos relacionales en ciertas situaciones y qué significa ésto para el futuro de las bases de datos relacionales.
Las bases de datos han estado con nosotros alrededor de 30 años. Durante este tiempo algunas presuntas revoluciones estallaron brevemente, todas ellas supuestamente para augurar el fin de las bases de datos relacionales. Todas aquellas revoluciones fracasaron, por supuesto, y ninguna hizo mella en el dominio de las bases de datos relacionales.
Lo primero, algo de formación
Una base de datos es, esencialmente, un grupo de tablas (entidades). Las tablas están compuestas de columnas y filas (tuplas). Además, las tablas tienen restricciones (constraints) que definen relaciones entre ellas. Las tablas son consultadas mediante SQL, que producen conjuntos de resultados originados por el acceso a los datos de una o varias tablas. Múltiples tablas accedidas en una consulta simple están, en realidad, "unidas" juntas, típicamente por un criterio definido en las columnas de la tabla relacionada. La normalización es un modelo de estructuración de datos usado con bases de datos relacionales que asegura la consistencia y elimina la duplicación de datos.
Los Sistemas de Gestión de Bases de Datos Relacionales (RDBMS) facilitan las bases de datos relacionales. Casi todos los sistemas de bases de datos que usamos en la actualidad son RDBMS, tales como Oracle, SQL Server, MySQL, SyBase, DB2, Teradata, etc.
Las razones del dominio de las bases de datos relacionales no son triviales. Contínuamente ofrecen la mejor mezcla de simplicidad, robustez, flexibilidad, rendimiento, escalabilidad, y compatibilidad en gestión de datos genéricos.
Sin embargo, para ofrecer todo esto, las bases de datos relacionales tienen que ser increíblemente complejas internamente. Por ejemplo, una relativa sencilla instrucción SELECT podría tener cientos de potenciales vías de ejecución de la consulta. Todo esto está oculto para nosotros como usuarios, pero bajo la cubierta, los RDBMS determinan el "plan de ejecución" que mejor responda a nuestras peticiones, utilizando cosas como algoritmos basados en costes.
El problema con las bases de datos relacionales
Incluso aunque los RDMBS hayan provisto a los usuarios de bases de datos con la mejor mezcla de simplicidad, robustez, flexibilidad, rendimiento, escalabilidad y compatibilidad, su rendimiento en cada una de esa áreas no es necesariamente mejor que aquel que una solución alternativa que persigue estos beneficios de forma aislada. Esto no tuvo mucho de problema debido al dominio universal que los RDMBS ha sido mayor que la necesidad de desplazar estos límites. No obstante, si realmente tuviste una necesidad que no pudiera ser resuelta por una base de datos relacional genérica, las alternativas estuvieron siempre ahí para llenar esos nichos.
Hoy estamos en una situación ligeramente diferente. Para un número incremental de aplicaciones, uno de sus beneficios es convertirse en más y más críticos; y mientras aún es considerado un nicho, es rápidamente convertido en principal, así por tanto, para un número incremental de usuarios de bases de datos este requerimiento está empezando a eclipsar a otros en importancia. Ese beneficio es la escalabilidad. A medida que más y más aplicaciones son lanzadas en entornos que tienen cargas de trabajo masivas, tales como servicios web, sus requerimientos de escalabilidad pueden, lo primero de todo, cambiar muy rápidamente y, en segundo lugar, crecer en gran medida. El primer escenario puede se difícil de gestionar si tienes una base de datos relacional colocada en un servidor simple en casa. Por ejemplo, si tu carga se triplica de noche, ¿cómo puedes actualizar rápidamente tu hardware? El segundo escenario puede ser también difícil de gestionar con bases de datos relacionales en general.
Las bases de datos relacionales se escalan bien, pero normalmente sólo cuando la escala ocurre en un servidor simple de un nodo. Cuando la capacidad de ese nodo simple ha sido alcanzada, necesitas escalar fuera y distribuir su carga a través de un servidor de múltiples nodos. Aquí es cuando la complejidad de las bases de datos relacionales comienza a restregarse contra su potencial para escalar. Intenta escalar cientos o miles de nodos, en lugar de unos pocos, y las complejidades se tornan insostenibles, y las características que hacen a los RDBMS tan atractivos, drásticamente reducen su viabilidad como plataformas para sistemas grandes distribuidos.
Para que los servicios en nube sean viables, los vendedores tienen que tratar esta limitación, porque una plataforma en nube sin un almacenamiento de datos escalable no es maś que una plataforma como todas. Así, para proveer a los clientes con un sitio con escalabilidad para almacenar datos de aplicaciones, los vendedores tuvieron sólo una opción real. Ellos tuvieron que implementar un nuevo sistema de bases de datos focalizada en la escalabilidad, a expensa de otros beneficios que venían con las bases de datos relacionales.
Aquellos esfuerzos, combinados con aquellos de nichos existentes, llevaron a alzar una nueva generación de sistemas de bases de datos.
