Bases de Datos Relacionales Vs No Relacionales

Jony Coyla Jarita

Universidad Peruana Union , Juliaca 21100, Peru

Resumen

El gran dilema, bases de datos relacionales (RDBMS) y no relacionales (NoSQL), todos preguntan, todos hablan de ello, estamos comparando cual es mejor, en fin, hay una gran incertidumbre en el tema, muchos apuntan a un extremo o al otro, cometen errores y nos olvidamos de ver con objetividad. Quiero explicar de que va todo esto de una forma simple para entendernos. Quiero recordar que grandes volúmenes de datos no son un simple millón de rows, son mucho más, billones por ejemplo, ahora imagina billones de rows que interactúan con otros billones de rows para generar información más significativa, cuando hay grandes volúmenes de información se aprecia todo de una forma diferente, esto impacta en tiempo y dinero.Cada tipo de base de datos nació en una época y con unas necesidades diferentes, y aún ambas son necesarias hoy en día. Todo el problema parte por los grandes volúmenes de datos, ¿Cómo los procesamos?, ¿Como puedo mantener mi infraestructura tecnológica?, ¿Cómo hago para que millones de usuarios puedan usar mi aplicación de forma muy rápida? y quien sabe cuantas preguntas más…En la década de los 70 nacen las bases de datos relacionales que le dan uso a un lenguaje de consulta estructurado llamado SQL, la idea era organizar la información (normalizar) en grupos de datos bajo una semejanza, y así poder mantener una coherencia entre ellos (integridad), fue creciendo el volumen de información pero pocos tenían acceso a manipularla, mientras Internet fue expandiéndose y cada vez más personas acceden a los datos, nos dimos cuenta que los RDBMS son muy lentos, y como fueron diseñados traerían problemas, se inventaron muchas soluciones, pero como todo, se llega a un límite. Y aquí entran las NoSQL, una forma de almacenar y manipular los datos sin necesidad de ser restrictivo como el SQL, con un objetivo muy básico, sacrificar integridad por velocidad.

Palabras clave: Sql, NOsql, Relacional, No relacionaln datos

Abstract

The great dilemma, relational databases (RDBMS) and non-relational (NoSQL), everyone asks, everybody talks about it, we are comparing what is best, in short, there is great uncertainty on the issue, many point to one end or other, make mistakes and forget to look objectively. I want to explain what this is all in a simple to understand. I recall that large volumes of data is not just a million rows, are much more billions for example, now imagine billions of rows that interact with other billions of rows to generate more meaningful information, when large volumes of information all seen in a different way, it impacts time and money.Each type of database and born at a time with different needs, and yet both are needed today. The whole problem partly by the large volumes of data, how we process ?, How can I keep my technological infrastructure ?, How do I get millions of users to use my application very quickly? and who knows how many more questions ...In the 70's are born relational databases that give use a structured query language called SQL, the idea was to organize information (normalize) in datasets under a likeness, so we can maintain consistency between them (integrity), grew the volume of information but few had access to manipulate, while Internet was expanding and more and more people access the data, we realized that the RDBMS are very slow, and as designed would bring problems were invented many solutions, but like everything, it reaches a limit. And here are the NoSQL, a way to store and manipulate data without being restrictive as SQL, with a very basic objective, sacrificing integrity for speed.

1. Introducción

La base de datos relacional (BDR) es un tipo de base de datos (BD) que cumple con el modelo relacional (el modelo más utilizado actualmente para implementar las BD ya planificadas).

Permite establecer interconexiones o relaciones entre los datos (que están guardados en tablas), y a través de dichas conexiones relacionar los datos de ambas tablas, de ahí proviene su nombre: "modelo relacional".

Tras ser postuladas sus bases en 1970 por Edgar Frank Codd, de los laboratorios IBM en San José (California), no tardó en consolidarse como un nuevo paradigma en los modelos de base de datos.

