Sie sind auf Seite 1von 5

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 volmenes de datos
no son un simple milln de rows, son mucho ms, billones por ejemplo, ahora imagina billones de rows que interactan con otros billones de
rows para generar informacin ms significativa, cuando hay grandes volmenes de informacin 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 an ambas son necesarias hoy en da. Todo el problema
parte por los grandes volmenes de datos, Cmo los procesamos?, Como puedo mantener mi infraestructura tecnolgica?, Cmo hago para
que millones de usuarios puedan usar mi aplicacin de forma muy rpida? y quien sabe cuantas preguntas ms
En la dcada 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 informacin (normalizar) en grupos de datos bajo una semejanza, y as poder mantener una coherencia entre ellos (integridad), fue
creciendo el volumen de informacin pero pocos tenan acceso a manipularla, mientras Internet fue expandindose y cada vez ms personas
acceden a los datos, nos dimos cuenta que los RDBMS son muy lentos, y como fueron diseados traeran problemas, se inventaron muchas
soluciones, pero como todo, se llega a un lmite. 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 bsico, 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. Introduccin
La base de datos relacional (BDR) es un tipo de base de datos (BD) que cumple con el modelo relacional (el modelo ms utilizado actualmente
para implementar las BD ya planificadas).
Permite establecer interconexiones o relaciones entre los datos (que estn guardados en tablas), y a travs 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 informtica, NoSQL (a veces llamado "no slo SQL") es una amplia clase de sistemas de gestin de bases de datos que difieren del modelo
clsico del sistema de gestin de bases de datos relacionales (RDBMS) en aspectos importantes, el ms 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 slo SQL" para subrayar el hecho de que tambin pueden soportar lenguajes de consulta de tipo
SQL.
Por lo general, los investigadores acadmicos se refieren a este tipo de bases de datos como almacenamiento estructurado, trmino que abarca
tambin las bases de datos relacionales clsicas. A menudo, las bases de datos NoSQL se clasifican segn su forma de almacenar los datos, y
comprenden categoras 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 compaas de Internet, como Google, Amazon, Twitter y Facebook. Estas
tenan que enfrentarse a desafos con el tratamiento de datos que las tradicionales RDBMS no solucionaban. Con el crecimiento de la web en
tiempo real exista una necesidad de proporcionar informacin procesada a partir de grandes volmenes de datos que tenan unas estructuras
horizontales ms o menos similares. Estas compaas se dieron cuenta de que el rendimiento y sus propiedades de tiempo real eran ms
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 estn altamente optimizadas para las operaciones recuperar y agregar, y normalmente no
ofrecen mucho ms que la funcionalidad de almacenar los registros (p.ej. almacenamiento clave-valor). La prdida de flexibilidad en tiempo de
ejecucin, comparado con los sistemas SQL clsicos, se ve compensada por ganancias significativas en escalabilidad y rendimiento cuando se
trata con ciertos modelos de datos.

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

Todos los datos se representan en forma de tablas (tambin llamadas relaciones, ver nota anterior). Incluso los resultados de
consultar otras tablas. La tabla es adems la unidad de almacenamiento principal.

Las tablas estn compuestas por filas (o registros) y columnas (o campos) que almacenan cada uno de los registros (la
informacin 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 implementacin del diseo
fsico de cada SGBD esto no suele ser as. Por ejemplo, en SQL Server si aadimos una clave de tipo "Clustered" a una tabla haremos
que los datos se ordenen fsicamente 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 ms columnas.

Para establecer una relacin 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 diseo de bases de
datos.
El diseo conceptual de la base de datos para manejar toda esta informacin se puede ver en la siguiente figura, denominada diagrama
Entidad/Relacin o simplemente diagrama E-R:

La primera caracterstica significa que los datos no tienen una definicin de atributos fija, es decir: Cada registro (o documento, como se les
suele llamar en estos casos) puede contener una informacin con diferente forma cada vez, pudiendo as almacenar slo los atributos que
interesen en cada uno de ellos, facilitando el polimorfismo de datos bajo una misma coleccin de informacin. Tambin se pueden almacenar
estructuras de datos complejas en un slo documento, como por ejemplo almacenar la informacin sobre una publicacin de un blog (ttulo,
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 informacin) y elrendimiento (no hay que hacer un JOIN para obtener
los datos relacionados, pues stos se encuentran directamente en el mismo documento).
Con escalabilidad horizontal me refiero a la posibilidad de aumentar el rendimiento del sistema simplemente aadiendo ms nodos, sin
necesidad en muchos casos de realizar ninguna otra operacin ms que indicar al sistema cules 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 porcin de los datos) y reunir luego los resultados antes de devolverlos al cliente. La gran mayora permiten tambin indicar otras cosas
como el nmero de rplicas en que se har una operacin 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 informacin que se mueve entre las distintas instancias del motor de base de datos no tiene
por qu ser demasiado intensiva. Por supuesto, seguiremos encontrndonos con problemas de escalabilidad inherentes al tipo de software que
estemos construyendo, pero seguramente podamos resolverlos ms fcilmente con la ayuda de estas caractersticas.
Por ltimo, muchos de estos sistemas realizan operaciones directamente en memoria, y slo vuelcan los datos a disco cada cierto tiempo. Esto
permite que las operaciones de escritura sean realmente rpidas. Por supuesto, trabajar de este modo puede sacrificar fcilmente la durabilidad
de los datos, y en caso de cuelgue o apagn se podran perder operaciones de escritura o perder la consistencia. Normalmente, esto lo resuelven
permitiendo que una operacin de escritura haya de realizarse en ms de un nodo antes de darla por vlida, o disminuyendo el tiempo entre
volcado y volcado de datos a disco. Pero claro, an as, existe ese riesgo.
Una tienda de artculos, todo el detalle del artculo est en una RDBMS, pero hay una serie de funcionalidades para el usuario que generan
grandes volmenes de informacin que pueden estar en una NoSQL, como las; lista de deseos, favoritos, comentarios, puntuaciones y el motor
de bsqueda.
Un video juegos online, guarda informacin del estado de tu partida, se reanuda cada vez que entras en la aplicacin, 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 ms, tambin es una buena
opcin usar una NoSQL.
Usar una NoSQL tampoco es as de simple, tenemos varios tipos (Clave Valor, Documentales y Grafos) y cada una con un propsito diferente.
Inclusive, el modelado de datos entre ambas es diferente; para una RDBMS se usa la normalizacin y para una NoSQL de tipo Clave Valor se
usa arreglo asociativo.
Para terminar, es importante no confundir trminos usados exclusivamente en las RDBMS con las NoSQL, por ejemplo el acrnimo ACID, en
las NoSQL no se aplica por qu no hay relaciones, pero si se garantiza que los datos han sido grabados correctamente.

