2010/3/21 Fernando Parra <[email protected]>
>
> 2010/2/25 Federico Brubacher <[email protected]>
> >
> > Creo que no todas los data-store no relacionales se manejen con map-reduce, 
> > creo que hay varios q usan :hashing así que el lookup seria en tiempo 
> > constante (habría q ver para una gran cantidad de objetos-hash seria mejor 
> > un árbol ?) . De cualquier manera una ventaja de las bases relacionales es 
> > que son buenas en  transacciones.
> >
> > 2010/2/25 Michel Martens <[email protected]>
> >>
> >> 2010/2/25 Fernando Parra <[email protected]>:
> >> > Se que esto no está relacionado directamente a Ruby, pero creo que es de
> >> > interés para la mayoría.
> >> > Actualmente estoy leyendo mucho sobre la movida NoSQL y opino que es un
> >> > paradigma muy necesario considerando los volúmenes de datos y las
> >> > necesidades que los sistemas de información presentan.
> >> > Ahora, me parece muy lindo el concepto, pero hay un caso que no me queda
> >> > claro de todas las explicaciones que he escuchado, y me hace sospechar 
> >> > que
> >> > por ahí las bases de datos relacionales siguen estando vigentes (dado que
> >> > hay muchos fanáticos que proponen desecharlas completamente).
> >> > El tema es el siguiente: supongamos un sistema comercial en el cual 
> >> > tendría
> >> > miles de datos en tablas maestras con información como: roles, países y
> >> > ciudades, códigos de productos, etc. Es muy probable (y sobre todo al
> >> > principio) que no se hayan realizado por ej, ventas de cierto producto, 
> >> > o no
> >> > se hayan asignado roles a ciertos usuarios, lo que se traduce en que un
> >> > registro de una tabla aún no se ha relacionado con otra al menos una vez.
> >> > En NoSQL se propicia la utilización de algoritmos Map Reduce del cual se
> >> > podría extraer de un set los datos que corresponden a valores únicos (por
> >> > ejemplo, los países que integran los usuarios de nuestro sitio), pero al
> >> > hacer esto no estaríamos tomando en cuenta todo el set posible. Nada me
> >> > suena mejor que un OUTER LEFT JOIN si estuviera utilizando SQL.
> >> > Si para solucionar esto agregáramos una colección conteniendo los datos 
> >> > de
> >> > lookup, estaríamos simulando una situación típica de una base relacional 
> >> > y
> >> > me parece que nadie lo recomendaría.
> >> > Me imagino esta situación en un sistema transaccional todo el tiempo.
> >> > Cual es la mejor aproximación???
> >> > He leído por ahí que muchos mezclan bases relacionales con no 
> >> > relacionales,
> >> > lo cual me parece correcto, por que se estaría utilizando la mejor
> >> > herramienta para cada dominio. Pero, aún así, he leído de algunos
> >> > evangelistas NoSQL que no sería una buena práctica. Entonces?
> >>
> >> Está bueno el planteo. Te parece pasarlo a código y vemos cuál sería
> >> la equivalencia? Si podés armate un ejemplo de cómo serían las tablas,
> >> el resultado que querés obtener y cómo lo obtendrías con SQL.
> >>
> >> Saludos,
> >>
> >> --
> >> Michel
>
> No hay equivalencia de RDBMS a Hash Key, Document Oriented, Big Table,
> punto. Si la base de datos no está populada, no hay forma de hacer
> consultas de lookup. Es decir, se pueden hacer lookups siempre y
> cuando esten cargados en la memoria de la aplicación, lo cual es
> sumamente embarroso. Imagínense una lista de SKUs de 50.000 unidades
> cargadas en memoria.
> La solución son las bases de datos orientadas a Graphs como Neo4J
> donde podes asociar objetos entre sí como sucede en la vida real
> (ventaja eterna de un RDBMS salvando los JOINS que son extremadamente
> costosos de ejecutar). Es una forma increíble de generar estructuras
> débiles y al mismo tiempo evitar duplicación de datos como en los
> demás casos.
> Me parece que la zona gris entre las dos tecnologías es resuelta con
> esta última. El único downside es la complejidad, pero suena
> razonable.
> _______________________________________________
> Ruby mailing list
> [email protected]
> http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar

No me queda claro cuando decís que Map-Reduce no toma en cuenta todo
el set posible. De acuerdo con Michel, un poco de código para
expresarlo sería muy bienvenido!
_______________________________________________
Ruby mailing list
[email protected]
http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar

Responder a