Passare ai contenitori sequenziali (a pettine): per quanto riguarda i dati esistenti?

Question

Abbiamo un database con oltre 500 tabelle, in cui quasi tutte le tabelle hanno un PK cluster che è di tipo di dati guid (uniqueidentifier).

Stiamo testando un passaggio da "normali" guidi "casuali" generati tramite il metodo Guid.NewGuid() di .NET ai GUID sequenziali generati tramite NHibernate guid.comb algorithm. Questo sembra funzionare bene, ma per quanto riguarda i client che hanno già milioni di righe con valori di chiavi primarie "casuali"?

• Trarranno beneficio dal fatto che i nuovi ID generati da ora in poi saranno sequenziali?
• Potrebbe/dovrebbe essere fatto qualcosa ai dati esistenti?

Grazie in anticipo per eventuali suggerimenti su questo.

Answer 1

Si potrebbe fare questo, ma non sono sicuro che vorreste. Non vedo alcun vantaggio nell'utilizzo di guai sequenziali, infatti l'uso di guids non è raccomandato come chiave primaria a meno che non siano coinvolti motivi di diffusione/replicazione. Stai usando un indice cluster?

Detto questo, se vai avanti, ti consiglio di caricare prima una tabella con i valori dell'algoritmo.

Stai per avere problemi con le chiavi esterne. Sarà necessario associare il vecchio e il nuovo guid nella tabella sopra indicata, rilasciare le chiavi esterne, eseguire un aggiornamento transazionale, quindi riapplicare le chiavi esterne.

Non penso che ne valga la pena, a meno che non si stia allontanando completamente dai guidi per dire un sistema basato su interi.

Answer 2

Dipende se le tabelle sono raggruppate nell'indice primario o in un altro indice. Ad esempio, se si creano grandi quantità di nuovi record in una tabella con un GUID PK e una data di creazione, di solito è opportuno raggruppare in base alla data di creazione per ottimizzare l'operazione di inserimento.

D'altra parte, a seconda delle query eseguite, un cluster sul GUID può essere migliore, nel qual caso l'utilizzo di GUID sequenziali può aiutare con le prestazioni dell'inserto. Direi che non è possibile dare una risposta definitiva alla tua domanda senza una conoscenza approfondita dell'uso.

Answer 3

Sono di fronte a un problema simile, penso che sarebbe possibile aggiornare i dati esistenti scrivendo un'applicazione per aggiornare le chiavi esistenti utilizzando l'algoritmo guid.comb di NHibernate. Per propagare le nuove chiavi alle tabelle delle chiavi esterne correlate, forse sarebbe possibile effettuare temporaneamente una cascata di aggiornamenti? Facendo questo attraverso il codice .NET sarebbe più lento di uno script SQL, un'altra opzione potrebbe essere quella di duplicare la logica di guid.comb in SQL, ma non è sicuro se ciò è possibile.

Se si sceglie di conservare i dati esistenti, l'utilizzo dell'algoritmo guid.comb dovrebbe migliorare le prestazioni, si verificheranno comunque divisioni delle pagine quando si verificano degli inserimenti, ma poiché i nuovi guidi sono sequenziali anziché totalmente casuali, ciò sarà almeno in qualche modo ridotto. Un'altra opzione da considerare sarebbe quella di rimuovere l'indice cluster sulla chiave primaria GUID, anche se non sono sicuro di quale impatto avranno le prestazioni di query esistenti.