Base de datos de SQL Server en un SSD: ¿alguna ventaja para un archivo separado para cada tabla?

19

Estoy creando una base de datos en la que habrá alrededor de 30 tablas, con cada tabla que contenga decenas de millones de filas y cada tabla que contenga una sola columna importante y una columna de clave primaria / externa con el fin de maximizar la eficiencia de la consulta frente a la pesada actualizaciones e inserciones y hacer un uso intensivo de los índices agrupados. Dos de las tablas contendrán datos textuales de longitud variable, una de ellas con cientos de millones de filas, pero el resto contendrá solo datos numéricos.

Como realmente quiero exprimir hasta la última gota de rendimiento del hardware que tengo disponible (aproximadamente 64 GB de RAM, un SSD muy rápido y 16 núcleos), estaba pensando en permitir que cada tabla tenga su propio archivo para que no importa si Me estoy uniendo en 2, 3, 4, 5 o más tablas, cada tabla siempre se leerá usando un hilo separado y la estructura de cada archivo estará estrechamente alineada con el contenido de la tabla, lo que con suerte minimizaría la fragmentación y la haría más rápida. para que SQL Server agregue al contenido de cualquier tabla dada.

Una advertencia, estoy atascado en SQL Server 2008 R2 Web Edition . Lo que significa que no puedo usar el particionamiento horizontal automático, lo que lo descarta como una mejora del rendimiento.

¿Usar un archivo por tabla realmente maximizará el rendimiento, o estoy pasando por alto las características integradas del motor de SQL Server que lo harían redundante?

Segundo, si usar un archivo por tabla es ventajoso, ¿por qué create tablesolo me da la opción de asignar la tabla a un grupo de archivos y no a un archivo lógico específico? Esto requeriría que creara un grupo de archivos separado para cada archivo en mi escenario, lo que me sugiere que quizás SQL Server no está imaginando las ventajas que supongo que vendrían de hacer lo que estoy proponiendo.

sql-server sql-server-2008 database-design sql-server-2008-r2 Nathan Ridley
fuente

Respuestas:

18

Estaba pensando en permitir que cada tabla tenga su propio archivo para que no importa si me uno a 2, 3, 4, 5 o más tablas, cada tabla siempre se leerá usando un hilo separado y la estructura de cada archivo estar estrechamente alineado con el contenido de la tabla, lo que con suerte minimizaría la fragmentación y aceleraría la incorporación de SQL Server al contenido de cualquier tabla

¿Qué diablos estás hablando? No estoy seguro de dónde obtuvo su información, pero ciertamente debe descartar esa fuente. Nada de lo que asume aquí es realmente correcto.

Si desea leer una buena discusión sobre el rendimiento de SSD para SQL Server, existen varias series de blogs. Como de costumbre, la de Paul Randal es la más leída:

Brent también tiene una buena presentación sobre el tema: SQL en SSD: Hot and Crazy Love y hay más por ahí.

Al revisar todas estas presentaciones, notará rápidamente que todas se centran en las escrituras, ya que aquí es donde entra en juego el rendimiento de los SSD. La redacción de su publicación se trata casi por completo de lecturas, que es un tema diferente. Si las lecturas son su punto débil, entonces debería estar hablando de RAM, no de SSD, y de estrategias adecuadas de indexación y consulta.

Remus Rusanu
fuente
1
Sí, me han dado información incorrecta en algún lugar a lo largo de la línea, pero como comenté la respuesta de Stuart, hice la pregunta para asegurarme de no basar mis decisiones en información incorrecta. Gracias por los enlaces, los revisaré.
17

Mi primera sugerencia sería no hacer suposiciones sobre el rendimiento sin realizar pruebas de carga en ambas configuraciones.

Supongo que al haber visto tales configuraciones (que tienen sentido en el papel) en el pasado sería que tener cada tabla en un archivo separado no tendría un impacto positivo medible para el rendimiento ... y que la complejidad adicional compensaría cualquier ganancia de rendimiento incluso si fueran medibles.

Por último, cuando se trata de exprimir cada caída de rendimiento de un servidor SQL, lo remito al siguiente cuadro (proporcionado por mi Microsoft):

ingrese la descripción de la imagen aquí

Cualquier optimización potencial que se pueda hacer desde la perspectiva de una aplicación eclipsa fácilmente cualquier posible optimización a nivel de configuración de hardware / base de datos ... así que concentre su atención de manera apropiada.

Michael Fredrickson
fuente
Por supuesto. Sin embargo, en mi caso, he estado optimizando todo el sistema tanto como puedo y el principal cuello de botella que tengo en este momento es una velocidad de consulta muy rápida frente a las frecuentes actualizaciones, eliminaciones e inserciones. Como voy a aprovechar SQL Server para resolver este problema, quiero asegurarme de darle la mejor oportunidad absoluta de operar lo más rápido posible en mis datos.
@NathanRidley Ok, entendido ... Creo que la respuesta real a menos que alguien tenga un recurso que diga "nunca hagas esto", es que el mejor curso de acción sería comparar dos configuraciones con tu carga de trabajo típica y ver si hay una diferencia medible.
Michael Fredrickson
4

Como otros han señalado, no hay un beneficio directo de un archivo por tabla; Aquí hay una gran sinopsis de Steve Jones sobre cómo se originó este mito: http://www.sqlservercentral.com/blogs/steve_jones/2009/10/13/sql-server-legend-data-files-and-threads/

También es posible que desee investigar una vista particionada que creo que es compatible con 2008 Web Edition. Hay algunos trucos para codificar en una vista particionada, pero puede imitar muchas de las funciones de las tablas particionadas con relativa facilidad.

Stuart Ainsworth
fuente
2

Creo que los archivos separados para cada tabla no aportarían ningún beneficio de rendimiento. Los índices correctos podrían tener un aumento potencial de rendimiento (lectura de disco) en el servidor de la base de datos.

¿SQL Server 2008 R2 admite la compresión? Si es así, enciéndelo.

Corrígeme si me equivoco.

Peter Kiss
fuente
¿Podría explicar por qué no habría beneficio de rendimiento? Por lo menos, explique por qué este es el caso cuando archivos separados permiten que SQL Server use múltiples hilos para leer.
Si coloca toda la tabla en su propio grupo de archivos pero en la misma unidad, el rendimiento será igual antes de la partición. Pero si está separando algunas tablas en sus grupos de archivos en un disco diferente más rápido, tendrá un beneficio de rendimiento. También puede particionar, por ejemplo, por año si tiene muchos datos que dependen del año. Con esta técnica, puede mantener sus datos más utilizados en un disco más rápido que los anteriores. También puede separar índices, pero solo si los coloca en un nuevo disco físico tendrá algún beneficio de rendimiento.
Tienes razón sobre los hilos paralelos (tablas / archivos), pero creo que hasta que tengas solo un disco físico, la ganancia de rendimiento será pequeña.
Y le recomiendo que obtenga una matriz RAID HDD más fuerte para la base de datos porque el SSD morirá pronto.