¿El concepto de un índice agrupado en un diseño de base de datos es sensato cuando se usan SSD?

Al diseñar un esquema de datos del servidor SQL y las consultas, sprocs, vistas, etc. subsiguientes, ¿tiene sentido considerar la idea de un índice agrupado y el orden de los datos en el disco para los diseños de bases de datos que se implementan explícitamente en plataformas SSD?

http://msdn.microsoft.com/en-us/library/aa933131(v=sql.80).aspx
"Un índice agrupado determina el orden físico de los datos en una tabla".

En una plataforma de disco físico, el diseño para considerarlos tiene sentido para mí, ya que un escaneo físico de los datos para recuperar filas "secuenciales" puede ser más eficaz que una búsqueda en la tabla.
En una plataforma SSD, todos los datos de acceso de lectura utilizan una búsqueda idéntica. No existe un concepto de "orden físico" y las lecturas de datos no son "secuenciales" en el sentido de que los bits se almacenan en la misma pieza de silicio.

Entonces, en el proceso de diseño de una base de datos de aplicaciones, ¿la consideración del índice agrupado es relevante para esta plataforma?

Mi pensamiento inicial es que no se debe a que la idea de "datos ordenados" no se aplica al almacenamiento SSD y la optimización de búsqueda / recuperación.

EDIT: Sé que el SQL Server va a crear uno, sólo estoy filosofando sobre si tiene sentido pensar en ello durante el diseño / optimización.

Hágase otra pregunta: si toda la base de datos está en la memoria y nunca tengo que tocar el disco, ¿quiero almacenar mis datos en un árbol B ordenado o quiero almacenar mis datos en un montón desordenado?

La respuesta a esta pregunta dependerá de su patrón de acceso. En la mayoría de los casos, su acceso requiere una búsqueda de una sola fila (es decir, búsquedas) y escaneos de rango. Estos patrones de acceso requieren un B-Tree, de lo contrario son ineficientes. Algunos otros patrones de acceso, comunes en DW y OLAP, siempre hacen agregados en toda la tabla de extremo a extremo siempre y no se benefician de los escaneos de rango. A medida que profundice, otros requisitos saldrán a la luz, como la velocidad de inserción y asignación en un montón frente a B-Tree puede desempeñar un papel para grandes trabajos de transferencia ETL. Pero la mayoría de las veces la respuesta realmente se reduce a una pregunta: ¿busca o escanea el rango? La abrumadora cantidad de veces que la respuesta es SÍ. Y, por lo tanto, la abrumadora cantidad de veces que el diseño requiere un índice agrupado.

En otras palabras: solo porque es barato leerlo desde el disco en orden aleatorio no implica que pueda tirar a la basura sus líneas TLB y L2 en una bonanza de escaneo de RAM de 64 Gb ...

Si utiliza un índice agrupado bien elegido, es más probable que obtenga todos los datos relacionados que necesita en menos páginas de datos. Es decir, puede guardar los datos que necesita en menos memoria. Esto brinda un beneficio independientemente de si usa discos giratorios o SSD.

Pero tiene razón en que el otro beneficio de un índice agrupado: leer / escribir datos relacionados secuencialmente en lugar de con muchas búsquedas de disco, no es un beneficio significativo para SSD, donde las búsquedas no son una sobrecarga de rendimiento tan grande como son con discos giratorios.

Vuelve el comentario de @Matthew PK.

Por supuesto, la ubicación A en RAM es tan rápida como la ubicación B en RAM. Ese no es el punto. Estoy hablando del caso en que todos los datos que necesita no caben en la RAM si los datos se encuentran dispersos en muchas páginas. Cualquier página dada puede contener solo una pequeña cantidad de datos que le interesan. Por lo tanto, el RDBMS debe seguir cargando y purgando páginas a medida que accede a A, B y otras filas. Ahí es donde obtienes la penalización de rendimiento.

Sería mejor que cada página esté llena de datos que le interesen, con la esperanza de que todas las solicitudes de filas posteriores se atiendan desde páginas en RAM. El uso de un índice agrupado es una buena manera de garantizar que sus datos estén agrupados en menos páginas.

Sí, absolutamente todavía tiene sentido. Estás pensando demasiado bajo en tu enfoque. SQL Server (en una explicación muy muy simplificada) almacena datos agrupados en una arquitectura de árbol B. Esto permite una recuperación rápida de datos basada en los valores de clave de índice agrupados.

Un montón (sin índice agrupado) no tiene un orden secuencial de datos. Lo más importante a considerar aquí es que, en un montón, las páginas de datos no están vinculadas en una lista vinculada .

Entonces la respuesta es sí, todavía tiene sentido tener índices agrupados creados en tablas, incluso en un SSD. Todo se basa en la cantidad de datos que SQL Server tiene que filtrar para llegar a los datos resultantes. Con una búsqueda de índice agrupado, se minimiza.

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