Diseño de tabla grande SQL

Tengo una pregunta general sobre el diseño de tablas de SQL Server 2008. Actualmente tenemos una mesa de más de 600 GB y crece a unos 3 GB al día. Esta tabla tiene las indencias apropiadas, pero se está convirtiendo en un gran problema al ejecutar consultas y solo por su tamaño. La pregunta es si debería dividir la tabla en varias tablas por año y mes (esto se ajustaría a cómo otros departamentos dividen sus grandes conjuntos de datos) o deberíamos aprovechar la partición que está integrada en SQL Server. Parece que usar la partición requeriría menos cambios de código. Por lo que leí cuando particioné, todavía solo consulta una tabla y el servidor maneja cómo obtener los datos. Si tomamos la ruta de varias tablas, tendríamos que manejar la extracción de datos de varias tablas.

"Esta tabla tiene las sangrías apropiadas pero se está convirtiendo en un gran problema al ejecutar consultas"

Particionar solo no ayuda al rendimiento de la consulta a menos que SQL Server pueda eliminar particiones al ejecutar una consulta. Su cláusula WHERE debe alinearse con la forma en que particiona. Solo obtenemos un campo para usar como campo de partición, por lo que si ese campo no está incluido en su cláusula WHERE, es probable que escanee toda la tabla a pesar de tener particiones.

"y solo por su tamaño".

Particionar puede facilitar ciertas operaciones de mantenimiento, pero aún hay cosas que no podemos hacer partición por partición. Si el mantenimiento del índice y las actualizaciones de estadísticas le causan problemas, es mejor dividir el diseño en una tabla de archivo y una tabla actualizada en vivo. Cuando necesite mover periódicamente datos de la tabla en vivo a la tabla de archivo, haga eso, reconstruya los índices con un factor de relleno del 100%, actualice las estadísticas con el escaneo completo y luego configure su grupo de archivos en solo lectura. La partición puede ayudar con las cargas de la tabla de archivo, pero la partición de la tabla en vivo no. (Estoy lanzando varios conceptos avanzados aquí como si fuera rápido y simple, pero solo estoy esbozando algunos antecedentes aquí).

"Parece que usar la partición requeriría menos cambios de código".

Más o menos, parece a primera vista, pero cuanto más te involucras, tienes opciones como vistas particionadas. Puede cambiar el nombre de la tabla existente, poner una vista en su lugar y luego puede hacer sus propios cambios en las tablas subyacentes (y agregar varias tablas) sin cambiar su aplicación.

He escrito más sobre las trampas de la partición aquí:

http://www.brentozar.com/archive/2008/06/sql-server-partitions-not-the-answer-to-everything/

Particionar de forma aislada puede ser suficiente, pero puede obtener mejores resultados si se combina con vistas particionadas y varias tablas. Depende mucho del patrón de consulta y crecimiento.

La limitación actual con la partición es que las estadísticas de columna solo se mantienen en una tabla, en lugar de en el nivel de partición. Si tiene un patrón de consulta que se beneficiaría de estadísticas más precisas, la combinación de particiones de tabla con vistas particionadas podría generar importantes beneficios de rendimiento.

Donde la naturaleza de sus datos varía de mes a mes, año a año, las vistas particionadas también pueden ayudar. Imagine un minorista que cambia sus líneas de productos continuamente, de modo que haya poca consistencia en los rangos de Product.ProductId en uso de año en año. Con una sola tabla de pedido / detalle de pedido y, por lo tanto, un solo histograma de estadísticas, las estadísticas ofrecerán poco al optimizador de consultas. Una tabla por año (Order_2010, Order_2011, OrderLine_2010, OrderLine_2011) particionada por mes y combinada con vistas particionadas (Order, OrderLine) proporcionará estadísticas más detalladas y potencialmente útiles para el optimizador.

Puede introducir el particionamiento de tablas con un esfuerzo comparativamente pequeño, así que comience allí, mida el impacto y luego evalúe si las vistas particionadas valdrían la pena el esfuerzo adicional.

Kimberly Tripp ha publicado una gran cantidad de guías y libros blancos sobre particiones que generalmente se consideran lecturas obligatorias sobre el tema. Kendra Little también tiene un buen material y una útil lista de referencia de otros artículos.

El rendimiento suele ser la razón número 1 por la que las personas buscan particionar. Personalmente, considero que las mejoras en el tiempo de recuperación son un beneficio igual o mayor con un VLDB. Tómese un tiempo para comprender la disponibilidad parcial y la restauración gradual antes de comenzar, ya que puede influir en el enfoque que adopte.

Si tiene el proceso no ideal pero no infrecuente de enviar copias de seguridad a través de la red, es posible que esté buscando un tiempo de restauración de 3 horas para sus 600 GB actuales. En un año en el que ha incumplido 1.5TB, tiene un problema.

Como dijiste, tienes dos opciones aquí:

1. Utiliza múltiples tablas
2. Utilizar particionamiento

Con 1, puede crear una VISTA que une todas esas tablas y simplemente actualizarla para incluir tablas recién creadas. Considero que esto realmente es una forma de emular la partición. Las ventajas de este método incluyen no requerir Enterprise Edition de SQL Server.

Con 2, puede alinear sus índices a sus particiones, y alinear sus particiones a un almacenamiento diferente. Después de configurar la función de partición y el esquema de partición, esto se hace por usted cuando divide o fusiona particiones. Las ventajas de este método incluyen no tener que mover manualmente los registros a una nueva tabla. Dado que la función de partición y el esquema de partición manejan esto por usted. Además, como dijiste, se necesita poco o ningún cambio de código para acceder a los datos.

Si tiene Enterprise Edition, definitivamente le daría un vistazo a la partición. A pesar de lo complejo que parece, realmente no es tan malo. Si no, la partición ni siquiera es una opción para usted.

Crear tablas particionadas

Modificación de tablas particionadas

Diseño de particiones para gestionar subconjuntos de datos

Espero que esto ayude,

Mate

Según su pregunta, parece que está almacenando datos históricos (registros) y su limitación parece provenir de la velocidad de consulta, no de los problemas de la sala de almacenamiento. Para mí la partición no ayudará.

Cuando dice que tiene índices adecuados, ¿incluye un índice en el campo de fecha? Tuve buenos resultados usando el índice en trunc (marca de tiempo, día) con Postgres. Luego debe asegurarse de que todas las consultas se seleccionen el día antes que cualquier otra manipulación. Tenga cuidado, una marca de tiempo con un campo de zona horaria no es indexable (porque se "mueve" dependiendo de la zona horaria) por lo que necesita una marca de tiempo "fija" para indexarse.