NoSQL para no programadores

Superados los hypes de Django y Ruby On Rails, la última moda de tecnología es hablar de tecnologías NoSQL como medio de almacenamiento distribuido no relacional. En parte lo que pasa es que como se ha disparado la inversión en big data pues los periodistas que cubren las noticias de tecnología de Silicon Valley han publicado un gran número de nota de prensa y comentarios sobre los nuevos productos.

La pregunta que pretendo responder en este post es ¿Debe alguien que no es programador profundo preocuparse por las tecnologías NoSQL?.

Si tienes una base de datos con menos de cien millones de registros o un sitio web con menos de un millón de visitas al día, probablemente no necesitas preocuparte en absoluto ni siquiera por saber lo que es NoSQL. No obstante, la cantidad de información disponible está creciendo tan rápido que es fácil que en los próximos años muchas empresas alcancen los límites de las bases de datos relacionales. Y ya hoy por hoy es imposible concebir servicios de alto tráfico como Twitter sin tecnologías NoSQL.

La falta de escalabilidad puede visualizarse mediante las gráficas que muestran cómo se deteriora inexorablemente el rendimiento de un sistema relacional no distribuido cuando aumenta el número de usuarios. El problema técnico es que debido a su arquitectura intrínseca las bases de datos relacionales no se pueden distribuir de forma sencilla sobre varias máquinas. Existen algunas implementaciones comerciales de bases de datos paralelas pero son demasiado caras como infraestructura software de un sitio web y además una de las cosas que demostró Google es que las aplicaciones “big data” deben correr sobre pequeños servidores baratos. En 1998 Altavista utilizaba 20 máquinas DEC con multiprocesadores Alpha de 64 bits dotadas de un total de 130Gb de RAM y 500Gb de disco para indexar toda la web de entonces y atender 13 millones de consultas al día. Pero la infraestructura de Altavista fue incapaz de seguir el crecimiento de la web al ritmo que lo hacían los nodos clónicos de Google basados en MySQL. Y hoy en día Facebook tiene más de 2.000 servidores basados en MySQL.

Coste vs Tiempo de Respuesta según aumenta el número de usuarios
Fuente: NoSQL Scalability and Performance (Couchbase).

Para empezar a entender los fundamentos relevantes de las tecnologías NoSQL hagamos un poco de historia. Las primeras tecnologías NoSQL son realmente anteriores a las bases de datos relacionales y se utilizaban porque ofrecían mejor rendimiento a costa de menos funcionalidades y la carencia del poder expresivo del lenguaje SQL. Una de las más veteranas, Berkely DB era uno de los soportes de almacenamiento de MySQL alternativo a InnoDB y MyISAM hasta que que MySQL le retiró el soporte el 2006. Incluso ahora varios sistemas de almacenamiento distribuido no relacional siguen usando Berkeley DB como back-end para la persistencia de datos. Berkeley DB es en esencia muy sencillo, se le proporciona una clave (típicamente en forma de cadena de texto) y un objeto binario y Berkeley DB almacena el objeto siendo luego posible recuperarlo dada su clave. También es posible crear claves alternativas o índices con duplicados para los objetos y recuperar los objetos ordenados por dichos índices. Berkeley DB no es cliente servidor, su código funciona dentro del espacio de direcciones de la aplicación que lo usa, lo cual aumenta su velocidad de respuesta pero también hace que sea inútil “tal cual” como sistema distribuido ya que la aplicación cliente debe estar en la misma máquina que los archivos de Berkeley DB para que sea posible garantizar la integridad de las transacciones.

Los sistemas de almacenamiento no relacional proporcionaban una solución para algunas aplicaciones que requerían un rendimiento en lectura y escritura de datos que los SGBDR no podían alcanzar, pero fue de las diferentes necesidades y retos técnicos con los que que se fueron topando los sitios como Facebook o LinkedIn de donde surgieron realmente las primeras aplicaciones open source de almacenamiento distribuido. Los portales se encontraban con problemas de escalabildiad y los ISPs con problemas para dimensionar y prededir el comportamiento de las bases de datos relacionales. Un serio obstáculo para ofrecer bases de datos relacionales en modalidad de software como servicio es que es muy fácil escribir consultas SQL que saturen por completo el servidor durante segundos, minutos o incluso horas.

Las aplicaciones NoSQL –o NewSQL o hasta N★SQL como algunos se refieren a ellas– pueden dividirse en seis grupos:

1. Sistemas “BigTable”: Son básicamente una forma de repartir las filas y columnas clásicas de una tabla en diferentes servidores. Muchas de sus ideas están derivadas de Google Big Table y Amazon Dynamo. Las opciones Open Source más populares son Cassandra, HBase, Hypertable. Y como servicio puede utilizarse Amazon SimpleDB.

