He revisado algunos artículos sobre Bigtable y NOSQL. Es muy interesante que eviten las operaciones de JOIN.Operación de unión con NOSQL
Como ejemplo básico, tomemos la tabla Employee and Department y supongamos que los datos están distribuidos en varias tablas/servidores.
Solo quiero saber si los datos se distribuyen en varios servidores, ¿cómo hacemos las operaciones JOIN o UNION?
Tendría que hacer múltiples selecciones, y unir los datos manualmente en su aplicación. Consulte this SO post para obtener más información. Desde esa publicación:
Los conjuntos de datos Bigtable se pueden consultar desde servicios como AppEngine usando un lenguaje llamado GQL ("gee-kwal") que se basa en un subconjunto de SQL. Perceptiblemente ausente de GQL es cualquier tipo de comando JOIN. Debido a la naturaleza distribuida de una base de datos de Bigtable, realizar una unión entre dos tablas sería terriblemente ineficiente. En cambio, el programador tiene que implementar dicha lógica en su aplicación o diseñar su aplicación para no necesitarla.
Kaleb's right. Usted escribe código personalizado con una solución NoSQL si sus datos no encajan bien en una tienda de valores-clave. El procesamiento Map-reduce/async y las memorias caché personalizadas son comunes. Brian Aker dio una presentación muy divertida (y satírica y parcial) en el OpenSQLCamp de noviembre de 2009 http://www.youtube.com/watch?v=LhnGarRsKnA. Saltee en 40 segundos para escuchar acerca de las uniones.
+1 para el video divertido –
Cuando tiene datos extremadamente grandes, es probable que desee evitar uniones. Esto se debe a que la sobrecarga de una búsqueda de clave individual es relativamente grande (el servicio necesita averiguar qué nodo (s) consultar y consultarlos en paralelo y esperar respuestas). Por sobrecarga, quiero decir latencia, no limitación de rendimiento.
Esto hace que las uniones realmente mal, ya que es necesario hacer muchas búsquedas de claves externas, que terminarían yendo a muchos, muchos nodos diferentes (en muchos casos). Entonces querrías evitar esto como un patrón.
Si no ocurre muy a menudo, probablemente puedas recibir el golpe, pero si vas a querer hacer muchos de ellos, puede valer la pena "desnormalizar" los datos.
El tipo de cosas que se almacenan en las tiendas NoSQL suele ser bastante "anormal" en primer lugar. No es raro duplicar los mismos datos en todo tipo de lugares diferentes para facilitar las búsquedas.
Además, la mayoría de los nosql no (realmente) admiten índices secundarios, lo que significa que tiene que duplicar cosas si desea consultar por cualquier otro criterio.
Si está almacenando datos como empleados y departamentos, realmente está mejor con una base de datos convencional.
+1 bien dicho ... – gbn
Este enlace fue útil cuando intentaba entender esto: http://www.allbuttonspressed.com/blog/django/2010/09/JOINs-via- denormalization-for-NoSQL-coders-Part-1-Intro –
Estoy de acuerdo con algunos de los comentarios SI desea unir DOS conjuntos de datos MUY GRANDES. Pero en noSQL, también puede usar playOrm y tener 1 billón de intercambios, pero tiene mil millones de particiones y luego puede unir una a las particiones con otra cosa. Este caso de uso es realmente muy amplio.
Teníamos un cliente que tenía esto y dividimos las operaciones por la Cuenta para que pudiéramos obtener la partición para la cuenta # 4567 y consultar en esa partición y unirla con otra tabla pequeña u otra partición de tablas grandes.
playOrm hace que las uniones sean posibles con un lenguaje JQL/HQL simple y una herramienta de consulta ad-hoc próximamente disponible.
después, Dean
Creo que esta no es una buena opción para usuarios corporativos. La herramienta/lenguaje está desarrollado por usted mismo (a juzgar por el repositorio de Github) no actualizado en más de 3 años ... La industria dice "no" donde usted mismo dice "sí". Si sigue este consejo, tenga cuidado. –
La industria también bajó EJB2 mientras que pasé por una ruta completamente diferente usando hibernación. Finalmente, la industria se dio cuenta de que EJB2 apesta. No basar las cosas en la industria y lo que "la gente" dice es mi opinión (me alegro de no haberlo hecho). Haga sus propios juicios. Gracias a dios EJB3 copiado Hibernate eventualmente (más o menos). Ese proyecto terminó cuando cassandra cambió su protocolo y no tuve tiempo de actualizarlo. Algún día podría funcionar muy bien para algunos proyectos no SQL en los que estuve. En twitter, hacemos cosas similares estos días pero de forma manual (y es más trabajo :(). –
EJB2 (era) no solo persistencia de beans ... también, EJB3 e Hibernate realmente se "fusionaron" cuando JPA especificó una interfaz que Hibernate implementado - King incluso ayudó con JPA. De todos modos, elegiste Hibernate, que era una buena opción, no es un proyecto de una persona abandonado como el que has creado. No digo que tu proyecto contenga código o prácticas incorrectas, sino una. debe tener un principio general para buscar en otra parte la solución de dependencias de software –
Sé que esto es una cuestión de edad, pero es un buen resultado en Google, por lo que podría valer la pena el necro decir que Couchbase, mientras que ser una base de datos "NoSQL", tiene una implementación SQL llamada N1QL, que tiene joins. Y pueden ser bastante performant en ciertas circunstancias.
¿Desea una operación * SQL * JOIN o UNION en un producto llamado * NoSQL *? – gbn
Simple, usa playOrm y une particiones (las particiones suelen tener menos de 1 millón de filas pero la tabla puede ser infinita) y funciona bien. –