Esta mañana, Matt Aslett de The 451 blogueó sobre El principio del fin de NoSQL en el que destacaba la inutilidad del nombre de la categoría NoSQL. Buen post, como siempre. Pero esto no es nuevo. La gente lleva quejándose del término desde el día en que se acuñó.
Estoy totalmente de acuerdo con Matt en que centrarse en los casos de uso ("¿qué problema intentas resolver?") será mucho más productivo que centrarse en las etiquetas. Pero discrepo con Matt cuando parece insinuar que puede ser más útil categorizar en función del modelo de datos subyacente (clave-valor, documento, orientado a columnas, gráfico, etc.). Estas categorías sólo ofrecen una mejora marginal si uno se centra en evaluar la idoneidad para una tarea concreta.
Mongo es una base de datos de documentos. También lo es Couch. Pero estas dos soluciones van en direcciones drásticamente diferentes desde la perspectiva de los casos de uso.
Mongo es una base de datos de documentos. Cassandra es una base de datos orientada a columnas. Membase y Riak son almacenes de valores clave. Sin embargo, desde el punto de vista de los casos de uso, estas soluciones chocan frontalmente. Hoy en día, los clientes las evalúan indistintamente y cada una gana o pierde, a menudo basándose en capacidades que no tienen nada que ver con el modelo de datos subyacente.
Sí, NoSQL es un nombre de categoría inútil.
Hay al menos dos buenas razones por las que el apodo NoSQL apesta:
- Algunos sistemas "NoSQL" ofrecen en realidad dialectos de SQL como lenguaje de consulta para acceder a los datos de la base de datos. Google App Engine dispone del Lenguaje GQL. Quest tiene Toad para bases de datos en nube que pretende ofrecer una interfaz SQL para Hbase, Azure Tables, SimpleDB de Amazon y otras bases de datos "NoSQL". Colmena aporta un dialecto de SQL a Hadoop, facilitando el ETL.
- Como señala Matt, hay demasiadas clases diferentes de tecnología agrupadas bajo la bandera NoSQL hoy. No cabe duda. Pero yo propongo que hablar simplemente de un aspecto de una compleja pila tecnológica sólo nos acerca marginalmente a abordar el verdadero problema. Los seres humanos estamos programados para desear categorías ordenadas en las que agrupar conceptos y cosas. Pero sugiero que NoSQL como etiqueta para Mongo es sólo ligeramente menos útil que decir que Mongo es una base de datos de documentos, si lo que estás tratando de hacer es averiguar lo que es bueno para.
Categorizar por modelo de datos también es bastante inútil.
Entonces, ¿cuál sería un conjunto de categorías bonito, limpio y representativo para todas estas soluciones emergentes? ¿Una que realmente permitiera a un observador determinar si la categoría de la solución es apropiada o no para un caso de uso determinado? No tengo la respuesta y no estoy seguro de que exista una buena respuesta. Tal vez los propios casos de uso proporcionen la categorización adecuada. En cualquier caso, estoy deseando leer el informe 451 que Matt indica que ayudará a estructurar el pensamiento en torno a estas "alternativas de bases de datos".
En última instancia, para clasificar estas soluciones habrá que ir más allá del modelo de datos subyacente (clave-valor, documento, orientado a columnas, gráfico, etc.). En su lugar, estos sistemas deben compararse utilizando un conjunto de atributos más amplio y, esperemos, manejable: ¿Hay que declarar un esquema antes de insertar los datos? ¿Se puede cambiar el esquema sobre la marcha si es necesario? ¿Es difícil hacerlo? ¿Puede la base de datos distribuirse de forma transparente (para una aplicación) entre varias máquinas o se trata de una solución centrada en un único servidor? ¿Es necesario desmontar la base de datos para añadir o eliminar capacidad? ¿Se puede consultar la base de datos con un lenguaje de consulta o hay que escribir código? ¿Mantiene el sistema índices para acelerar las consultas? ¿Cuál es el rendimiento de la base de datos en operaciones aleatorias y secuenciales? ¿Cuál es su rendimiento en las lecturas frente a las escrituras? ¿Los datos se escriben en un soporte duradero de forma inmediata o con el tiempo? ¿Y en caso de fallo del centro de datos? ¿Puedo cambiar esa exposición mediante operaciones síncronas? ¿Cómo afectará esto al rendimiento? ¿Puede la base de datos funcionar más allá de los límites del centro de datos? ¿Siempre leeré lo que escribo o habrá periodos de incoherencia de datos entre lectores?
Sin duda, estas preguntas son mucho más pertinentes a la hora de determinar la idoneidad para un determinado caso de uso. Una vez más, existe un bajo coeficiente de correlación cuando se comparan las respuestas a estas preguntas con las estrechas categorías en las que se clasifican estos sistemasY poco importa si las agrupamos todas en una gran categoría "NoSQL" o si las dividimos en subcategorías basadas en un enfoque de modelo de datos de un solo eje (clave-valor, documento, orientado a columnas, gráfico, etc.).
¿Es NoSQL una repetición del fiasco de OODBMS a finales de los 90?
¿Por qué hay tanto ruido en torno a NoSQL? ¿Se trata de una repetición del bombo de las bases de datos orientadas a objetos que todos vivimos a finales de la década de 1990? En aquel fiasco, los vendedores de OODBMS, los expertos y los inversores echaron por tierra la tecnología de bases de datos relacionales por considerarla poco "compatible" con los modelos de desarrollo de aplicaciones orientadas a objetos cada vez más dominantes. Se afirmaba que era más "natural" para los desarrolladores almacenar los datos en la base de datos en su forma nativa de objeto, con el argumento de que también sería más eficiente.
Pero, en realidad, no se trataba de un problema real. De hecho, el paso de una tecnología conocida y operativa a una solución no probada que prometía un enfoque más "elegante" y teóricamente correcto sólo garantizaba una cosa: trastornos. Las capas de mapeo objeto-relacional (ORM) diseñadas para salvar el "desajuste" entre los modelos de datos objeto y relacional no son perfectas; pero son mejores que poner el mundo patas arriba si no es necesario. Las decenas de miles de millones de dólares de ingresos previstos por los analistas para el mercado de los OODBMS nunca llegaron a materializarse.
Entonces, ¿existe ahora un problema real? ¿Un caso o casos de uso reales para los que las tecnologías de bases de datos existentes son realmente insuficientes? ¿En los que la disrupción de un cambio tecnológico tendrá un impacto económico sustancial? La respuesta es un rotundo sí.
Los casos de uso están impulsando la divergencia, y la convergencia, de las soluciones NoSQL.
Couch ha reclamado el caso práctico de sincronización de datos móviles. En un mundo informático cada vez más dominado por los dispositivos móviles, la sincronización de datos entre la nube y los dispositivos móviles (para disponer de los datos incluso cuando están desconectados de la red) es un problema que muchas aplicaciones deben resolver. Hay que tener en cuenta muchas cosas: conectividad intermitente, plataformas muy divergentes en las que deben ejecutarse estas bases de datos sincronizadas y, quizá, la expectativa de que el conjunto de datos que se mueve y sincroniza normalmente tenga que caber en una sola caja o dispositivo. Couch se centra en estos requisitos, y hace las suposiciones simplificadoras apropiadas, lo que permite a Couch abordar el caso de uso mejor que nadie. Couch es una base de datos de documentos. También lo es Mongo. Mongo es una solución pobre para este caso de uso. No está diseñado para mantener sincronizados sistemas conectados de forma transitoria y, a pesar de que Mongo fue diseñado inicialmente como una base de datos de un solo nodo, el trabajo de fragmentación y replicación realizado en el último año indica claramente que Mongo se está moviendo en una dirección diferente. En este caso, hay claramente divergencia de soluciones, incluso en el segmento más restringido de "bases de datos documentales" del mercado "NoSQL".
Por otro lado, existe la categoría cruzada convergencia entre otras soluciones NoSQL que intentan abordar otro caso de uso extremadamente amplio y generalizado: el almacenamiento de datos detrás de aplicaciones web interactivas. En Membase hablamos cada semana con muchos usuarios potenciales que se enfrentan a este problema, y nos evalúan constantemente frente a Cassandra (columna), Mongo (documento) y Riak (también clave-valor).
Las aplicaciones web que permiten a las organizaciones interactuar directamente con los consumidores son cada vez más la forma más común de nuevo sistema de software interactivo que se está construyendo. Estos sistemas se caracterizan por patrones de uso concurrentes aleatorios por parte de grandes poblaciones de usuarios (gran audiencia) y por su propensión a acumular grandes conjuntos de datos (grandes datos). También existe una tendencia hacia el modelo de computación en nube, especialmente para este tipo de aplicaciones, en las que se prefiere "escalar" (añadiendo más instancias de máquinas en nube, máquinas virtuales o servidores básicos) en lugar de ejecutar cargas de trabajo en grandes máquinas dedicadas. Estas realidades han llevado a la necesidad generalizada de una nueva clase de sistema de gestión de bases de datos que esté diseñado, desde la base, para permitir escala horizontal y soportar de forma rentable medidas elevadas de concurrencia frente a conjuntos de datos en rápido crecimiento. Quizás podamos llamar a esto base de datos en la nubeLa base de datos elástica, la base de datos scale-out o la base de datos auto-sharding (: P).
¿Qué debe ofrecer una base de datos para resolver este problema? Yo diría que debe ser sencilla, rápida, elástica y segura. Si consideramos Membase, Mongo, Cassandra y Riak, cada una de las cuales pretende explícitamente resolver este problema generalizado de "base de datos en la nube", las puntuaciones en cada uno de estos puntos varían.
Centrémonos en la primera característica. Para tener éxito, una base de datos en la nube de uso general debe ser sencilla de obtener, desarrollar y operar en producción.
- Membase es extremadamente fácil de conseguir, instalar y empezar a usar. También lo es Mongo - más fácil que Membase en algunos casos, más difícil en otros. Cassandra es un reto en casi todas las situaciones.
- Mongo es fácil de desarrollar contra - proporcionando consultas enriquecidas, gestión de índices y la capacidad de operar con una variedad de tipos de datos interesantes dentro de la propia base de datos. Membase proporciona a los desarrolladores una API de clave-valor compatible con Memcached que, aunque es extremadamente fácil de usar, impone una mayor carga al desarrollador de aplicaciones para muchas operaciones comunes de bases de datos que Mongo. Cassandra presenta un modelo de desarrollo más complicado, pero permite consultas enriquecidas. Las consultas de Riak se basan exclusivamente en map-reduce.
- Membase es fácil de gestionar en producciónMongo ofrece un amplio conjunto de herramientas de supervisión y gestión que proporcionan una visión profunda del funcionamiento de un clúster de servidores pequeño o grande, aumentando el tiempo de actividad del sistema. Mongo proporciona mucha menos información sobre el funcionamiento de un clúster, y esta deficiencia fue la principal señalada por Mongo tras la interrupción de FourSquare.
Se puede hacer una comparación similar para cada una de las características restantes: rapidez, elasticidad y seguridad. Cada solución es fuerte en algunas de estas áreas y relativamente débil en otras.
Pero lo más importante es que cada una de estas soluciones se está moviendo para apuntalar sus deficiencias relativas para satisfacer mejor las necesidades de los clientes. Existe una convergencia impulsada por los casos de uso. Ningún proyecto se centra simplemente en ser un gran sistema de gestión de bases de datos clave-valor, o documento, u orientado a columnas. Cada uno se centra en resolver un problema del mundo real: proporcionar un lugar rentable para almacenar datos detrás de aplicaciones web interactivas, como se ha caracterizado anteriormente. Para ello, Membase está añadiendo capacidades de consulta e indexación. Mongo acaba de incorporar el soporte de sharding y réplica a su solución inicial de servidor único y está rediseñando su motor de almacenamiento para aumentar la seguridad de los datos. Redis, otra solución "NoSQL", está añadiendo capacidades de gestión de clústeres para ser verdaderamente "elástica". Existe una clara convergencia entre las soluciones dirigidas a este caso de uso. Cada uno de estos proyectos identifica la segmentación de anuncios y ofertas, los juegos sociales, la gestión del estado de sesiones de aplicaciones web y el procesamiento de eventos en tiempo real como casos de uso para los que está pensado su sistema. Todos ellos son casos de uso de aplicaciones web interactivas.
La tecnología no relacional es el hilo conductor real y coherente de las bases de datos en la nube
Hay una cosa que se puede decir sistemáticamente de estas soluciones de bases de datos en la nube, desde una perspectiva técnica. Pretenden escalar horizontalmente, y eso es muy difícil (imposible) de hacer de forma rentable, con un rendimiento aceptable, empleando el modelo de datos relacional. Así que cada uno de estos sistemas de bases de datos "NoSQL" son sistemas "no relacionales". Eso es, en última instancia, lo que se pretendía con "NoSQL".
De hecho, cada uno de estos sistemas es, en esencia, un almacén de valores clave. Varían en las técnicas utilizadas para mirar dentro de los valores o para agrupar los valores con el fin de operar sobre ellos (key-value ve el valor como un blob opaco, document ve el valor como una colección formateada de tipo atributo-datos, column-oriented store agrupa pares KV individuales utilizando una(s) estructura(s) de datos separada(s) en "columnas"). Pero en cada caso, en lugar de desglosar un registro de datos (tupla) en entradas almacenadas en un conjunto normalizado de tablas con referencias cruzadas, como en el modelo relacional, estas bases de datos en la nube almacenan los campos de datos de un "registro" concreto en una única ubicación. Esto hace que sea muy fácil distribuir automáticamente los registros ("fragmentar la base de datos") entre muchos nodos de un clúster de bases de datos. Este enfoque tiene sus pros y sus contras.
En el lado de los contras, la desnormalización conlleva un aumento del tamaño total del conjunto de datos (ya que algunos datos se almacenan inevitablemente varias veces en la base de datos, mientras que en una base de datos relacional normalizada sólo habría referencias), y aumenta la complejidad de las uniones. En el lado positivo, facilita la distribución de datos en muchos servidores baratos y el cambio de esa distribución bajo demanda sin interrupción de la aplicación. También elimina el requisito de predefinir un esquema (o cambiar el esquema de la base de datos) antes de insertar datos. En caso de duda, guárdelos. Puede deducir un esquema más tarde. Esto facilita enormemente la recopilación de información que antes podía haber quedado sin recoger. En última instancia, quizá sea aquí donde la tecnología de bases de datos NoSQL creará más valor.
Así que busquemos un nombre mejor.
Estamos listos para deshacernos de la etiqueta NoSQL. Si la gente puede unirse en torno a una taxonomía más centrada en los casos de uso, creo que sería una victoria para los usuarios que luchan por averiguar para qué sirven estos sistemas.
Base de datos en la nube es un nombre que llega al corazón del problema que Membase intenta resolver, por todas las razones expuestas anteriormente. Pero puede resultar demasiado moderno o amorfo. Me encantaría saber qué opina la gente.
