7 duras verdades sobre la revolución NoSQL

La palabra de moda NoSQL ha estado haciendo metástasis durante varios años. El entusiasmo por estos rápidos almacenes de datos ha sido embriagador, y somos tan culpables como cualquiera de ver el atractivo innovador de NoSQL. Sin embargo, la luna de miel está llegando a su fin, y es hora de empezar a equilibrar nuestro entusiasmo con algunas verdades duras.

No nos malinterpretes. Todavía estamos trabajando para probar el último experimento en la construcción de un mecanismo simple para almacenar datos. Todavía encontramos un gran valor en MongoDB, CouchDB, Cassandra, Riak y otros destacados de NoSQL. Todavía estamos planeando lanzar algunos de nuestros datos más confiables en estas pilas de código porque están creciendo mejor y más probadas cada día.

[También en: Destacados de NoSQL: Nuevas bases de datos para nuevas aplicaciones | Primer vistazo: base de datos Oracle NoSQL | Obtenga un resumen de las historias clave cada día en el boletín diario. ]

Pero estamos empezando a sentir la irritación, ya que los sistemas NoSQL están lejos de ser un ajuste perfecto y, a menudo, no funcionan correctamente. Los desarrolladores más inteligentes sabían esto desde el principio. No quemaron los manuales de SQL y enviaron desagradables gramas a la fuerza de ventas de su otrora devoto proveedor de SQL. No, los desarrolladores inteligentes de NoSQL simplemente señalaron que NoSQL significa "No solo SQL". Si las masas malinterpretaron el acrónimo, ese fue su problema.

Esta lista de quejas, grandes y pequeñas, es, por tanto, un intento de documentar este hecho y aclarar las cosas. Está destinado a aclarar las cosas ahora para que podamos hacer un mejor trabajo entendiendo las compensaciones y los compromisos.

NoSQL dura verdad n. ° 1: JOIN significa consistencia

Una de las primeras quejas que tiene la gente sobre los sistemas SQL es el costo computacional de ejecutar un JOIN entre dos tablas. La idea es almacenar los datos en un solo lugar. Si mantiene una lista de clientes, coloque sus direcciones postales en una tabla y use sus ID de cliente en todas las demás tablas. Cuando extrae los datos, JOIN conecta las ID con las direcciones y todo permanece consistente.

El problema es que los JOIN pueden ser costosos y algunos administradores de bases de datos han inventado comandos JOIN complejos que asombran la mente, convirtiendo incluso el hardware más rápido en un fango. No fue una sorpresa que los desarrolladores de NoSQL convirtieran su falta de JOIN en una característica: ¡mantengamos la dirección del cliente en la misma tabla que todo lo demás! La forma NoSQL es almacenar pares clave-valor para cada persona. Cuando llegue el momento, los recuperas todos.

Por desgracia, las personas que quieren que sus tablas sean coherentes todavía necesitan JOIN. Una vez que comienzas a almacenar las direcciones de los clientes con todo lo demás sobre ellos, a menudo terminas con varias copias de esas direcciones en cada tabla. Y cuando tiene varias copias, debe actualizarlas todas al mismo tiempo. A veces eso funciona, pero cuando no funciona, NoSQL no está listo para ayudar con las transacciones.

Espera, dices, ¿por qué no tener una tabla separada con la información del cliente? De esa manera, solo habrá un registro para cambiar. Es una gran idea, pero ahora puedes escribir el JOIN tú mismo en tu propia lógica.

La dura verdad n. ° 2 de NoSQL: transacciones complicadas

Digamos que está bien vivir sin unir tablas porque quiere la velocidad. Es una compensación aceptable y, a veces, los administradores de bases de datos SQL desnormalizan las tablas solo por esta razón.

El problema es que NoSQL dificulta la coherencia de las distintas entradas. A menudo, no hay transacciones para asegurarse de que los cambios en varias tablas se realicen juntos. Para eso, está solo, y una falla podría asegurar que las tablas se vuelvan inconsistentes.

Las primeras implementaciones de NoSQL se burlaron de estas transacciones. Ofrecerían listados de datos que fueran consistentes, excepto cuando no lo fueran. En otras palabras, buscaron los datos de menor valor donde los errores no harían ninguna diferencia material.

Ahora, algunas implementaciones de NoSQL ofrecen algo parecido a una transacción. El producto NoSQL de Oracle, por ejemplo, ofrece control transaccional sobre los datos escritos en un nodo y le permite elegir una cantidad flexible de consistencia en múltiples nodos. Si desea una coherencia perfecta, debe esperar a que cada escritura llegue a todos los nodos. Varios otros almacenes de datos NoSQL están experimentando con agregar más estructura y protección como esta.

NoSQL dura verdad n. ° 3: las bases de datos pueden ser inteligentes

A muchos programadores NoSQL les gusta presumir de cómo su código ligero y su mecanismo simple funcionan extremadamente rápido. Por lo general, tienen razón cuando las tareas son tan simples como el interior de NoSQL, pero eso cambia cuando los problemas se vuelven más difíciles.