Conclusin
ste patrn es normal y a veces muy til, permitiendo al lector sacar sus propias conclusiones y dejando que l mismo tome una decisin o
postura al respecto, pero al tratar con tecnologas 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 muchsimo cuidado a la hora de realizar comparaciones, no slo porque
sean diferentes, sino por la educacin que se ha impartido a travs de los aos en todos los desarrolladores y estudiosos del campo de la
informtica.
Ahora bien, partiendo del hecho que SQL es y ha sido considerado un estndar de fecto en la manera en que se deben tratar y administrar todos
los datos de una aplicacin, podemos comenzar a dar un bosquejo del por qu surge la pregunta que tenemos en cuestin: El miedo a lo
desconocido. As, tal cual.
Por qu tememos a una tecnologa 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 programacin.

Antes de la aparicin del concepto de base de datos relacional en el ao de 1970, se utilizaban tcnicas de manipulacin de ficheros para
guardar y gestionar la informacin que generaba una aplicacin, 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 aparicin de conceptos como tablas, relaciones, claves y la
unificacin de los trminos fila y dato toda sta engorrosa tarea se convirti en ms que un objeto de estudio y trajo alegras y colores a muchos
programadores de la poca. Salir de esa zona de confort, implica implcitamente la necesidad de expresar esos miedos a temas tan oscuros
en la programacin y la preocupacin de complicar ms la profesin del desarrollo y la gestin de datos.
NoSQL facilita demasiado la gestin de la informacin 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 conexin como las
engorrosas de sql server, slo tendramos que proporcionar un nombre y el mismo motor de base de datos realizar todo ese tedioso y aburrido
procedimiento.
Por lo anterior, no podemos temerle a la maravillosa tecnologa del NoSQL y su gran utilidad en el nuevo mundo de la Internet ni tan nuevo,
de hecho -, porque se estn 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 ms importante, vino para facilitarnos
la vida y quitarnos ms 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 cmo estructurar informacin, adems de aportar un gran conocimiento lgico al estudiante.
Desarrollo web: es bueno tratar de mantener una misma jerarqua 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 informacin siempre sea consistente.
Rama de negocios: inteligencia de negocios, anlisis de negocios, bodegas de datos, minera de datos, minera de texto son temas que
requieren el uso de SQL para facilitar el consumo de la informacin y la identificacin de patrones en los datos.
Empresarial: El software a la medida y el software empresarial, ambos de escritorio, poseen la caracterstica de mantener informacin con una
estructura consistente y SQL es ideal para sta tarea.

Cuando usar NOsql.


Si realizamos el ejercicio en google, encontramos un poco ms de informacin al respecto y es ms sencillo orientarse en sta nueva tecnologa.
Yo considero que las tecnologas NoSQL pueden user usadas en los siguientes mbitos:
Redes sociales: Es obligatorio. Gracias a las redes sociales, sta tecnologa comenz a despegar y mostrar utilidad en el campo de la
informtica y la estadstica.
Desarrollo Web: Considero ms pertinente el uso de stas tecnologas en sta rea, debido a la poca uniformidad de la informacin que
encontramos en Internet, sin embargo, es posible realizar stos desarrollos con SQL, como expuse anteriormente.
Desarrollo Mvil: En stos momentos, las empresas estn lidiando con un problema grande conocido como Bring Your Own Device en
realidad no es un problema, es un fenmeno social -, por lo que la informacin que se recolecte siempre ser diferente por ms que uno desee
estructurarla y mantenerla esttica.
BigData: Como podemos observar en Search Business Analytics, la administracin de grandsimas cantidades de informacin y su evidente
heterogeneida hace de NoSQL un excelente candidato en sta rea.
Cloud (XaaS): el trmino 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 heterogneos.

Referencias
4

Das könnte Ihnen auch gefallen