NoSQL: el movimiento en contra de las bases de datos

Base de datosUna reunión en San Francisco fue la inauguración de la comunidad de NoSQL, un grupo de personas que comparten la idea de destronar la tiranía de las bases de datos relaciones, costosas y lentas, en favor de una alternativa mucho más eficiente y barata para manipular datos.

"Las bases de datos relaciones nos ofrecen demasiado. Nos fuerzan a adaptar nuestros objetos para adaptarlos a una RDBMS (sistema de gestión de bases de datos relacional)", dice Jon Travis, uno de los principales ingenieros en SpringSource, y uno de los 10 presentadores en la reunión de NoSQL.

Las alternativas basadas en NoSQL "te ofrecen sólo lo que necesitás", dice Travis.

Surge el código abierto

Los primeros precursores son desarrolladores Web y Java, muchos de los cuales aprendieron a llevar adelante sus iniciativas (ajustadas en presupuesto) sin usar Oracle. Para esto construyeron sus propias soluciones para almacenar datos (emulando lo que hicieron Google y Amazon), y luego las publicaron como código abierto.

Hoy estas soluciones gestionan terabytes e incluso petabytes de datos para la Web 2.0, y ya no es factible volver atrás, por motivos técnicos, económicos e incluso ideológicos.

"Las empresas Web 2.0 pueden tomar riesgos y necesitan escalabilidad", dice Johan Oskarsson, el organizador de la reunión NoSQL y, como la mayoría de los participantes, un desarrollador Web (del sitio Last.fm). "Cuando se combinan estas dos cosas, hace que NoSQL sea una muy buena alternativa".

Muchos, dice Oskarsson, dejaron de usar la base de datos MySQL, una favorita de la Web 2.0 por mucho tiempo, en favor de una alternativa NoSQL porque las ventajas eran demasiado grandes para ignorar.

Por ejemplo, Facebok creó su almacen de datos Cassandra para soportar una nueva búsqueda en su sitio web, en vez de usar su base de datos MySQL existente. De acuerdo a la presentación del ingeniero de Facebook Avinash Lakshman, Casandra puede escribir hasta 50GB de datos en disco en tan sólo 0.12 milisegundos, más de 2500 veces más rápido que MySQL.

¿Y qué es NoSQL? (técnicamente hablando)

Los nombres de los proyectos son tan diversos como extraños: Hadoop, Voldemort, Dynomite, y otros. Pero suelen estar unificados por algunos puntos en común, incluyendo: 

No llamarlos "bases de datos". Werner Vogels, CTO de Amazon, se refiere a su sistema Dynamo como "un almacenamiento de clave-valor de alta disponibilidad". Google llama a su BigTable, otro de los modelos para muchos simpatizantes de NoSQL, "un sistema de almacenamiento distribuido para gestionar datos estructurados".

Pueden manejar enormes cantidades de datos. Hypertable, una implementación de código abierto basada en BigTable, se usa dentro del motor de búsqueda Zvents para escribir 1000 millones de celdas de datos por día, según cuenta el ingeniero Doug Judd en su presentación.

A su vez, BigTable, en conjunto con su tecnología hermana MapReduce, procesa hasta 20 petabytes de datos por día.

"Definitivamente la cantidad de datos es tan grande que las personas están buscando otras tecnologías", dice Travis de SpringSource, que con su tecnología VPork ayuda a los usuarios de NoSQL a realizar benchmarks de rendimiento de sus bases de datos alternativas.

Se ejecutan en clusters de servidores de  PC baratas. Los clusters de PC se pueden expandir de forma facil y barata sin la complejidad y el costo del "data sharding", que involucra recortar una base de datos en múltiples tablas para ejecutarse en grandes clusters o grillas.

Google cuenta que uno de sus clusters de BigTable más grande gestiona 6 petabytes de datos sobre miles de servidores.

"Oracle te va a decir que con el hardware y la configuración adecuada de Oracle RAC (Real Application Clusters) y algún otro software mágico pueden lograr la misma escalabilidad. ¿Pero a qué costo?", pregunta Javier Soltero, CTO de SpringSource.

Superan los cuellos de botella de rendimiento. Al no tener que realizar la traducción de datos hacia un formato amigable para SQL, las arquitecturas NoSQL son mucho más rápidas.

"SQL es un enfoque extraño para el código procedural, y casi todo el código es procedural", dice Curt Monash, un analista independiente de bases de datos y blogger. "El costo de mapear los datos a SQL puede valer la pena para los casos en que estos datos tengan que manipularse extensivamente... pero cuando la estructura de la base de datos es muy simple, SQL no parece ayudar".