Considere el viejo desafío de UNIRSE. Una vez que los programadores NoSQL comienzan a generar sus propios comandos JOIN en su propia lógica, comienzan a intentar hacerlo de manera eficiente. Los desarrolladores de SQL han pasado décadas desarrollando motores sofisticados para manejar los comandos JOIN de la manera más eficiente posible. Un desarrollador de SQL me dijo que estaba tratando de sincronizar su código con el disco duro giratorio para que solicitara datos solo cuando la cabeza estuviera justo encima del lugar correcto. Esto puede parecer extremo, pero los desarrolladores de SQL han estado trabajando en trucos similares durante décadas.

No hay duda de que los programadores se pasan días tirando de los pelos tratando de estructurar sus consultas SQL para aprovechar toda esta inteligencia latente. Puede que no sea fácil de tocar, pero cuando el programador lo descubre, las bases de datos realmente pueden cantar.

Un lenguaje de consulta sofisticado como SQL siempre tiene el potencial de eclipsar a un lenguaje de consulta poco sofisticado como los que se encuentran en NoSQL. Puede que no importe con resultados simples, pero cuando la acción se vuelve compleja, el SQL se ejecuta en la máquina justo al lado de los datos. Tiene poca sobrecarga para obtener los datos y hacer el trabajo. Un servidor NoSQL generalmente tiene que enviar los datos a donde van.

NoSQL dura verdad n. ° 4: demasiados modelos de acceso

En teoría, se supone que SQL es un lenguaje estándar. Si usa SQL para una base de datos, debería poder ejecutar la misma consulta en otra versión compatible. Esta afirmación puede funcionar con algunas consultas sencillas, pero todos los administradores de bases de datos saben que puede llevar años aprender las idiosincrasias de SQL para diferentes versiones de la misma base de datos. Las palabras clave se redefinen y las consultas que funcionaron en una versión no funcionarán con otra.

NoSQL es aún más misterioso. Es como la Torre de Babel. Desde el principio, los desarrolladores de NoSQL han tratado de imaginar el mejor lenguaje posible, pero tienen imaginaciones muy diferentes. Este semillero de experimentación es bueno, hasta que intentas saltar entre herramientas. Una consulta para CouchDB se expresa como un par de funciones de JavaScript para mapear y reducir. Las primeras versiones de Cassandra usaban una API sin procesar de bajo nivel llamada Thrift; las versiones más recientes ofrecen CQL, un lenguaje de consulta similar a SQL que debe ser analizado y comprendido por el servidor. Cada uno es diferente a su manera.

Cada herramienta no solo tiene sus propias idiosincrasias, sino que tiene una filosofía y una forma de expresarla completamente diferentes. No hay formas fáciles de cambiar entre almacenes de datos y, a menudo, te quedas escribiendo toneladas de código adhesivo solo para tener la opción de cambiar en el futuro. Puede que esto no sea demasiado difícil cuando se introducen pares de claves y valores en el sistema, pero puede agravarse cada vez más a medida que se introduce la complejidad.

La dura verdad n. ° 5 de NoSQL: la flexibilidad del esquema es un problema a la espera de suceder

Una de las grandes ideas del modelo NoSQL es no requerir un esquema. En otras palabras, los programadores no necesitan decidir de antemano qué columnas estarán disponibles para todas y cada una de las filas de una tabla. Una entrada puede tener 20 cadenas adjuntas, otra puede tener 12 números enteros y otra puede estar completamente en blanco. Los programadores pueden tomar la decisión siempre que necesiten almacenar algo. No necesitan pedir permiso al DBA y no necesitan completar toda la documentación para agregar una nueva columna.

Toda esa libertad suena embriagadora y, en las manos adecuadas, puede acelerar el desarrollo. Pero, ¿es realmente una buena idea para una base de datos que podría vivir a través de tres equipos de desarrolladores? ¿Es incluso viable para una base de datos que podría durar más de seis meses?

En otras palabras, los desarrolladores pueden querer tener la libertad de lanzar cualquier par antiguo a una base de datos, pero ¿quieres ser el quinto desarrollador en aparecer después de que cuatro hayan elegido sus propias claves? Es fácil imaginar una variedad de representaciones de "cumpleaños", y cada desarrollador elige su propia representación como clave cuando agrega el cumpleaños de un usuario a una entrada. Un equipo de desarrolladores puede imaginar casi cualquier cosa: "cumpleaños", "cumpleaños", "cumpleaños".

La estructura NoSQL no ofrece soporte para limitar este problema porque eso significaría reinventar el esquema. No quiere ser duro con la suavidad de los desarrolladores totalmente geniales. Un esquema se interpondría en el camino.

El hecho es que agregar una columna a una tabla no es un gran problema, y ​​la disciplina podría ser buena para el desarrollador. Así como ayuda a obligar a los desarrolladores a designar tipos de variables, también ayuda a obligar a los desarrolladores a designar el tipo de datos adjuntos a una columna. Sí, el DBA puede obligar al desarrollador a completar un formulario por triplicado antes de adjuntar esa columna, pero no es tan malo como tratar con media docena de claves diferentes creadas sobre la marcha por un programador.

