lunes, 27 de mayo de 2013

BASES DE DATOS NOSQL: LLEGARON PARA QUEDARSE

William Díaz Sepúlveda.
contadores de visitas gratis


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

1Introducció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



tomado de http://blog.nahurst.com/visual-guide-to-nosql-systems (Nathan Hurst)

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