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.

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.

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

MySQL	Hadoop
HBase	Couchbase
Cassandra	Riak
MongoDB	Redis

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)