En informática, NoSQL (a veces llamado "no sólo SQL") es una amplia clase de sistemas de gestión de bases de datos que difieren del modelo clásico del sistema de gestión de bases de datos relacionales (RDBMS) en aspectos importantes, el más destacado es que no usan  SQL como el principal lenguaje de consultas. Los datos almacenados no requieren estructuras fijas como tablas, normalmente no soportan operaciones  JOIN, ni garantizan completamente ACID (atomicidad, consistencia, aislamiento y durabilidad), y habitualmente escalan bien horizontalmente. Los sistemas NoSQL se denominan a veces "no sólo SQL" para subrayar el hecho de que también pueden soportar lenguajes de consulta de tipo SQL.

Por lo general, los investigadores académicos se refieren a este tipo de bases de datos como almacenamiento estructurado, término que abarca también las bases de datos relacionales clásicas. A menudo, las bases de datos NoSQL se clasifican según su forma de almacenar los datos, y comprenden categorías como clave-valor, las implementaciones de BigTable, bases de datos documentales, y bases de datos orientadas a grafos.

Los sistemas de bases de datos NoSQL crecieron con las principales compañías de Internet, como Google, Amazon, Twitter y Facebook. Estas tenían que enfrentarse a desafíos con el tratamiento de datos que las tradicionales RDBMS no solucionaban. Con el crecimiento de la web en tiempo real existía una necesidad de proporcionar información procesada a partir de grandes volúmenes de datos que tenían unas estructuras horizontales más o menos similares. Estas compañías se dieron cuenta de que el rendimiento y sus propiedades de tiempo real eran más importantes que la coherencia, en la que las bases de datos relacionales tradicionales dedicaban una gran cantidad de tiempo de proceso

En ese sentido, a menudo, las bases de datos NoSQL están altamente optimizadas para las operaciones recuperar y agregar, y normalmente no ofrecen mucho más que la funcionalidad de almacenar los registros (p.ej. almacenamiento clave-valor). La pérdida de flexibilidad en tiempo de ejecución, comparado con los sistemas SQL clásicos, se ve compensada por ganancias significativas en escalabilidad y rendimiento cuando se trata con ciertos modelos de datos.

2. Método

El modelo relacional de bases de datos se rige por algunas normas sencillas:

Todos los datos se representan en forma de tablas (también llamadas “relaciones”, ver nota anterior). Incluso los resultados de consultar otras tablas. La tabla es además la unidad de almacenamiento principal.

Las tablas están compuestas por filas (o registros) y columnas (o campos) que almacenan cada uno de los registros (la información sobre una entidad concreta, considerados una unidad).

Las filas y las columnas, en principio, carecen de orden a la hora de ser almacenadas. Aunque en la implementación del diseño físico de cada SGBD esto no suele ser así. Por ejemplo, en SQL Server si añadimos una clave de tipo "Clustered" a una tabla haremos que los datos se ordenen físicamente por el campo correspondiente.

El orden de las columnas lo determina cada consulta (que se realizan usando SQL). Cada tabla debe poseer una clave primaria, esto es, un identificador único de cada registro compuesto por una o más columnas. Para establecer una relación entre dos tablas es necesario incluir, en forma de columna, en una de ellas la clave primaria de la otra.

A esta columna se le llama clave externa. Ambos conceptos de clave son extremadamente importantes en el diseño de bases de datos.El diseño conceptual de la base de datos para manejar toda esta información se puede ver en la siguiente figura, denominada diagrama Entidad/Relación o simplemente diagrama E-R:

La primera característica significa que los datos no tienen una definición de atributos fija, es decir: Cada registro (o documento, como se les suele llamar en estos casos) puede contener una información con diferente forma cada vez, pudiendo así almacenar sólo los atributos que interesen en cada uno de ellos, facilitando el polimorfismo de datos bajo una misma colección de información. También se pueden almacenar estructuras de datos complejas en un sólo documento, como por ejemplo almacenar la información sobre una publicación de un blog (título, cuerpo de texto, autor, etc) junto a los comentarios y etiquetas vertidos sobre el mismo, todo en un único registro. Hacerlo así aumenta laclaridad (al tener todos los datos relacionados en un mismo bloque de información) y elrendimiento (no hay que hacer un JOIN para obtener los datos relacionados, pues éstos se encuentran directamente en el mismo documento).

