2012-11-29 11 views
5

Ho un'idea che chiamare una query di query è più veloce di una query dal database, perché il rallentamento è nella comunicazione tra cf e il db. È vero.CF - QoQ vs Query

Ciò significa che una QoQ all'interno di un ciclo è accettabile, mentre una query all'interno di un ciclo non lo è.

risposta

13

I DBMS completi sono altamente ottimizzati per l'elaborazione di query [appropriatamente scritte] e su una rete moderna il sovraccarico non sarà enorme.

QoQ viene eseguito utilizzando un database incorporato, che può essere o meno ottimizzato, a seconda del tipo di query eseguita.

Quindi, se il database si trova su una macchina diversa, attraverso una rete lenta, in alcune situazioni la QQ potrebbe essere meno lenta. Se stai colpendo il database, preferisci che tutto venga elaborato in modo appropriato lì, in una richiesta, ed evita i round trip e la rielaborazione in un ciclo.

Ovviamente, un grande vantaggio di QoQ è che è possibile utilizzarlo per elaborare dati che non provengono da un database, ad esempio i risultati di cfdirectory o un file CSV che è stato convertito in una query.


ColdFusion esegue QoQ analizzando manualmente l'SQL e quindi eseguendo il loop del recordset. Ciò lo rende efficiente per operazioni semplici, come un join a due tabelle con chiavi corrispondenti, ma meno efficiente per combinazioni complesse (dove l'unione utilizza più colonne e/o non è un confronto diretto a = b). (Brief info here.)

Railo utilizza H2. H2 afferma di essere veloce e il loro sito web offre alcuni speed comparisons che suggeriscono che è più veloce di Derby e MySQL - ma ovviamente sarebbe meglio cercare test indipendenti di terze parti, senza contare che questi test non sono garanzia di prestazioni QoQ (che sospetto non avrà indici, per esempio).


In generale: non fanno alcuna decisione difficile senza prima fare il test delle prestazioni per stabilire che è effettivamente necessario per migliorare le prestazioni, e di essere in grado di determinare oggettivamente quale metodo è effettivamente più veloce.

+0

Il derby non viene utilizzato nelle funzioni QoQ di ACF. Derby è incluso con esso per avere un facile accesso a un database low-overhead. La QoQ di ACF utilizza qualcosa di più simile all'analisi e al looping manuale SQL per modificare i recordset. –

+2

Eww. :/Ci sono ulteriori informazioni su cui puoi fare riferimento, quindi posso aggiornare la risposta di conseguenza? –

+0

Non ho risorse esterne, a parte le conversazioni che ho avuto con il personale Adobe e anni di esperienza: P –

3

Ho scoperto che l'utilizzo di una q di q può essere MOLTO più veloce rispetto a quello di una query.

Ad esempio, uso religiosamente QoQ sui rapporti di vendita. Ho un rapporto sulle vendite che verrebbe estratto per un intervallo di date del primo trimestre, che potrebbe mostrare i dati delle vendite per agente di vendita e potrebbe anche mostrare i dati relativi alle vendite per prodotto venduto.

Nel mio DB, le stesse tabelle/campi sarebbero stati utilizzati per entrambe le sezioni che verrebbero visualizzate nello stesso report.

Interrogo la tabella principale per i miei dati in base all'intervallo di date e quindi interrogo quei risultati per creare ciascuna sezione del mio rapporto.

Ho trovato questo metodo più veloce su entrambi i server con DB locale e remoto.

+1

Hai avuto un'analisi DBA del tuo database e delle tue query? È probabile che un report di vendita trimestrale abbia molti dati e che sia possibile ottimizzare un DBMS. –

+0

Ho avuto risultati simili. A volte i database sono lenti per qualsiasi numero di ragioni. A volte vuoi unirti o unire le tue query in CF. A volte il QoQ è molto più veloce. Grazie Steve. –

4

Dipende dalle funzionalità della macchina Coldfusion rispetto al server del database e dal problema che si sta tentando di risolvere.

QofQ sarà in genere molto veloce per i set di dati di piccole dimensioni perché tutto accade nella memoria del server.Tuttavia, se si tenta di utilizzare QofQ su un set di dati di grandi dimensioni, il server inizierà a presentare problemi a causa del sovraccarico legato alla conservazione e all'elaborazione dei dati in memoria.

Le query di database generalmente superano QofQ su dataset di grandi dimensioni perché è ciò per cui sono progettate per. I database sono in grado di elaborare grandi quantità di dati molto velocemente. Usali per quello.

Se state pensando di recuperare un grande set di risultati dal database e analizzarlo con QofQ, probabilmente è il modo sbagliato di farlo. Fai in modo che il database riduca i risultati per te. Se stai chiedendo frequentemente al server del database queste informazioni, memorizzalo nel tuo server.

Ricordare che questo è tutto soggettivo e dipenderà molto dal problema specifico, dal carico, dal database e dalle capacità del server.

3

tempi di utilizzare QofQ

  • Quando si hanno due origini dati e per vari motivi è possibile utilizzare i server collegati
  • Quando i dati è disponibile in via WDDX o JSON e devi fare un join
  • quando è pratico per memorizzare i dati in una query nella cache e fare QofQ contro la query nella cache
  • quando si deve unire il risultato di una serviziScarica l'elenco() contro una base di dati

tempi non utilizzare QofQ

  • Quando è possibile caricare i dati in una struct invece
  • Quando si fa a fare un massiccio numero di iterazioni
  • Quando quella di insiemi di dati di origine è molto grande
  • Quando avete bisogno di fare una sinistra, a destra, o outer join

per maggiori dettagli vedi

http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WSc3ff6d0ea77859461172e0811cbec0e4fd-7ff0.html

questo è per CF 9 ma QofQ è stato circa lo stesso dal CF 6

+0

ah sì, ho trascurato di dire che il mio Q sta usando un join, che gioca un ruolo importante – Daniel

+0

Puoi fare inner join –

+0

Ottima lista, ben dichiarata! –

0

Amico! Utilizzato solo nella cache.

Problemi correlati