Progettazione di cluster: se prevedo di inserire dati in più tabelle ogni settimana, è una cattiva idea raggrupparli?
Ho alcune tabelle a cui mi unisco che penso sarebbero perfette per essere messe in un cluster. Ma mi aspetto anche di inserire dati in essi ogni settimana. Non una quantità enorme di dati, qualcosa come 5 - 20 record a settimana. La mia comprensione è che i cluster sono utili per le tabelle da cui si uniscono e da cui si seleziona, ma non così buono se si prevede di utilizzare le istruzioni DML su di essi.
La mia domanda è: quando la documentazione Oracle dice che il clustering non è efficiente da usare con le istruzioni DML, si riferiscono all'aggiornamento e all'eliminazione di centinaia di record? O anche una piccola quantità di record da inserire rientrerebbe in questa linea guida? La mia domanda è essenzialmente: la scala delle dichiarazioni DML influisce sull'efficienza del clustering? O è più una situazione binaria. Ad esempio, se aggiorno un record ogni giorno, dovrei evitare di mettere le mie tabelle in un cluster?
Risposte
Devo ancora vedere uno scenario utente del mondo reale in cui il vantaggio (risparmio di un po 'di disco o I / O o blocco dell'accesso) dell'utilizzo di un cluster invece di semplici tabelle (o IOT) con join è così significativo che vale la pena di affrontarlo.
5-20 record a settimana: non è niente. Carta e matita possono farlo.
Cordiali saluti: le tabelle del dizionario dei dati utilizzano alcuni cluster per gli identificatori. Questi identificatori non cambiano mai. Vengono inseriti, cancellati, ma mai aggiornati. In alcuni ambienti, 5-20 record vengono inseriti / eliminati in pochi secondi o minuti (a causa della creazione e rilascio dinamico di oggetti) senza causare alcun problema. Quindi 5-20 record a settimana non saranno un problema. La domanda è: vuoi davvero usare qualcosa che non viene quasi mai utilizzato, che potrebbe anche non migliorare sensibilmente le prestazioni (o addirittura peggiorare), ma richiede un'attenzione particolare.
caveat emptor
Ogni volta che hai un'idea di progettazione dello schema, esegui benchmark per (dis) dimostrare la sua utilità.
Per me, è necessario dimostrare che l'utilizzo di un progetto di schema non standard ha un vantaggio significativo prima dell'implementazione.
Per la tua quantità di dati davvero minuscola, mi aspetto che risparmi solo pochi jiffy all'anno.
Ancora una volta, esegui i benchmark.
TL; DR Quando utilizzare una tabella raggruppata? mai (salvo prova contraria).
Il clustering e il partizionamento servono a creare località di riferimento in enormi set di dati.
Il clustering memorizza tutte le righe associate a ciascun valore di chiave e, a seconda dell'RDBMS, può essere applicato tabella per tabella come indice in cui le righe sono le foglie o multi-tabella, dove vengono conservati i dati per ciascun valore di chiave in più tabelle insieme. Con il clustering, il tavolo è ancora enorme.
Il partizionamento sta mettendo il tavolo in spazi diversi, quindi si comporta come tanti piccoli tavoli. Ad esempio, negli scambi abbiamo suddiviso per giorno di negoziazione. Questo è ottimo per velocizzare le query e l'abbandono, poiché le vecchie partizioni sono quiescenti. È anche molto utile per eliminare in modo efficiente i dati e riciclare lo spazio per fornire un nuovo valore della chiave di partizione, quando si esegue il partizionamento alla data.