2

Con escalabilidad horizontal me refiero a la posibilidad de aumentar el rendimiento del sistema simplemente añadiendo más nodos, sin necesidad en muchos casos de realizar ninguna otra operación más que indicar al sistema cuáles son los nodos disponibles. Muchos sistemas NoSQL permiten utilizar consultas del tipo Map-Reduce, las cuales pueden ejecutarse en todos los nodos a la vez (cada uno operando sobre una porción de los datos) y reunir luego los resultados antes de devolverlos al cliente. La gran mayoría permiten también indicar otras cosas como el número de réplicas en que se hará una operación de escritura, para garantizar la disponibilidad. Y gracias al  sharding y a no tener que replicar todos los datos en cada uno de los nodos, la información que se mueve entre las distintas instancias del motor de base de datos no tiene por qué ser demasiado intensiva. Por supuesto, seguiremos encontrándonos con problemas de escalabilidad inherentes al tipo de software que estemos construyendo, pero seguramente podamos resolverlos más fácilmente con la ayuda de estas características.

Por último, muchos de estos sistemas realizan operaciones directamente en memoria, y sólo vuelcan los datos a disco cada cierto tiempo. Esto permite que las operaciones de escritura sean realmente rápidas. Por supuesto, trabajar de este modo puede sacrificar fácilmente la durabilidad de los datos, y en caso de cuelgue o apagón se podrían perder operaciones de escritura o perder la consistencia. Normalmente, esto lo resuelven permitiendo que una operación de escritura haya de realizarse en más de un nodo antes de darla por válida, o disminuyendo el tiempo entre volcado y volcado de datos a disco. Pero claro, aún así, existe ese riesgo.

Una tienda de artículos, todo el detalle del artículo está en una RDBMS, pero hay una serie de funcionalidades para el usuario que generan grandes volúmenes de información que pueden estar en una NoSQL, como las; lista de deseos, favoritos, comentarios, puntuaciones y el motor de búsqueda.

Un video juegos online, guarda información del estado de tu partida, se reanuda cada vez que entras en la aplicación, y cambia a medida que la uses. Éste es un buen caso para guardar los datos en una NoSQL.

Centralizas todos los logs generados por tus aplicaciones para luego buscar indicadores de seguridad, errores, y de más, también es una buena opción usar una NoSQL.

Usar una NoSQL tampoco es así de simple, tenemos varios tipos (Clave Valor, Documentales y Grafos) y cada una con un propósito diferente. Inclusive, el modelado de datos entre ambas es diferente; para una RDBMS se usa la  normalización y para una NoSQL de tipo Clave Valor se usa arreglo asociativo.

Para terminar, es importante no confundir términos usados exclusivamente en las RDBMS con las NoSQL, por ejemplo el acrónimo ACID, en las NoSQL no se aplica por qué no hay relaciones, pero si se garantiza que los datos han sido grabados correctamente.

Conclusión

Éste patrón es normal y a veces muy útil, permitiendo al lector sacar sus propias conclusiones y dejando que él mismo tome una decisión o postura al respecto,  pero al tratar con tecnologías como SQL – que son de facto en un desarrollo actual – y NoSQL – que desde su nombre es algo confuso, como explica Martin Fowler en su blog – debemos tener muchísimo cuidado a la hora de realizar comparaciones, no sólo porque sean diferentes, sino por la educación que se ha impartido a través de los años en todos los desarrolladores y estudiosos del campo de la informática.

Ahora bien, partiendo del hecho que SQL es y ha sido considerado un estándar defecto en la manera en que se deben tratar y administrar todos los datos de una aplicación, podemos comenzar a dar un bosquejo del por qué surge la pregunta que tenemos en cuestión:  El miedo a lo desconocido. Así, tal cual.

¿Por qué tememos a una tecnología como NoSQL? ¿Por qué no somos capaces de aceptar que hay otras maneras de manipular y gestionar datos? Por el simple hecho de estar rompiendo con un paradigma – sí, SQL es un paradigma apoyado en modelos relacionales – que hemos arrastrado desde los inicios de la programación.

