Riak link-walking como una unión?

Question

Estoy buscando almacenar imágenes en una base de datos NoSQL (< 5MB) y vincularlas a artículos en un cubo diferente. ¿Qué tipo de velocidad ofrece la función de enlace para caminar de Riak? ¿Es como un RDBMS unirse en absoluto?

Answer 1

Los enlaces no son en absoluto similares a los JOIN (que implican un producto cartesiano), pero se pueden usar para fines similares en algunos sentidos. Son muy similares a los enlaces en un documento HTML.

Con el enlace caminando, o bien comienza con una sola tecla o crea un trabajo de reducción de mapa que comienza con varias teclas. (Link-walking/transversal es en realidad un caso especial de map-reduce). Esos valores se obtienen, sus enlaces se filtran contra su especificación (depósito, etiqueta) y luego los enlaces coincidentes se pasan a la siguiente fase (o de nuevo a la cliente). Por supuesto, todo esto se hace en paralelo (a diferencia de JOIN) con alta data-localidad.

Además, map-reduce no es lento por sí mismo, simplemente no tiene un planificador de consultas sofisticado para hacer el trabajo por usted; debe pensar cómo consultará y organizará sus datos según sea necesario.

Answer 2

Piense en relaciones unidireccionales y tan rápido como consultar normalmente. No tan lento como MapReduce.

Desde: http://seancribbs.com/tech/2010/02/06/why-riak-should-power-your-next-rails-app/

La primera forma en que se ocupa de Riak esto es con enlace a pie. Cada dato almacenado en Riak puede tener relaciones unidireccionales con otros datos a través del encabezado HTTP Link del . En el ejemplo canónico , conoce la clave de una banda que ha almacenado en el cubo "artistas" (las cubetas Riak son como las tablas de la base de datos o las cubetas S3). Si ese artista está vinculado a sus álbumes, que están en virales vinculados a las pistas en los álbumes , puede encontrar todas las pistas producidas en una única solicitud. Como voy a describir en la siguiente sección, esto es mucho menos doloroso que un JOIN en SQL porque cada elemento se opera en de forma independiente, en lugar de una tabla en por vez. Esto es lo que esa consulta sería aspecto:

GET /primas/artistas/Thebeatles/álbumes, ,/pistas, _, 1 “/ bruto” es la parte superior del espacio de nombres URL , “artistas” es el cubo, "TheBeatles" es la clave del objeto fuente. Lo que sigue son las especificaciones de coincidencia cuyos enlaces a continuación, en el formato de cubo, etiqueta, mantener triples, donde los subrayados coinciden con cualquier cosa. El tercer parámetro , "mantener" dice que devuelve resultados de ese paso, lo que significa que puede recuperar los resultados de cualquier paso que desee, en cualquier combinación. No sé ustedes, pero a mí que se siente más natural que esto:

pistas SELECT * FROM pistas internas JOIN álbumes en tracks.album_id = albums.id INNER JOIN artistas en álbumes.. artist_id = artists.id WHERE artists.name = "The Beatles" La advertencia de enlaces es que son intrínsecamente unidireccionales, pero este se puede solucionar con poca dificultad en su aplicación. Sin restricciones de integridad referencial en su base de datos SQL (que ActiveRecord ha hecho doloroso en el pasado), que no tiene ninguna garantía de que su sólida de eliminación o actualización no causará una fila para quedará huérfana, de todos modos. Somos algo así como echado a perder porque ActiveRecord maneja la vinculación de las asociaciones automáticamente.

El lugar en el que la función de enlace de caminar realmente brilla es en autorreferencial y profundo transitiva relaciones (has_many pensar: a través de auto grande).Como no es necesario crear una tabla virtual mediante un JOIN y alias de las diferentes versiones de la misma tabla , puede hacer fácilmente cosas como gráficos de redes sociales (friends-of-friends-of-friends), y estructuras de datos como árboles y listas.