NoSQL

Introducción

Como humanos que somos, tenemos la increíble habilidad de tomar decisiones basándonos en grandes cantidades de datos sin estructurar que, de manera natural, obtenemos, filtramos y procesamos. Podemos decir que, casi todas las decisiones que tomamos, están influenciadas por una gama variada de imágenes, sonidos, palabras, aromas, sabores y texturas.

Pero examinemos por un instante cómo están organizadas las empresas. En contraste con el cerebro humano, las compañías toman sus decisiones basándose en grandes cantidades de datos estructurados.

Hoy en día se estima que más del 80% de los datos de una empresa son datos no estructurados y tienen un formato de texto, voz o vídeo. Lamentablemente, la mayoría de las empresas no tienen las herramientas necesarias para apreciar la riqueza inmensa de esa información, incluso a la hora de llegar a tomar decisiones vitales para la propia compañía.

En el mundo de los negocios, esta información es crítica para mejorar la experiencia del cliente, identificar tendencias emergentes, crear nuevos productos y servicios, y mucho más.

¿Qué es NoSQL?

El termino NoSQL, dentro del ámbito de una base de datos, no se refiere precisamente a la carencia de lenguaje SQL como el propio nombre sugiere, sino a la ausencia de estructuras de datos relaciones como las que forman parte de un sistemas de gestión de bases de datos relacional o RDBMS.

El modelo NoSQL sustituye las estructuras basadas en relaciones de los esquemas convencionales que forman un RDBMS incorporando una serie de prestaciones, algunas de ellas más robustas que otras, adaptadas a las necesidades concretas de las aplicaciones que las utilizan. En otras palabras podemos decir que hemos pasado de un modelo de talla única a otro hecho a medida. No existe una definición de base de datos NoSQL estándar, sino que cada una de ellas es diferente a la otra y diseñada para un propósito en concreto aunque funcionen bajo el mismo sistema de estructuración de datos.

Clasifiquemos para no estructurar…

En general hay 4 tipos de bases de datos NoSQL, dependiendo de como almacenan la información:

• Key-Value: clave-valor es la forma mas típica, como un HashMap donde cada elemento esta identificado por una llave única, lo que permite la recuperación de la información de manera muy rápida. Normalmente el valor se almacenar como un objeto BLOB. De esta forma el tipo de contenido no es importante para la base de datos, solo la clave y el valor que tiene asociado. Son muy eficientes para lecturas y escrituras, además de que pueden escalar fácilmente particionando los valores de acuerdo a su clave; por ejemplo aquellos cuya clave está entre 1 y 1000 van a un server, los de 1001 a 2000 a otro, etc. Muchas de ellas están basadas en la publicación de Google acerca de su BigTable y de Amazon. Dentro de estas bases de datos podemos encontrar a BigTable de Google, SimpleDB de Amazon, Cassandra, Hadoop, Riak, Voldemort y MemcacheDB entre otras.
• Basada en Documentos: estas almacenan la información como un documento (generalmente con una estructura simple como JSON o XML) y con una clave única. Es similar a las bases de datos Key-value, pero con la diferencia que el valor es un fichero que puede ser entendido. Si el servidor entiende los datos, puede hacer operaciones con ellos. De hecho varias de las implementaciones de este tipo de bases de datos permiten consultas muy avanzadas sobre los datos, e incluso establecer relaciones entre ellos, aunque siguen sin permitir joins. Podemos encontrar a MongoDB y CouchDB entre las mas importantes de
  este tipo.
• Orientadas a Grafos: Hay otras bases de datos que almacenan la información como grafos donde las relaciones entre los nodos son lo mas importante. Son muy útiles para representar información de redes sociales. De hecho, las relaciones también pueden tener atributos y puedes hacer consultas directas a relaciones, en vez de a los nodos. Además, al estar almacenadas de esta forma, es mucho más eficiente navegar entre relaciones que en un modelo relacional. Obviamente, este tipo de bases de datos sólo son aprovechables si la información en cuestión se puede representar fácilmente como una red. Encontramos a neo4j entre otras.
• Orientadas a Columnas: guardan los valores en columnas en lugar de filas. Con este cambio ganamos mucha velocidad en lecturas, ya que si se requiere consultar un número reducido de columnas, es muy rápido hacerlo pero no es eficiente para realizar escrituras. Por ello este tipo de soluciones es usado en aplicaciones con un índice bajo de escrituras pero muchas lecturas. Por ejemplo, Cassandra.

Las ventajas de estas…