Raffaele Sena, de Adobe Systems, dice que Adobe relanzó su servicio colaborativo ConnectNow Web hace un año y medio, y decidió no usar una base de datos por los motivos explicados por Monash.

Adobe usa Terracotta, un software Java para clustering, para gestionar los datos en formato Java. Sena explica que este enfoque es la clave por la cual el rendimiento de ConnectNow es dos a tres veces superior a la versión anterior. "El sistema hubiera sido mucho más complejo y dificil de desarrollar con una base de datos", dice.

Otro proyecto, MongoDB, se llama a si mismo "base de datos orientada a documentos" por su almacenamiento nativo de datos de tipo objeto.

Sólo lo necesario. Quienes impulsan NoSQL admiten que las bases de datos tienen características únicas y una reputación sólida para la integridad de datos, pero explican que todo esto puede resultar demasiado para sus necesidades.

Tomemos por ejemplo a ConnectNow que, incluso sin una base de datos, hace tres copias de los datos de la sesión del usuario mientras está online - datos que luego son borrados cuando el usuario se desconecta, dice Sena. "No necesitamos una base de datos, ya que la mejor representación de los datos ya están en memoria", dice.

Soporte de la comunidad

Por ser de código abierto, las alternativas de NoSQL no suelen tener el mismo soporte que otros proveedores tradicionales. Para la mayoría de los entusiastas de NoSQL esto no es un problema, ya que están acostumbrados a trabajar con enfoques alternativos.

Pero algunos admiten que puede causar miedo trabajar sin "un cuello para ahorcar" cuando las cosas salen mal, especialmente para los gerentes.

"Tuvimos que salir a vender la propuesta", admite Sena de Adobe. "Pero básicamente, después de ver que nuestro primer prototipo funcionaba, pudimos convencer a la alta gerencia que este era el camino correcto".

A pesar de todo el potencial, la mayoría de las organizaciones todavía no necesitan preocuparse por lo que se pierden, dice Monash.

"La mayoría de las organizaciones grandes ya tienen una forma de hacer OLTP (procesamiento de transacciones online), probablemente a través de sistemas de bases de datos. ¿Por qué cambiar?", dice. MapReduce y otros proyectos "puede ayudar a las organizaciones. Pero probablemente debería integrarse a una DBMS analítica".

Incluso Orkarsson, el organizador de NoSQL, admite que su compania, Last.fm, todavía no migró a una alternativa NoSQL, y en cambio usa bases de datos de código abierto. Por ahora, la revolución está esperando.

"Es verdad que hoy NoSQL no es muy relevante para la mayoría de las organizaciones", dice Orkarsson. "Pero esto podría cambiar en los próximos dos años".