NoSQL dura verdad n. ° 6: sin extras

Digamos que no quiere todos los datos en todas las filas y quiere la suma de una sola columna. Los usuarios de SQL pueden ejecutar una consulta con la operación SUM y enviarle un solo número.

Los usuarios de NoSQL obtienen todos los datos que se les envían y luego pueden hacer la adición ellos mismos. La suma no es el problema porque lleva aproximadamente la misma cantidad de tiempo sumar los números en cualquier máquina. Sin embargo, el envío de datos es lento y el ancho de banda necesario para enviar todos esos datos puede resultar caro.

Hay algunos extras en las bases de datos NoSQL. Si desea hacer algo más que almacenar y recuperar datos, probablemente lo hará usted mismo. En muchos casos, lo hará en una máquina diferente con una copia completa de los datos. El problema real es que a menudo puede ser útil realizar todos los cálculos en la máquina que contiene los datos porque el envío de los datos lleva tiempo. Pero duro para ti.

Están surgiendo soluciones NoSQL. La estructura de consulta Map and Reduce de MongoDB le proporciona una estructura JavaScript arbitraria para reducir los datos. Hadoop es un mecanismo poderoso para distribuir la computación en la pila de máquinas que también contiene los datos. Es una estructura en rápida evolución que ofrece herramientas que mejoran rápidamente para crear análisis sofisticados. Es muy bueno, pero aún nuevo. Y técnicamente Hadoop es una palabra de moda completamente diferente a NoSQL, aunque la distinción entre ellos se está desvaneciendo.

La dura verdad n. ° 7 de NoSQL: Menos herramientas

Claro, puede poner su pila NoSQL en funcionamiento en su servidor. Claro, puede escribir su propio código personalizado para enviar y extraer sus datos de la pila. Pero, ¿y si quieres hacer más? ¿Qué pasa si desea comprar uno de esos paquetes de informes sofisticados? ¿O un paquete de gráficos? ¿O descargar algunas herramientas de código abierto para crear gráficos?

Lo sentimos, la mayoría de las herramientas están escritas para bases de datos SQL. Si desea generar informes, crear gráficos o hacer algo con todos los datos en su pila NoSQL, deberá comenzar a codificar. Las herramientas estándar vienen listas para analizar datos de Oracle, Microsoft SQL, MySQL y Postgres. ¿Tus datos están en NoSQL? Están trabajando en eso.

Y estarán trabajando en eso por un tiempo. Incluso si pasan por todos los obstáculos para ponerse en marcha con una de las bases de datos NoSQL, tendrán que empezar de nuevo desde el principio para manejar el siguiente sistema. Hay más de 20 opciones diferentes de NoSQL, todas ellas con su propia filosofía y su propia forma de trabajar con los datos. Ya era bastante difícil para los fabricantes de herramientas soportar las idiosincrasias e inconsistencias en SQL, pero es aún más complicado hacer que las herramientas funcionen con todos los enfoques NoSQL.

Este es un problema que desaparecerá lentamente. Los desarrolladores pueden sentir la emoción en NoSQL, y modificarán sus herramientas para trabajar con estos sistemas, pero llevará tiempo. Quizás entonces comiencen con MongoDB, lo que no te ayudará porque estás ejecutando Cassandra. Los estándares ayudan en situaciones como esta, y NoSQL no es grande en estándares.

Deficiencias de NoSQL en pocas palabras

Todas estas deficiencias de NoSQL se pueden reducir a una simple declaración: NoSQL descarta la funcionalidad por velocidad. Si no necesita la funcionalidad, estará bien, pero si la necesita en el futuro, lo lamentará.

Las revoluciones son endémicas de la cultura tecnológica. Llega un nuevo grupo que se pregunta por qué la última generación construyó algo tan complejo y se propuso derribar las viejas instituciones. Después de un rato, comienzan a darse cuenta de por qué todas las instituciones antiguas eran tan complejas y comienzan a implementar las funciones una vez más.

Estamos viendo esto en el mundo NoSQL, ya que algunos de los proyectos comienzan a agregar cosas que parecen transacciones, esquemas y estándares. Ésta es la naturaleza del progreso. Derribamos cosas solo para reconstruirlas. NoSQL ha terminado con la primera fase de la revolución y ahora es el momento de la segunda. El rey esta muerto. Larga vida al rey.

Artículos relacionados

  • Destacados de NoSQL: nuevas bases de datos para nuevas aplicaciones
  • Primer vistazo: base de datos Oracle NoSQL
  • Flexionando NoSQL: MongoDB en revisión
  • 10 consejos de rendimiento esenciales para MySQL
  • 10 herramientas esenciales de MySQL para administradores
  • Domina MySQL en la nube de Amazon
  • El momento de los estándares NoSQL es ahora

Esta historia, "7 duras verdades sobre la revolución NoSQL", se publicó originalmente en .com. Siga los últimos avances en gestión de datos en .com. Para conocer los últimos avances en noticias de tecnología empresarial, siga .com en Twitter.