2. Sistemas “Atributo-Valor”: Son los sistemas de funcionalidad más sencilla, en los cuales simplemente se recupera un objeto binario (BLOB) a partir de una clave. Los sistemas atributo-valor no distribuidos como Berkeley DB o Redis suelen usarse como software base de otras aplicaciones, bien para la capa de persistencia bien para la implementación de caches. Entre los sistemas atributo valor distribuidos podemos destacar Voldemort y Riak este último incorporando también algunas ideas inspiradas en Dynamo. Los sistemas atributo-valor no son muy prácticos para almacenar datos estructurados, se suelen utilizar para almacenar y recuperar objetos cuya estructura interna es opaca a la aplicación cliente, por ejemplo, el almacenamiento de imágenes que usa Tumblr está basado en el servicio atributo-valor de Amazon S3. Además de Amazon S3, en modalidad de software como servicio de tuplas atributo-valor también está disponible Azure Table Storage de Microsoft.

3. Almacenes de documentos: Los documentos que manejan estos sistemas son un conjunto de datos identificados por etiquetas, internamente pueden ser documentos JSON o de otro tipo que se recuperan mediante claves primarias. También suelen disponer de funcionalidades para combinar documentos al estilo de las JOINs de SQL. Los almacenes de documentos pueden ser muy convenientes en casos en los que, por ejemplo, hay que almacenar formularios web rellenados por el usuario, pero estos formularios cambian muy amenudo. En lugar de tener que añadir una columna a una tabla por cada campo nuevo en un formulario diferente, o crear una tabla distinta para cada tipo de formulario, los almacenes de documentos permiten simplemente convertir el formulario a JSON o XML y guardarlo “tal cual” indexándolo por los campos que se desee. Los dos productos Open Source más populares son CouchDB y Mongo DB.

4. Grafos: Para representar información estructurada en forma de red aparecieron aplicaciones como Neo4j o Infinite Graph.

5. Índices “full-text”: Se trata de sistemas orientados a crear índices de texto no estructurado. El producto Open Source más popular es Apache Lucene sobre el que se han construido otros productos como Bobo, Zoie o Solr.

6. Almacenes de documentos XML: Se trata de un almacén especialmente diseñado para almacenar documentos XML. Proporcionan XPath como lenguaje de consulta. Un producto popular es BaseX.

NoSQL Matrix

Disponibilidad de mano de obra cualificada en tecnologías NoSQL.

Para que una nueva solución tecnológica sea viable no es suficiente con que sea técnicamente conveniente, además es necesario que sea posible encontrar en el mercado de trabajo a un preico asequible a profesionales capaces de manejar la nueva tecnología. Los gráficos que se vienen a continuación muestran que NoSQL es un fenómeno originario del Área de la Bahía que se ha ido extendiendo a diferentes velocidades según el producto y que es aún relativamente poco conocido entre los programadores. En el estudio realizado por el Instituto de Analíticas Avanzadas de la Universidad de Carolina del Norte sobre el que están basados algunos de los datos del Grupo 451 se encontraron 366.084 miembros de LinkedIn con “MySQL” en su perfil frente a sólo 9.079 con “Hadoop” lo cual –extrapolado– implicaría que menos del 2,5% de los programadores tienen actualmente algún conocimiento de NoSQL. Sin embargo, las cifras de otros productos como Cassandra o Redis muestran que en Europa y particularmente en España existe una clara tendencia hacia la adquisición de competencias técnicas NoSQL.

Distribución geográfica de los miembros de LinkedIn con diversas tecnologías en su perfil


NoSQL USA vs rest of the world
MySQL Hadoop
Distribución geográfica de miembros de LinkedIn con MySQL en su perfil Distribución geográfica de los miembros de LinkedIn con Hadoop en su perfil
HBase Couchbase
Distribución geográfica de miembros de LinkedIn con HBase en su perfil Distribución geográfica de miembros de LinkedIn con Couchbase en su perfil
Cassandra Riak
Distribución geográfica de miembros de LinkedIn con Cassandra en su perfil Distribución geográfica de miembros de LinkedIn con Riak en su perfil
MongoDB Redis
Distribución geográfica de miembros de LinkedIn con MongoDB en su perfil Distribución geográfica de miembros de LinkedIn con Redis en su perfil

Fuente: Too much information

Conclusiones y Recomendaciones.

1ª) Mantener en el radar las tecnologías NoSQL. Puede que no sean necesarias mañana mismo, pero con la explosión de datos que se avecina puede que sí lo sean pasado mañana.