• Consistencia Eventual: No se implementan mecanismos rígidos de consistencia como los presentes en las bases de datos relacionales, donde la confirmación de un cambio implica una comunicación del mismo a todos los nodos que lo repliquen. Esta flexibilidad hace que la consistencia se dé, eventualmente, cuando no se hayan modificado los datos durante un periodo de tiempo. Esto se conoce también como BASE (Basically Available Soft-state Eventual Consistency, o coherencia eventual flexible básicamente disponible).
• Estructura distribuida: Generalmente se distribuyen los datos mediante mecanismos de tablas de hash distribuidas.
• Escalabilidad horizontal: Consiste en 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.
• Tolerancia a fallos y Redundancia.
• No generan cuellos de botella: el problema de fondo de los sistemas SQL, es que deben de transcribir cada sentencia para poder ser ejecutada y, cada sentencia compleja requiere, además de un nivel de ejecución más concreto para poderse llevar a cabo, por lo que constituye un punto de entrada común, único y conflictivo en base a rendimiento.
• Solo lo estrictamente necesario: son sistemas simples que no tienen un sistema de consulta complejo ni con capacidad declarativa para en una sola línea realizar una cantidad interna de operaciones desorbitada.
• Estructura dinámica: La primera característica significa que los datos no tienen una definición de atributos fija, es decir: Cada registro 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 la claridad (al tener todos los datos relacionados en un mismo bloque de información) y el rendimiento (no hay que hacer un JOIN para obtener los datos relacionados, pues éstos se encuentran directamente en el mismo documento).

Una de cal y otra de arena…

• El código abierto puede significar una «mancha» en el soporte para las empresas. Mientras que los principales proveedores de RMBMS tales como Oracle, IBM y Sybase ofrecen buenos soportes a pequeñas, medianas y grandes empresas y típicamente start-ups, los vendedores de código abierto esperan ofrecer un soporte comparable -con excepción de un puñado de clientes blue-chip.Generalmente un vendedor de código abierto no tiene el alcance global, servicios de soporte, y la credibilidad de Oracle o IBM.
• No están lo suficientemente maduros para algunas empresas. A pesar de sus puestas en práctica en algunas grandes empresas, las bases de datos NoSQL aún se enfrentan a un problema de credibilidad importante con muchas empresas. Los críticos señalan la falta de madurez de NoSQL y los posibles problemas de inestabilidad, mientras que citan la madurez, y una gran funcionalidad y estabilidad de los RDBMSes.
• Limitaciones de Inteligencia de Negocios. Hay una o dos cuestiones acerca de las capacidades de BI de las bases de datos NoSQL.¿Pueden estas bases de datos proporcionar la clase de minería de datos rigurosos que las empresas se utilizan con las RDBMSes? ¿Cuántos conocimientos de programación se necesitan para hacer la consulta ad hoc y análisis?Las respuestas no son precisamente positivas. Las bases de datos NoSQL no tienen muchos ganchos para el uso general de herramientas de BI, mientras que la más simple consulta ad-hoc y análisis implica conocimientos de programación bastante buenos. Sin embargo, las soluciones están disponibles. Quest Software, por ejemplo, ha creado Toad para bases de datos en la nube, que proporciona capacidades de consulta ad-hoc para algunas bases de datos NoSQL. Evidentemente la solución esta del lado de los sistemas híbridos.
• La falta de experiencia.
  La novedad de NoSQL significa que no hay una gran cantidad de desarrolladores y administradores que conocen la tecnología lo que hace difícil a las empresas encontrar personas con los conocimientos técnicos apropiados. Por el contrario, el mundo RDBMS tiene miles de personas muy cualificadas.
• Problemas de compatibilidad.
  A diferencia de las bases de datos relacionales, que comparten ciertos estándares, las bases de datos NoSQL tienen pocas normas en común.
  Cada base de datos NoSQL tiene su propia API, las interfaces de consultas son únicas y tienen peculiaridades. Esta falta de normas significa que es imposible cambiar simplemente de un proveedor a otro, por si no quedara satisfecho con el servicio.

Entonces…

Las bases de datos NoSQL son ya una opción más en la cartera de alternativas para almacenar los datos de tus aplicaciones. Existen varios tipos de ellas, pero en general su objetivo principal es resolver los problemas de performance y de escalabilidad de las RDBMS. Por otro lado, las RDBMS no desaparecerán ni mucho menos. Sus capacidades transaccionales las hacen perfectas para la mayoría de las aplicaciones existentes. Sin embargo, seguramente sufrirán cambios. Así como en el pasado las bases orientadas a objetos influenciaron la evolución de las RDBMS, veremos en el futuro muchas de las ideas de las NoSQL aplicadas a las bases relacionales. En el futuro, usarás más de un solo tipo de bases de datos. Aquella que se adapte a tu aplicación y más aún, aquella que se adapte a cierto caso de uso de tu aplicación. Por lo que no será raro ver desarrollos que usen más de un solo tipo de base de datos. El punto es que debes seguir adaptándote, perderle el miedo a salir de la seguridad de un RDBMS y empezar a usar otras alternativas. Recuerda que no se trata de usar la mejor herramienta, sino de usar la mejor herramienta para tu problema específico.

Términos

HashMap
Una tabla hash, matriz asociativa, mapa hash, tabla de dispersión o tabla fragmentada es una estructura de datos que asocia llaves o claves con valores. La operación principal que soporta de manera eficiente es la búsqueda: permite el acceso a los elementos (teléfono y dirección, por ejemplo) almacenados a partir de una clave generada (usando el nombre o número de cuenta, por ejemplo). Funciona transformando la clave con una función hash en un hash, un número que identifica la posición (casilla o cubeta) donde la tabla hash localiza el valor deseado.

BLOB
Los BLOB (Binary Large Objects, objetos binarios grandes) son elementos utilizados en las bases de datos para almacenar datos de gran tamaño que cambian de forma dinámica.