Il concetto di un indice cluster in un progetto DB è sensato quando si utilizzano SSD?

Quando si progetta uno schema di dati del server SQL e le successive query, sprocs, viste, ecc. La nozione di un indice cluster e l'ordine dei dati su disco ha senso considerare i progetti di DB realizzati esplicitamente per essere distribuiti su piattaforme SSD?

http://msdn.microsoft.com/en-us/library/aa933131(v=sql.80).aspx
"Un indice cluster determina l'ordine fisico dei dati in una tabella."

Su una piattaforma a disco fisico, la progettazione di considerarli ha senso per me come una scansione fisica dei dati per recuperare righe "sequenziali" può essere più performante di una ricerca attraverso la tabella.
Su una piattaforma SSD, tutti gli accessi in lettura ai dati utilizzano una ricerca identica. Non esiste un concetto di "ordine fisico" e le letture dei dati non sono "sequenziali", nel senso che i bit sono memorizzati sullo stesso pezzo di silicio.

Quindi, nel processo di progettazione di un database dell'applicazione, la considerazione dell'indice cluster è rilevante per questa piattaforma?

Il mio pensiero iniziale è che non è perché l'idea di "dati ordinati" non si applica all'archiviazione SSD e all'ottimizzazione di ricerca / recupero.

EDIT: So che SQL Server ne creerà uno, sto solo filosofando sul fatto che abbia senso pensarci durante la progettazione / ottimizzazione.

Ponetevi un'altra domanda: se l'intero database è in memoria e non devo mai toccare il disco, voglio archiviare i miei dati in un albero B ordinato o voglio archiviare i miei dati in un heap non ordinato?

La risposta a questa domanda dipenderà dal modello di accesso. Nella maggior parte dei casi l'accesso richiede una ricerca a riga singola (es. Ricerche) e scansioni dell'intervallo. Questi schemi di accesso richiedono un albero a B, altrimenti sono inefficienti. Alcuni altri schemi di accesso, comuni in DW e OLAP, eseguono sempre aggregati sull'intera tabella end-to-end sempre e non beneficiano delle scansioni dell'intervallo. Man mano che si approfondiscono, vengono alla luce altri requisiti, come la velocità di inserimento e allocazione in un heap rispetto a B-Tree può svolgere un ruolo importante per i grandi lavori di trasferimento ETL. Ma la maggior parte delle volte la risposta si riduce davvero a una domanda: cerchi o scansiona il range? Il numero schiacciante di volte in cui la risposta è SÌ. E quindi il numero schiacciante di volte in cui il design richiede un indice cluster.

In altre parole: solo perché è economico leggerlo dal disco in ordine casuale non implica che è possibile eliminare i propri TLB e le linee L2 in una bonanza di scansione RAM da 64 GB ...

Se si utilizza un indice cluster ben scelto, è più probabile che si ottengano tutti i dati correlati necessari in un numero inferiore di pagine di dati. Cioè, puoi conservare i dati di cui hai bisogno in meno memoria. Ciò offre un vantaggio indipendentemente dal fatto che si utilizzino dischi rotanti o SSD.

Ma hai ragione che l'altro vantaggio di un indice cluster - leggere / scrivere i dati correlati in sequenza invece che con molte ricerche su disco - non è un vantaggio significativo per SSD, dove le ricerche non sono un enorme sovraccarico di prestazioni come loro sono con dischi rotanti.

Il commento di Re @Matthew PK.

Ovviamente la posizione A nella RAM è rapida quanto la posizione B nella RAM. Non è questo il punto. Sto parlando del caso in cui tutti i dati necessari non si adattano alla RAM se i dati sono sparsi tra molte pagine. Ogni data pagina può contenere solo una piccola quantità di dati che ti interessano. Pertanto, RDBMS deve continuare a caricare ed eliminare le pagine quando accedi a A, B e altre righe. Ecco dove si ottiene la penalità per le prestazioni.

Sarebbe meglio che ogni pagina fosse piena di dati che ti interessano, nella speranza che tutte le successive richieste di riga vengano soddisfatte da pagine nella RAM. L'uso di un indice cluster è un buon modo per garantire che i dati siano raggruppati in meno pagine.

Sì, ha assolutamente senso. Stai pensando a un livello troppo basso nel tuo approccio. SQL Server (in una spiegazione molto molto semplificata) archivia i dati cluster in un'architettura B-tree. Ciò consente un rapido recupero dei dati in base ai valori della chiave di indice cluster.

Un heap (nessun indice cluster) non ha un ordine sequenziale di dati. La cosa più importante da considerare qui che è in un heap le pagine di dati non sono collegate in un elenco collegato .

Quindi la risposta è sì, ha ancora senso avere indici cluster creati su tabelle, anche su un SSD. È tutto basato sulla quantità di dati che SQL Server deve esaminare per ottenere i dati risultanti. Con una ricerca di indice cluster, è ridotto al minimo.

Riferimento: http://msdn.microsoft.com/en-us/library/ms189051.aspx