Traducido de No to SQL? Anti-database movement gains steam.
Compartir
  • Invitado

    que hay de gemstone muchachos.<br />Saludos.

  • Invitado

    Parece que volvemos a los viejos y mucho mas eficientes archivos indexados... parecia que las db relacionales eran la panacea, aunque en la epoca que salieron funcionaran a paso de tortuga se pincharan y tuvieran muchos inconvenientes... a ver cuando se dan cuenta de lo mismo con el paradigma de objetos...

  • Invitado

    Cuente con eso que vamos a volver al pasado jejejeje

  • Invitado

    Al parecer estamos volviendo a los 70, donde cada uno hace las cosas como mejor les parece, una tecnologia carente de ESTANDARES y poco unificada no es buen sintoma en un mundo cada vez mas globalizado.

  • El artículo está bien, pero muy apologético. Creo que NoSQL es un término demasiado genérico: hay bases de datos relacionales, clave-valor, orientadas a objetos, orientadas a documentos... y meter todo lo que no es SQL en el mismo saco me parece un reduccionismo poco constructivo.<br /><br />Deberías hablar del teorema CAP, y cómo el gran problema de las bases de datos NoSQL no soportan consistencia de datos, algo muy peligroso. <br /><br />Por otra parte, se habla mucho de escalabilidad y grandes cantidades de datos, pero en el mundo de la ingeniería informática no sólo cuenta el "tenerla grande" sino en pensar en el futuro. Una aplicación empresarial nunca debería descansar sobre BBDD NoSQL.

  • El problema de los RDBMS en sitios de alta escalabilidad/disponibilidad es que muchas veces se acaba desnormalizando la BD (sharding, pérdida de restricciones de integridad, etc) y por tanto las ventajas de los RDBMS se pierden. Pero esto es una práctica desconsejada por todos, y por ello debería realizarse cuando fuese estrictamente necesaria.<br /><br />Es cierto que Oracle RAC es muy cara, pero MySQL Cluster funciona bien, MySQL tradicional con replicación es un poco farragosa en el tema de la disponibilidad... pero siempre nos queda PostgreSQL.<br /><br />Hay dos artículos muy interesantes de James Golick (http://jamesgolick.com/2010/3/30/what-does-scalable-database-mean.html , http://jamesgolick.com/2010/3/29/most-nosql-dbs-are-not-scalable.html ) ) explicando qué significa "escalabilidada" y criticando un poco los mitos que se han generado sobre NoSQL.

  • Parece que NoSQL está siendo el término de moda, y las modas no son buenas. Se supone que somos ingenieros y sabemos evaluar las necesidades de nuestros sistemas de forma rigurosa para elegir la mejor opción.<br /><br />Para ampliar, os recomiendo los artículos listados en http://sentidoweb.com/tag/nosql para aprender de forma más rigurosa sobre NoSQL.

  • Esto es una broma!!!!!!!!!!!!!!!!

  • Invitado

    [quote name="Isra"]Parece que NoSQL está siendo el término de moda, y las modas no son buenas. Se supone que somos ingenieros y sabemos evaluar las necesidades de nuestros sistemas de forma rigurosa para elegir la mejor opción.<br /><br />Para ampliar, os recomiendo los artículos listados en http://sentidoweb.com/tag/nosql para aprender de forma más rigurosa sobre NoSQL.[/quote]<br />Las modas no son buenas, pero en sistemnas de computacion las modas mandan, pasa con los lenguajes y los pradigmas, desde las ultimas 2 decadas, baste con ver los clasificados de los ultimos a#os, en lo que a pedido de desarrolladores respecta... sin embargo no me parece que NoSQL, sea una moda, me parece que es una respuesta que se espera desde hace mucho tiempo, las BD no son necesarias en muchisimos casos, hay diferentes soluciones mas eficientes en cualquier aspecto, todo depende de lo que se necesite...

  • Invitado

    al contrario en un mundo globalizado, es donde te quieren poner estandares y unificarte... en los 70 no era que cada uno hacia como le parecia, cada uno era tan eficiente como podia, las cosas funcionaban con 32KB de memoria en muchos casos...

  • Invitado

    "Casandra puede escribir hasta 50GB de datos en disco en tan sólo 0.12 milisegundos, más de 2500 veces más rápido que MySQL"
    es fisicamente imposible debido a que la velocidad de escritura de un Sata es de 160MB/s, la de un DD Solido son 650MB/s, la interpretacion de la presentacion es que cuando la BD es mayor a 50GB el promedio de escritura es de 0.12 ms.

  • Invitado

    ...con lo feliz que era yo creando ER's, pasándolos a tablas y aplicándole las formas normales de Boyce-Codd...<br /><br />snif

  • [quote name="Isra"]Parece que NoSQL está siendo el término de moda, y las modas no son buenas[/quote] <br /><br />Amigo: SQL es una moda. 8) <br /><br />[quote name="Isra"]Se supone que somos ingenieros y sabemos evaluar las necesidades de nuestros sistemas de forma rigurosa para elegir la mejor opción[/quote] <br /><br />Precisamente. Hay veces que la respuesta será SQL y en otras hay que empezar a pensar en alternativas noSQL :-) Recordemos que el modelo relacional no es tan buen amigo de los Objetos/POO

  • No estoy en contra de NoSQL, de hecho me gusta usar CouchDB. Sólo digo que hay que analizar detenidamente la situación antes de escoger SQL o NoSQL y buscar pistas que nos ayuden a elegir una u otra solución en función de la arquitectura de nuestro software. No sólo decir "usemos Cassandra porque Facebook usa Cassandra", o sólo por el aumento del rendimiento.<br /><br />Y no creo que SQL sea una moda, una moda no puede durar tantos años! Probablemente habrá casos, y muchos, en que la gente use BBDDR porque no conoce otra cosa, o porque se habla mucho de ellas, pero no creo que sea una moda.

  • Ah, y lo de la POO... es cierto que es complicado compatibilizar objetos con BD relacionales, pero no creo que haya una única respuesta a la pregunta "para mi programa OO, ¿es mejor SQL o NoSQL?". Creo que hay muchas cuestiones, como por ejemplo, la separación de capas: si quieres separar mucho las capas de lógica (tu software) y almacenamiento (BD) tendrás que hacer una "conversión" (ORM, etc). En otros escenarios es posible que quieras tener estructuras de almacenamiento más sencillas (NoSQL, archivos XML, etc). Saludos ,-)

  • mysql cluster es un mojonaco de pago... <br /><br />Sera bajo tu punto de vista todo muy "apologetico" pero pretender trabajar a escala de petabyte con bases relacionales es simplemente ridículo.<br /><br />Parece mentira que utilices tanto vocabulario y sea tan evidente que no hayas usado bases de datos en producción... Solo me cabe pensar que seas un ingeniero "de esos que no saben que es una IP.

  • Joder mira que lo sabia jajajaja<br /><br />Seguro que pasas interminables horas admirando tu maravillosa estructura de bases de datos y luego le toca al pringado de turno relacionar un puto quería durante días cuando podrías haber metido todos los datos en una tabla y hacer un puto indice... Son ganas de mirarse el ombligo porque de utilidad/ventajas no tiene nada.<br /><br />Lee menos a grandes ombligos andantes y pica mas código...

  • Invitado

    Antes de llenar líneas de comentario con tu altanería deberías aprender un poco de respeto y consideración.<br /><br />

    Seguro que pasas interminables horas admirando tu maravillosa estructura de bases de datos y luego le toca al pringado de turno relacionar un puto quería durante días cuando podrías haber metido todos los datos en una tabla y hacer un puto indice...
    <br /><br />a) No desprecies la figura del analista. Es función de un buen ingeniero estructurar la información de la mejor forma posible. Si se puede normalizar, es mejor normalizar, porque así los datos se podrán reutilizar más fácilmente.<br /><br />b) Los ataques a mi persona y a mi calidad como profesional los omito. Aquí estamos discutiendo sobre si NoSQL es mejor y para qué casos, no a ver quién la tiene más larga en términos de informática.

  • a) no desprecio ninguna figura en concreto puesto que no se cuales son las figuras existentes... Aunque me parece ridículo hacer las cosas sin saber. Hazlo, y luego habla. Hazlo y luego aconseja. Pero hablar porque si es tontería.<br /><br />b) nosql es mejor en todos los casos referentes a web. Las tablas relacionales no son necesarias en el 99% de los casos. Siempre se puede hacer mas fácil, rápido y mejor con tablas no relacionales... Sobretodo si no te pones a hacer tablas por todo dato que pueda estar duplicado y luego tengas que estar igualmente arreglando las inconsistencias y fallos que se produzcan en temas que no puedan seer hechos a través de transacciones... Ademas de mas sencillo, nosql es mas rápido. Mysql ya no tiene razón de existir mas que para los que se hartan de leer libros que otros escribieron hace siglos sin realmente, como he dicho, picar código en producción en servidores que ya no tienen 4mb de ram como en los años 80.<br /><br />Ahora vas y lo cascas.

  • Invitado

    Es la primera vez que leo algo así. 99% de los casos? No creo. Es más, creo que es al revés.<br /><br />En las bases de datos orientadas a documentos tienes la información organizada de un modo que sólo sirve a la aplicación tal cual está ahora. Por eso resulta absurdamente complicado hacer cosas como minería de datos. Pongamos por ejemplo una base de datos de personas y eventos. Tablas: personas, eventos, invitaciones. En NoSQL podrías agrupar eventos -> invitado a (-> nombre, email...), invitado b (->nombre, email...). Así ahorras las consultas relacionales y aumentas el rendimiento al obtener informes sobre los invitados de un evento X.<br /><br />Sin embargo, no es la forma óptima si quieres hacer un informe sobre los meses en los que la persona X ha asistido a más eventos.<br /><br />Y deja de decir que hablo por hablar. Llevo unos cuantos años haciendo aplicaciones web.

Cargar Más

Deja tus comentarios

Post comment as a guest

0

El nuevo Dos Ideas.

Nuevo logo, nuevo buscador, nueva portada, podcast mensual... ¡y muchas novedades más!

Más novedades en Dos Ideas

Los Comentarios.

ET
Hay algo que no me cierra.... Sprint 1...arrancan: Desarrollo, Analista Funcional y Qa, como puede a...
This is my first time i visit here. I found so many interesting stuff in your blog especially its di...
I'm really excited about it because of this post. It 's really amazing and eye-catching.
I’m glad Yahoo pointed me to it. I was able to get the know-how I was searching so badly for days no...
Eloy
muchas gracias es de mucha ayuda el texto
Federico
Estan excelente las nuevas caracteristicas de java, no entiendo por que hay que gente que no esta de...

Inspiración.

"Si tú tienes una manzana y yo tengo una manzana e intercambiamos las manzanas, entonces tanto tú como yo seguiremos teniendo una manzana cada uno. Pero si tú tienes una idea y yo tengo una idea, e intercambiamos las ideas, entonces ambos tendremos dos ideas"

Bernard Shaw