BASES DE DATOS
NOSQL: LLEGARON PARA QUEDARSE
|
William Díaz Sepúlveda.
Resumen: Las bases de
datos NOSQL aparecieron como una necesidad para el manejo de información voluminosa y distribuida en los grandes sitios web pero serán soluciones para
las grandes empresas y las medianas empresas? solucionan los problemas que las bases
de datos Relacionales solucionan?. Que tipo de problemas solucionan? Este
artículo presenta este modelo y sus actuales logros y resultados.
Palabras Claves: NOSQL,
bases de datos, relacional, Not Only SQL, CAP, ACID, BASE
1. Introducción
Las bases de
datos (BD) tradicionales son las
relacionales que usan un lenguaje Estándar para su manipulación y gestión , el
SQL que nace en 1974
basado en Modelo de EF COD. SQL tiene más de 37 años de vida. Son ejemplos de
bases de datos relacionales: ORACLE, MYSQL, SQL Server, POTGRESS, DB2, etc..Su
éxito se basó en que son una solución para los problemas de gestión y
estructuración de la información de las organizaciones, con un fundamento
matemático muy fuerte, lenguaje estandarizado (aceptado y adoptado) para su gestión (SQL) , con metodologías
estructuradas formales para el diseño de los sistemas de información de las
organizaciones y con principios de diseño
como la regla ACID (atómica consistente aislada y Durable) . estas
plataformas tienen muchas herramientas desarrolladas.
Las bases de datos NOSQL son un conjunto de bases de datos que no se ajustan al modelo de bases de datos relacionales y sus características, estas no tienen esquemas , no usan SQL ni permiten joins, no garantizan la propiedad ACID, escalan horizontalmente, hacen uso amplio de la memoria principal del computador, resuelven el problema de los altos volúmenes de información y la inmensa cantidad de consultas y transacciones diarias, en resumen no son relacionales.
Pero en qué consisten? Porque surgieron? cual es la mejor solución para un problema x determinado ¿ para qué tipo de problemas se debe considerar las alternativas NOSQL? Se debería usar una Solución NOSQL para un problema que tradicionalmente se ha resuelto con bases de datos relacionales? Que se debe tener en cuenta? Reemplazarán las bases de datos relacionales ?
Este trabajo
pretende dar algunas respuestas a estas inquietudes que genera la tecnología de
bases de datos NOSQL que vienen en vertiginoso desarrollo , especialmente desde
el 2009.
1.1 Origen.
El termino NOSQL cobija varios
productos, varios conceptos relacionados sobre almacenamiento, gestión de datos y datos voluminosos. Es lo
que denominan un término “umbrella” (“sombrilla”) porque cobija varias
elementos.
El término fue acuñado por
Calor Strozzi en 1998 y resucitado por Eric Evans (un empleado de Rackspace,) en
2009 y el mismo sugirió se llamasen estas bases de datos como Big Data
Las bases de
datos NOSQL no nacieron en 2009 sino que se remontan a la época de las bases de datos de red y
jerárquicas y una serie de productos que
no eran relacionales que resuelven
problemas que no tienen las características similares a los de : amazon.com,
Facebook, Youtube , twitter, Netflix,
Yahoo, EBay, Hulu,IBM, y que en la época
en que surgieron no se tenia internet. Desde 1965 (Knut 2010) se han
venido desarrollando productos para almacenamiento
masivo, datos multivalor, de red (grafos) , jerárquicos (arboles), con
estructuras B+, productos de procesamiento de transacciones de alto desempeño
llave valor (GTM en 2000 de código abierto)
Por ejemplo Neo4j empezó en el año 2000, pero si algo contribuyo al
desarrollo de los productos NOSQL fueron la serie de “papers” publicados por
Google en 2003, 2004 y 2006 sobre cómo construir una infraestructura escalable
para el procesamiento paralelo de grandes (enormes) cantidades de datos, que
origino Hadoop (y luego Hadoop MapReduce de Yahoo) , más tarde en 2007 Amazon
liberó su historia sobre Dynamo el almacenamiento llave/Valor de alta disponibilidad. (Shashank 2011)
“La innovación clave de
MapReduce es la capacidad de hacer una consulta, dividiéndola y ejecutándola en
paralelo a la vez, a través de muchos servidores sobre un conjunto de datos
inmenso.”
En el 2012 la
cantidad de productos NOSQL paso a ser un poco mas de 120 (Sergey, 2012)
Las siguientes
fechas corresponden a bases
de datos NOSQL recientemente
desarrolladas como soluciones a problemas de empresas web de alto volumen de
operaciones (transacciones diarias) , alto volumen de información (las fechas corresponden a fechas de inicio,
o en algunos casos de liberación del producto):
JackRabbit
|
2006
|
Tokyo Cabinet
|
2006
|
Amazon Dynamo
|
2007
|
MongoDB
|
2007
|
Cassandra
|
2008
|
Proyecto t Voldemort
|
2008
|
Terrastore
|
2009
|
Redis
|
2009
|
Riak
|
2009
|
HBase
|
2009
|
Vertexdb
|
2009
|
El porque
surgen las BD NOSQL se trata enseguida
1.2 El problema
Unos datos
interesantes relacionados son (Torres
2012) :
Desde 2010
se están vendiendo más dispositivos móviles que PCs.
Son más de
900 millones los usuarios de Facebook.
Cada minuto
se generan 50 horas de contenido en YouTube
Twitter genera
casi 8 terabytes de datos con sus más de 90 millones de tuits al día.
Wall-Mart gestiona
un millón de transacciones de sus clientes/ hora (2.5 petabytes)
Se estima que en 2015 circularan por el
planeta 7.900 exabytes
el cluster de producción más grande basado
en Cassandra gestiona más de 300
terabytes
de datos a
través de 400 máquinas
Se han creado más datos en los últimos dos años que todos los
años anteriores, se han creado datos del orden de ExaBytes (10 a la 18 ) por
año. Los datos son más entrelazados y conectados , son datos menos estructurados
y datos a escala de la web, con mucha
lectura escritura, los esquemas (“schemas”)
cambian frecuentemente, por ejemplo las aplicaciones sociales no necesitan el
mismo nivel de ACID y la orientación del software es hacia servicios(PasS:
programas como Servicios)
El problema aparece con los
sistemas de millones de transacciones al día contra la base de datos, otra elemento más es que
se necesita cada vez mayor flexibilidad para escalar (escalabilidad) y porque
para solucionarlo se estaban adquiriendo mayores y más potentes
computadores
Por tanto las bases de datos
NOSQL intentan
resolver problemas de
almacenamiento masivo, alto desempeño, procesamiento masivo de transacciones
(sitios con alto transito) y en términos
generales ser alternativas NOSQL a problemas de persistencia y almacenamiento
masivo (voluminoso) de información para las organizaciones.
Pero la gran
diferencia es como almacenan los datos. Por
ejemplo una factura en el modelo relacional termina guardándose en 4 tablas (con
3 o 4 llaves foráneas – asociaciones
involucradas) y en NOSQL
simplemente guardan la factura y no se
diseña las tablas ni su estructura por adelantado, se almacena, por ejemplo una clave
(numero de la factura) y el Objeto (la
factura)
Unido a lo
anterior podemos afirmar que en las bases de datos relacionales: la lectura de
datos es muy costosa, existe mucha transaccionalidad innecesaria, se asumen que
los datos son densos y bien estructurados, tienen problema de escalabilidad
horizontal y no todos los problemas se pueden modelar para una base un RDBMS
1.3 Usuarios
La tabla siguiente muestra
algunos ejemplo de empresas que están
usando BD NOSQL:
Cassandra
|
Digg, Twitter, Rackspace,
IBM, Reddit., Accenture, Adobe,
Ericsson Cisco, HP, Netflix, openwave, Facebook, WebEx, Pitney bowes. , Real,
Symantec,
|
HBase
|
Adobe, Powerset,
Stumbleupon, Yahoo, Twitter, Facebook
|
MongoDB
|
SourceForge,
Justin.tv, foursquare, Bit.ly.
www.gov.uk beta
.SAP, MTV, Athena Capital Research, Disney, IGN, The National Archives,
Guardian., NYTimes, Forbes, Foursquare, LexisNexis, CERN, Springer, and
Doodle
|
Redis
|
Github, The Guardian,
Craigslist
|
Hadoop
|
Amazon/A9 ,
Adobe, AOL, , Ebay , Facebook, Hulu media service, IBM Blue , Last.fm,
LinkedIn, New York Times, Microsoft Powerset, Rackspace, Twitter, Yahoo
|
1.3.3 Clasificación
Según el teorema de CAP o
teorema de Brewer (año 2000) , las bases
de datos solo pueden garantizar dos de tres características:
Consistencia
Disponibilidad
(“Availability”)
Tolerancia a particiones.
Las BD relacionales satisfacen
las características CA : es decir Consistencia y disponibilidad pero tiene serios problemas con la Tolerancia a
particiones (muchos nodos), para la nube se requiere escalabilidad y se necesita sacrificar consistencia.
Las BD NOSQL manejan un
concepto similar al ACID y se denomina para ellas BASE (Basically Available, Soft-State
y Eventual Consistency)
donde es de prioridad la disponibilidad sobre la consistencia, es decir
que el sistema no estará probablemente en cada instante del tiempo en estado
consistente.
Las bases de datos se han
venido clasificando principalmente en cuatro (4) grupos :
De clave Valor Documentos
Familia de columnas Grafos
Veamos cada uno de estos
grupos
De clave Valor.
Este grupo de bases de datos
NOSQL cuyo precursor fue Big Table de Google tiene un Modelo con pares clave-Valor
Especialmente útiles para
problemas de escrituras masivas de “Streaming”
Transaciones tipo
son : put (key, value), get(key), remove(key)
Ejemplos : Dynamo Amazon,
Cassaandra, Voldemort, Redis.
Cassandra fue inciado por
Facebook y hoy es un proyecto Apache de código Abierto (escrito en java) .
De Familias de Columnas.
Para definirlos mejor : Son
almacenamientos de datos orientados a Columnas
Ejemplos : Casandra, Hbase..)
De documentos
Las bases de datos de este
grupo permiten la gestión de información semi-estructurada orientadas a
documentos, son similares a registros, direccionados por una clave unica,
y se pueden recuperar con su contenido.
Tienen un modelado muy natural
orientado a la web.
Ejemplos : Couchdb , Mongodb,
riak
De Grafos
Los nodos son entidades y los
arcos con relaciones y contienen información con uso a menudo
de tablas hash distribuidas y ofrecen estructuras de datos sencillas
como arrays asociativos o almacenes de pares claves valor.
Ejemplos : Neo4j, Flockdb
(twiter)
Tienen una arquitectura
distribuida con datos almacenados redundantemente en distintos servidores
1.4 Cuales son las mas sobresalientes.
Los lideres
del mercado son : Hadoop y MongoDB. Le siguen Cassandra, Redis , CouchDB
y Riak
Un
estudio (Edlich ,2012) revela que hay
dos productos NOSQL que se suponen deben dominar los Ingenieros de Sistemas
(arquitectos de software, desarrolladores) entre los diez conocimientos de
tecnología requeridos : MongoDB y Hadoop.
Académicamente los ingenieros , los arquitectos de
software, los diseñadores de aplicaciones y los programadores requieren un
conocimiento más profundo de las estructuras de datos que antes con las bases
de datos relacionales no se requería.
La sensación que nos estamos devolviendo en el desarrollo y la evolución de las bases de
datos hacia los modelos jerárquico y de grafos no debería ser una limitante
para usar estas soluciones que están probando y muy bien ser soluciones para
problemas distribuidos, de alto volumen de información, de alto tráfico y de prioridades de servicios y
consultas diferentes a los problemas de procesamiento transaccional de las bases de datos relacionales.
El mercado muestra que las grandes firmas están
lanzando e integrando soluciones NOSQL en sus productos (Oracle, IBM) y
productos como Neo4j , que
poco a poco NOSQL se esta constituyendo en un PasS (program as Service )
estándar (Redis y MongoDB) (Edlich
,2012) y productos como Neo4j, MongoDb y
CouchDb han sido objeto de apoyo e inversión de capital de riesgo (“venture
capital ”).
Otro indicador muy importante es la cantidad de Artículos
que se ha publicado, los blogs y los sitios web con tutoriales y material sobre
los productos NOSQL. Sin mencionar nuevos y recientes productos.
1.5 como diseñar para estas bases de datos NOSQL?.
Es
muy conocido en el mundo de las bases de datos relacionales y el desarrollo de
software que el análisis de requerimientos define la bases de datos y la funcionalidad de la aplicación
pero Consistencia, Disponibilidad y Tolerancia a las particiones (CAP) son requerimientos
no funcionales, lo que ilustra la importancia que adquieren para los problemas el
incluir este análisis en su proceso de solución del problema.
El
otro Aspecto fundamental de análisis y de diseño es que la naturaleza de su
problema debe ser distribuido y de alto volumen de datos para aplicar bien
soluciones (TIENLE, 2013)
CAP es una regla de diseño
Debemos
tener en cuenta que el campo de las bases de datos NOSQL tendrá más desarrollo
y mucho mas se investigará y se escribirá sobre ellas y sobre como Diseñar
soluciones con arquitecturas NOSQL pero por la naturaleza de los problemas que
ya están solucionado podemos afirmar que para empezar un diseño debemos responder
a la pregunta :
“para
que se requiere la base de datos?”
“Qué
tipo de consultas y servicios debe proveer?”
El
modelo relacional se basa mayormente en los datos , sus operaciones, su gestión
y su manipulación.
Las
bases de datos relacionales normalizaban sus datos (en forma extrema) para evitar la duplicación y la redundancia ,
cuando se requería optimizar y mejorar rendimientos , se buscaba por ejemplo, ubicando
físicamente la
información en los discos tratando de
garantizar la lectura de información relacionada y posiblemente objeto de
búsquedas en bloques de lectura, en bases de datos NOSQL la optimización y el
rendimiento son principios de diseño y la redundancia (duplicación) es una
prioridad mucho menor, se puede ubicar todo un elemento con toda su información
en varios lugares .
Estas
tecnologías aprovechan el desarrollo actual del disco (memoria secundaria) y la
memoria principal (RAM)
El teorema CAP debe ser un principio de diseño el
teorema CAP y esto por ejemplo significa
que escoger CP como las dos principales características de su problema y
producto implica, por ejemplo, una base
de datos como HBASE o por el contrario
si es AP podría ser Cassandra, pero no
es tan estricto este criterio de diseño y por ejemplo Casandra permite ciertos
grados de consistencia, disponibilidad y particionamiento que vale la pena
tener en cuenta , es decir se debe tener muy presente la naturaleza y las
prioridades del problema a resolver y conocer muy detalladamente lo que ofrece
cada producto NOSQL para elegir la mejor solución Siempre teniendo en cuenta
dar la mejor solución en términos de calidad, desempeño y costos a cada problema.
2. Conclusiones
No hay una base de datos NOSQL o relacional ideal,
cada base de datos tiene sus ventajas y desventajas para algún caso o problema particular
( Bushik, 2012) y (López 2013)
No es fácil entender y
establecer cual es la mejor herramienta (producto NOSQL) para un determinado
problema.
Las bases de datos NOSQL (MONGODB) hace muy poco uso
de Procesador y Acceso A disco pero si mucho uso de memoria
Teniendo
en cuenta lo nuevo de estos productos y la madurez (edad) alcanzada por bases
de datos relacionales como Oracle (1977), inclusive MYSQL (1994) se puede
afirmar que es muy importante esperar desarrollo de técnicas o guías que
permitan:
Establecer la naturaleza relacional
de un problema
Establecer las características
y el tipo de problemas que son candidatos para solución con bases de datos NOSQL
Definir en qué casos se puede
sacrificar la características del teorema de CAP para clasificar el problema como un candidato para CA (relacionales donde la tolerancia a particiones no es un requisito
indispensable) o AP (donde la
consistencia no es importante) o CP (la disponibilidad no es un requisito
indispensable)
Igualmente importante es que
se pueda establecer si la solución debe emplear una arquitectura mixta con
bases de datos NOSQL y relacionales.
Podría
ser más aconsejable usar una Configuración para una arquitectura Mixta donde
para se puede utilizar las bases de datos
relacionales y para otras operaciones usar una plataforma NOSQL pero depende de la prioridad de solución de su problema
La
principal ventajas de las BD NOSQL es la
distribución de los datos y la buena escalabilidad
de las bases de datos
Pero aún
más importante los profesionales de ahora y del futuro deben conocer de
computación en la Nube , bases de datos NOSQL y de las posibilidades de
productos, servicios, modelos, soluciones , arquitecturas
Autores
William Díaz Sepúlveda.
Ingeniero de Sistemas UNIANDES. Profesor de la UNIAJC Cali. Valle del Cauca.
X. REFERENCIAS
Bushik Sergey (2012) A vendor-independent comparison of NOSQL databases:
Cassandra, HBase, MongoDB, Riak Altoros
Systems Inc., special to Network World, Octubre 22 de 2012 http://www.networkworld.com/news/tech/2012/102212-nosql-263595.html consultado en Mayo 2 de 2013.
Lopez Jose Luis (2013) Bases de datos NOSQL y su desempeño
frente al modelo relacional, Proyecto de Grado para optar al título de Ingeniería
de Sistemas , UNIAJC, Abril 2013.
TIENLE (2013) NoSQL
Data Modeling Techniques, TIENLE'S BLOG, Web Development Sharing, 2013/02/26,
Knut Haugen (2010) blog
Williams Alex (2012) Top 10 Developer and Engineering Skills
Employers Will Look for Going into 2012 – diciembre de 2012
Edlich Stefan (2012)
blog
http://www.infoq.com/articles/State-of-NoSQL
Noviembre de 2012. Consultado en 2013/05/11
Shashank Tiwari (2011) Professional NoSQL,
John Wiley & Sons, Inc.
Torres i Viñals Jordi (2012) del
cloud computing al big. Data. Visión
introductoria para jóvenes emprendedores Universidad Oberta de catalaluña
Cogswell Jeff (2012) SQL vs. NoSQL: Which Is Better?
favor
colocar sus comentarios acá o enviarlos
a williamdiazs@gmail.com
