Accesso efficiente al database per i dati correlati

0

Come esempio per questa domanda, considera un sistema di gestione dei contenuti che abbia una tabella del database del contenuto che contiene cose come il titolo e l'ubicazione della pagina, nonché il contenuto stesso che potrebbe essere una grande quantità di testo. Esiste una seconda tabella di database con i dettagli delle risorse (come immagini e file) associate a un elemento di contenuto. Ogni pagina nel sistema di gestione dei contenuti può avere uno o più elementi di contenuto, ciascuno con le proprie risorse.

Al momento sto recuperando un elenco di elementi di contenuto e quindi per ogni elemento di contenuto facendo una seconda query per recuperare l'elenco delle risorse correlate. In una pagina con 10 elementi di contenuto, ciò significa 11 query.

Potrei fare un join e recuperare tutto il contenuto e le risorse correlate in una query, ma mi interessa che dove ci sono più risorse per un elemento di contenuto, l'elemento di contenuto sarà duplicato e, poiché l'elemento di contenuto potrebbe essere grande, questo potrebbe essere molto inefficiente con così tanti dati duplicati.

Un'altra opzione è quella di avere una stored procedure che restituisce due recordset. Il primo recordset contiene il contenuto e il secondo recordset contiene le risorse correlate per tutti gli elementi di contenuto nel primo recordset, che viene separato dal server di ricezione.

Quindi la domanda è in generale quale è il modo più efficace per recuperare i dati in questa situazione?

So che il test delle prestazioni è spesso la risposta, ma per questa domanda stavo cercando consigli o alternative di tipo best practice a cui non avrei pensato.

    
posta johna 22.10.2014 - 01:21
fonte

2 risposte

1

"Non preoccuparti, sii felice". Praticamente qualsiasi approccio con questo problema avrà prestazioni adeguate per CMS di piccole e medie dimensioni.

Immersioni

Hai davvero bisogno di interrogare per ogni oggetto di contenuto? CMS come WordPress spesso memorizzano le loro pagine in formato HTML. Le pagine possono fare riferimento a immagini, audio, video e altri contenuti multimediali, ma solitamente lo fanno dal codice HTML , il che significa che quando si visualizza la pagina, non è mai necessario interrogare i riferimenti associati.

Nel caso ingenuo, gli elementi di contenuto vengono semplicemente caricati, in base a richieste HTTP indipendenti, dal file system locale. Nelle configurazioni più sofisticate, i contenuti multimediali vengono caricati da un server di contenuto "statico" separato o (meglio ancora), una rete di distribuzione dei contenuti .

Probabilmente ogni server web sul pianeta ha funzionalità o componenti aggiuntivi per supportare questo tipo di "servizio diviso" e server più orientati alle prestazioni come nginx supportano con entusiasmo questo modello (insieme a una vasta esperienza sul campo che viene implementata insieme ad altri acceleratori come i server di cache come Squid e Varnish .

Quando si modifica una pagina, c'è una maggiore probabilità che si vorrebbe o è necessario interrogare tutto il contenuto associato. Questo è l'unico caso in cui l'interrogazione di più volte potrebbe avere più senso. Tuttavia, questo è molto più probabile che si traduca in 2 query di 11 - una per la pagina, e quindi una query omnibus che restituisce 10 risultati a una query per tutto il contenuto associato.

Esistono diversi schemi per ottenere questo risultato in SQL, inclusa la memorizzazione di un elenco di ID di contenuto in ogni pagina, l'archiviazione dell'elemento di pagina associato in ogni elemento di contenuto o l'id di pagina per la tabella di conversione di id di contenuto . Tutte queste opzioni sono utilizzate in pratica in un CMS o in un altro. I database relazionali / SQL moderni saranno perfettamente performanti eseguendo occasionalmente tali query. Infatti, mentre 11 accessi su ogni caricamento di pagina potrebbero essere onerosi, fare 11 query su ogni modifica di pagina (il caso peggiore possibile) probabilmente non sarà un grosso problema. Con quale frequenza vengono eseguiti gli aggiornamenti? Non molto spesso, anche in CMS di migliaia o decine di migliaia di voci. Se stai pianificando CMS (multi-million o multi-billon-item), potremmo parlare di indicizzazione e ottimizzazione speciali, ma per sistemi di produzione anche piuttosto grandi, 2 query o anche 11 query per modifica non stanno andando "rompere la banca".

E la realtà è che, anche nei CMS che cercano di mantenere un collegamento in-the-database tra pagine e elementi di contenuto, i collegamenti sono solitamente incompleti. I collegamenti HTML a risorse esterne sono così comuni e così poche organizzazioni di utenti sono veramente disciplinate sul fatto di mantenere tutti i collegamenti dei contenuti completamente descritti nel database. Quindi, anche in quei "casi peggiori", il numero di elementi di contenuto associati al database è inferiore a quello che pensi.

    
risposta data 22.10.2014 - 03:04
fonte
0

Per serie di informazioni correlate come questa è preferibile una singola chiamata "jumbo" al server DB. Sebbene i dati totali restituiti siano gli stessi di 11 chiamate individuali, tutti i pacchetti di rete, la configurazione delle connessioni e la gestione dei blocchi si sommano nel tempo.

    
risposta data 22.10.2014 - 04:31
fonte

Leggi altre domande sui tag