Antes de la aparición del concepto de base de datos relacional en el año de 1970, se utilizaban técnicas de manipulación de ficheros para guardar y gestionar la información que generaba una aplicación, trayendo consigo la necesidad de comprender a cabalidad temas como el acceso a memoria, el manejo de punteros y puertos, etc. (¡Que caos!). Con la aparición de conceptos como tablas, relaciones, claves y la unificación de los términos fila y dato toda ésta engorrosa tarea se convirtió en más que un objeto de estudio y trajo alegrías y colores a muchos programadores de la época. Salir de esa zona de confort, implica – implícitamente – la necesidad de expresar esos miedos a temas tan oscuros en la programación y la preocupación de complicar más la profesión del desarrollo y la gestión de datos.

NoSQL facilita demasiado la gestión de la información en ciertos aspectos como la captura o el soporte de escalabilidad y acceso; facilita tanto la tarea, que en un futuro cercano estoy seguro que no nos preocuparemos si quiera de proporcionar una cadena de conexión como las engorrosas de sql server, sólo tendríamos que proporcionar un nombre y el mismo motor de base de datos realizará todo ese tedioso y aburrido procedimiento.

3

Por lo anterior, no podemos temerle a la maravillosa tecnología del NoSQL y su gran utilidad en el nuevo mundo de la  Internet – ni tan nuevo, de hecho -, porque se están solucionando grandes inconvenientes como la masiva concurrencia de acceso a una base de datos y el costoso mantenimiento de las mismas. Hay que aceptar de una vez por todas que NoSQL vino para quedarse y más importante,  vino para facilitarnos la vida y quitarnos más de un dolor de cabeza para empresarios y desarrolladores.

Recomendaciones

Cuando usar Sql.

Yo considero que una base de datos relacional puede ser usada estos ámbitos:

Educativo: es importante conocer cómo estructurar información, además de aportar un gran conocimiento lógico al estudiante.

Desarrollo web: es bueno tratar de mantener una misma jerarquía de los datos que llegan de la gran autopista, pero siempre y cuando la capacidad de concurrencia, almacenamiento y mantenimiento no sean de considerable dificultad y la información siempre sea consistente.

Rama de negocios: inteligencia de negocios, análisis de negocios, bodegas de datos, minería de datos, minería de texto son temas que requieren el uso de SQL para facilitar el consumo de la información y la identificación de patrones en los datos.

Empresarial: El software a la medida y el software empresarial, ambos de escritorio, poseen la característica de mantener información con una estructura consistente y SQL es ideal para ésta tarea.

Cuando usar NOsql.

Si realizamos el ejercicio en google, encontramos un poco más de información al respecto y es más sencillo orientarse en ésta nueva tecnología.

Yo considero que las tecnologías NoSQL pueden user usadas en los siguientes ámbitos:

Redes sociales: Es obligatorio. Gracias a las redes sociales, ésta tecnología comenzó a despegar y mostrar utilidad en el campo de la informática y la estadística.

Desarrollo Web: Considero más pertinente el uso de éstas tecnologías en ésta área, debido a la poca uniformidad de la información que encontramos en Internet, sin embargo, es posible realizar éstos desarrollos con SQL, como expuse anteriormente.

Desarrollo Móvil: En éstos momentos, las empresas están lidiando con un problema grande conocido como Bring Your Own Device – en realidad no es un problema, es un fenómeno social -, por lo que la información que se recolecte siempre será diferente por más que uno desee estructurarla y mantenerla estática.

BigData: Como podemos observar en Search Business Analytics, la administración de grandísimas cantidades de información y su evidente heterogeneida hace de NoSQL un excelente candidato en ésta área.

Cloud (XaaS): el término XaaS (Everything as a service) que indica “Cualquier cosa como servicio (sic)” y todos los temas relacionados a la nube, con NoSQL pueden adaptarse casi a cualquier necesidad del cliente, que evidentemente son heterogéneos.

 

Referencias

4