Ho esaminato alcuni articoli riguardanti Bigtable e NOSQL. È molto interessante che evitino le operazioni JOIN.Operazione di join con NOSQL
Come esempio di base, prendiamo la tabella Dipendente e Dipartimento e assumiamo che i dati siano distribuiti su più tabelle/server.
Voglio solo sapere, se i dati sono distribuiti su più server, come facciamo le operazioni JOIN o UNION?
È necessario eseguire più selezioni e unire i dati manualmente nella propria applicazione. Vedere this SO post per ulteriori informazioni. Da quel post:
dataset Bigtable possono essere interrogati da servizi come AppEngine che utilizzano un linguaggio chiamato GQL ("Gee-KWAL") che è un basato su un sottoinsieme di SQL. Manca in modo evidente da GQL qualsiasi tipo di comando JOIN. A causa della natura distribuita di un database Bigtable, l'esecuzione di un join tra due tabelle sarebbe terribilmente inefficiente. Invece, il programmatore deve implementare tale logica nella sua applicazione, o progettare la sua applicazione in modo da non averne bisogno.
Kaleb ha ragione. Scrivi un codice personalizzato con una soluzione NoSQL se i tuoi dati non si adattano bene a un archivio di valori-chiave. Le operazioni di riduzione mappa/asincrona e cache di visualizzazione personalizzate sono comuni. Brian Aker ha dato una presentazione molto divertente (e satirica e parziale) al Nov 2009 OpenSQLCamp http://www.youtube.com/watch?v=LhnGarRsKnA. Salta in 40 secondi per ascoltare i join.
+1 per il video divertente –
Quando si dispone di dati estremamente grandi, è consigliabile evitare i join. Ciò è dovuto al fatto che il sovraccarico di una ricerca di chiavi individuali è relativamente ampio (il servizio deve determinare quali nodi interrogare e interrogarli in parallelo e attendere le risposte). Per overhead, intendo latenza, non limitazione del throughput.
Questo rende i join estremamente efficaci, in quanto è necessario eseguire molte ricerche di chiavi esterne, che finirebbero per raggiungere molti, molti nodi diversi (in molti casi). Quindi vorresti evitare questo come schema.
Se non succede molto spesso, è probabile che tu prenda il colpo, ma se vuoi farne molti, potrebbe valere la pena "denormalizzare" i dati.
Il tipo di elementi memorizzati negli archivi NoSQL è in genere piuttosto "anormale". Non è raro duplicare gli stessi dati in tutti i tipi di luoghi diversi per semplificare le ricerche.
Inoltre la maggior parte di nosql non supporta (davvero) indici secondari, il che significa che è necessario duplicare elementi se si desidera eseguire una query in base a qualsiasi altro criterio.
Se si memorizzano dati come dipendenti e reparti, si sta davvero meglio con un database convenzionale.
+1 detto bene ... – gbn
Questo collegamento è stato utile quando stavo cercando di capire questo: http://www.allbuttonspressed.com/blog/django/2010/09/JOINs-via- denormalization-for-NoSQL-coders-Part-1-Intro –
Sono d'accordo con alcuni dei commenti SE si desidera unire DUE set di dati MOLTO GRANDI. Ma in noSQL, puoi anche usare playOrm e avere 1 trilione di scambi ma avere 1 miliardo di partizioni e quindi puoi unirti a una delle partizioni con qualcos'altro. Questo caso d'uso è davvero molto diffuso in realtà.
Abbiamo avuto un cliente che ha avuto questo e partizionata i mestieri dal conto, in modo siamo riusciti a ottenere la partizione per conto # 4567 e query in quella partizione e unirsi con un altro piccolo tavolo o in un altro grande partizione tabelle.
playOrm sta rendendo possibile l'unione con un linguaggio JQL/HQL semplice e uno strumento di query ad-hoc che verrà presto.
tardi, Dean
Penso che questa non sia una buona scelta per gli utenti aziendali. Lo strumento/linguaggio è sviluppato da te, (a giudicare dal repository Github) non aggiornato in 3+ anni ... L'industria dice "no" dove tu stesso dici "sì". Se segui questo consiglio, sii cauto. –
Anche l'industria è andata giù con EJB2, mentre ho percorso un percorso completamente diverso utilizzando l'ibernazione. Alla fine l'industria ha realizzato EJB2 fa schifo. Non basare le cose sul settore e ciò che la gente dice è la mia opinione (sono contento di non averlo fatto). Fai i tuoi giudizi. Grazie a dio EJB3 copiato alla fine Hibernate (sorta di). Quel progetto si è concluso una volta che cassandra ha cambiato il loro protocollo e non ho avuto il tempo di aggiornarlo. Un giorno potrei averlo trovato davvero molto bene per alcuni progetti noSQL in cui mi trovavo. Su Twitter, facciamo cose simili in questi giorni ma manualmente (ed è più lavoro :(). –
EJB2 (was) non solo i bean di persistenza ... anche, EJB3 e Hibernate in realtà si "uniscono" quando JPA ha specificato un'interfaccia che Hibernate implementato - King ha persino aiutato con JPA.In ogni caso, hai scelto Hibernate che è stata una buona scelta, non è un progetto abbandonato in 1 persona come quello che hai creato. Non sto dicendo che il tuo progetto contiene codice o pratiche errate, ma uno dovrebbe avere un principio generale da cercare altrove per risolvere le dipendenze del software –
So che questa è una vecchia questione, ma è un buon risultato su Google, quindi potrebbe essere la pena il necro dire che Couchbase, pur essendo un database "NoSQL", ce l'ha un'implementazione SQL denominata N1QL, che ha joins. E possono essere abbastanza performant in determinate circostanze.
Si desidera un'operazione * SQL * JOIN o UNION in un prodotto denominato * NoSQL *? – gbn
Semplice, usate playOrm e unite le partizioni (le partizioni di solito sono meno di 1 milione di righe ma la tabella può essere infinita) e funziona bene. –