2ª) No usar tecnologías NoSQL para problemas que pueden resolverse con SGBDR tradicionales. Algunos programadores son adictos a las novedades y les encanta instalarse cosas. Puede que Erlang sea un fantástico lenguaje de programación concurrente pero ello no implica que CouchDB sea una solución mágica sólo por estar escrita en él.

3ª) Ser consciente de la Paradoja de la Elección. Están apareciendo tantos sistemas alternativos sin que haya (por ahora) ninguno claramente dominante que puede ser difícil elegir el más idóneo entre ellos a medio-largo plazo.

4ª) Buscar talento y no tecnología. Para enfrentarse a los retos del Big Data, buscar personas con talento que tengan conocimientos técnicos y de negocio, no tecnologías presuntamente milagrosas.

Post relacionado: Cronograma de tecnologías NoSQL
Artículo relacionado: Big Data, la era de la avalancha de datos (Manuel Ángel Méndez)

Actualización: Database Landscape Map (Matthew Aslett)

Actualización:
Neither fish nor fowl: the rise of multi-model databases (Matthew Aslett)

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Esta entrada fue publicada en Computación en la Nube, Minería de Datos, Morfeo Think Tank, Tecnologías Emergentes, Tecnologías Libres. Guarda el enlace permanente.

13 respuestas a NoSQL para no programadores

  1. Jaime dijo:

    Sólo por comentar un detalle de las tecnologías NoSQL que no se ha dicho (aunque esto depende de cada una, por supuesto), es el tema de la versatilidad y adaptabilidad. Queda un poco implícito, pero por concretarlo un poco más explícitamente.

    Mientras que usar una base de datos SQL generalmente implica adaptarte a ella (con o sin trucos tales como ORMs, etc), incluso llegando al extremo de requerir gente especializada únicamente en ellas (los famosos DBAs), normalmente las soluciones NoSQL encajan mejor en el ciclo de desarrollo. Vamos, que uno no tiene que comerse tanto la cabeza a la hora de diseñar el esquema, relaciones, etc y luego poder configurarlo mejor a las necesidades, y cambiarlo posteriormente cuando haga falta.

    Un artículo muy interesante, especialmente el reparto de distintas Bases de Datos por el mundo ;-)

  2. Alfonso E.M. dijo:

    Precisamente sistemas como Chef (para controlar despliegues y configuraciones de ordenadores) abandonan CouchDB en favor de MySql. Y es que a veces la novedad nos ciega B-)

  3. Hola Sergio,

    Las modas van muy rápido, la de NoSQL ya tiene algunos años. Ahora hay una nueva moda que se llama NewSQL.

    http://siliconangle.com/blog/2011/12/29/newsql-will-prevail-in-2012-says-mits-michael-stonebraker/

    Hay que dejar claro que no hay nada que impida la escalabilidad y la distribución de las bases de datos relacionales. Los que no escalan bien son algunos productos muy concretos y muy conocidos.

    Algunos nombres son:

    Clustrix, GenieDB, ScalArc, Schooner, VoltDB, RethinkDB, ScaleDB, Akiban, CodeFutures, ScaleBase, Translattice y NimbusDB.

    También están resurgiendo los SGBD SQL basados en memoria RAM como el nuevo Hana de SAP.

    Crear un buen SGBD distribuido, escalable y eficiente es mucho más difícil que crear un simple sistema de clave-valor, por lo cual las soluciones NoSQL salen como setas y a las NewSQL y similares les va a costar mucho más madurar, pero NoSQL no es más que una chapuza rápida para ir saliendo del paso. No tiene futuro a largo plazo excepto para un pequeño nicho de aplicaciones super especializadas con bases de datos muy sencillas.

  4. Pingback: NoSQL para no programadores | Tantas cosas que no se …

  5. Pingback: » NoSQL para no programadores

  6. Juan dijo:

    Disculpad la ignorancia, pero tenia entendido que Google utilizaba Berkeley DB

  7. Pingback: NoSQL para no programadores

  8. Pingback: Big Data, la era de la avalancha de datos | TICbeat

  9. Pingback: Resumen semanal de temas de Java « Jbravomontero's Blog

  10. Pingback: NoSQL para no programadores « Conocimiento Libre (o lo que está detrás del Software Libre)

  11. Pingback: El ecosistema de productos Big Data | La Pastilla Roja

  12. Pingback: El ecosistema de productos Big Data | La Pastilla Roja

  13. Marshall Dev dijo:

    Muy interesante el tema, a decir verdad es conveniente preguntarse si dentro de poco estaremos viendo operando esto en nuestras computadoras para poder procesar una mayor cantidad de información, sobre todo los recursos multimedia.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>