¿Cuál es la mejor manera de particionar tablas grandes en SQL Server?

Question

En un proyecto reciente, el "líder" el desarrollador diseñó un esquema de base de datos donde " más grande " las tablas se dividirían en dos bases de datos separadas con una vista en la base de datos principal que uniría las dos tablas de bases de datos separadas. La base de datos principal es de lo que se sacó la aplicación, por lo que estas tablas se veían y se sentían como tablas normales (excepto algunas cosas extrañas relacionadas con la actualización). Esto parecía un enorme problema de rendimiento. Vemos problemas con el rendimiento en estas mesas, pero nada que lo haga cambiar de opinión sobre su diseño. Solo me pregunto cuál es la mejor manera de hacer esto, o si vale la pena hacerlo.

Answer 1

No creo que realmente vaya a ganar nada al dividir la tabla en varias bases de datos en un solo servidor. Todo lo que esencialmente ha hecho allí es aumentar la sobrecarga al trabajar con la "tabla". en primer lugar al tener varias instancias (es decir, abrir en dos bases de datos diferentes) en una sola instancia de SQL Server.

¿Qué tamaño de conjunto de datos tiene? Tengo un cliente con una tabla de 6 millones de filas en SQL Server que contiene 2 años de datos de ventas. Lo usan transaccionalmente y para informar sin problemas de velocidad notables.

Ajustar los índices y elegir el índice agrupado correcto es crucial para el rendimiento, por supuesto.

Si su conjunto de datos es realmente grande y está buscando particionar, obtendrá más por su dinero al dividir la tabla en servidores físicos.

Answer 2

La partición no es algo que se debe emprender a la ligera, ya que puede haber muchas implicaciones sutiles de rendimiento.

Mi primera pregunta es ¿se refiere simplemente a colocar objetos de tabla más grandes en grupos de archivos separados (en ejes separados) o se refiere a la partición de datos dentro de un objeto de tabla?

Sospecho que la situación descrita es un intento de tener el almacenamiento físico de ciertas tablas grandes en diferentes ejes del resto de las tablas. En este caso, agregar la sobrecarga adicional de bases de datos separadas, perder la capacidad de imponer integridad referencial en las bases de datos y las implicaciones de seguridad de habilitar el encadenamiento de propiedad entre bases de datos no proporciona ningún beneficio sobre el uso de múltiples grupos de archivos dentro de una sola base de datos. Si, como es muy posible, las bases de datos separadas a las que hace referencia en su pregunta ni siquiera se almacenan en husos separados, sino que se almacenan en el mismo husillo, entonces niega incluso el ligero beneficio de rendimiento que podría haber obtenido al separar físicamente la actividad de su disco y no he recibido absolutamente ningún beneficio.

Sugeriría que, en lugar de utilizar bases de datos adicionales para contener tablas grandes, consulte el tema del Grupo de archivos en los Libros en pantalla de SQL Server o para una revisión rápida, consulte artículo:

Si está interesado en la partición de datos (incluida la partición en múltiples grupos de archivos), le recomiendo leer los artículos de Kimberly Tripp, quien hizo una excelente presentación en el momento en que salió SQL Server 2005 sobre las mejoras disponibles allí. Un buen lugar para comenzar es este documento técnico

Answer 3

¿Qué versión de SQL Server está utilizando? SQL Server 2005 tiene tablas particionadas, pero en 2000 (o 7.0) necesitaba usar vistas de partición.

Además, ¿cuál fue el razonamiento para colocar las particiones de la tabla en una base de datos separada?

Cuando tuve que particionar tablas en el pasado (antes de 2005), generalmente es por una columna de fecha o algo similar, con una vista sobre las distintas particiones. Books Online tiene una sección que habla sobre cómo hacer esto y todas las reglas que lo rodean. Debe seguir las reglas para que funcione como se supone que debe funcionar.

La clave para recordar es que su columna de particionamiento debe ser parte de la clave primaria y desea intentar usar siempre esa columna en cualquier acceso contra la tabla para que el optimizador pueda ignorar las particiones que no deberían verse afectadas por la consulta.

Buscar " tabla particionada " en MSDN y debería poder encontrar un tutorial más completo para las tablas particionadas de SQL Server 2005, así como consejos sobre cómo configurarlas para obtener el máximo rendimiento.

Answer 4

¿Está preguntando sobre las mejores prácticas en términos de diseño de bases de datos, o está convenciendo a su líder para que cambie de opinión? :)

En términos de diseño ... En los viejos tiempos, la partición vertical a veces era necesaria para evitar las limitaciones del motor de la base de datos, donde el número de columnas en una tabla era un límite difícil, como 255 columnas. En la actualidad, los principales beneficios son puramente para el rendimiento: colocar columnas o blobs poco utilizados en una matriz de discos separada. Pero si regularmente está sacando cosas de ambas tablas, probablemente será una pérdida. Parece que su cliente potencial está sufriendo un caso de optimización prematura.

En términos de decir que su liderazgo está mal ... eso requiere diplomacia. Si es consciente de los murmullos de descontento en términos de rendimiento, un punto de referencia es probablemente la mejor manera de mostrar la diferencia.

Cree una nueva tabla física en algún lugar con 'crear tabla t1 como select * from view1' y luego ejecute un lote largo con la tabla dividida verticalmente y su nueva tabla. Si es tan malo como dices, la diferencia debería ser evidente.

Pero esto también puede ser una optimización prematura. Descubra lo que piensan los usuarios finales sobre el rendimiento. Si el rendimiento es lo suficientemente bueno, para alguna definición de bueno, entonces no arregles lo que no está roto.

Answer 5

Existe un beneficio definitivo para el particionamiento de tablas (independientemente de si se trata de grupos / discos iguales o diferentes). Si la columna de partición se selecciona correctamente, se dará cuenta de que sus consultas solo afectarán a la partición requerida. Así que imagínese si tiene 100 millones de registros (he particionado tablas mucho más grandes que eso, alrededor de más de 20 mil millones de filas) y si, en su mayor parte, más del 70% de su acceso a datos es solo una determinada categoría o línea de tiempo o tipo de datos, entonces ayuda a mantener los datos más accedidos en una partición separada. Además, puede alinear la partición con grupos de archivos separados con varios tipos de discos (SATA, canal de fibra, SSD) para que los datos más accedidos / ocupados se encuentren en el almacenamiento más rápido y los menos / raramente accedidos estén virtualmente en discos más lentos.

Aunque, en SQL Server, la capacidad de particionamiento es limitada, a diferencia de Oracle. Puede elegir solo una columna para particionar (incluso en SQL 2008). Por lo tanto, debe elegir una columna sabiamente donde esa columna también sea parte de la mayoría de sus consultas frecuentes. En su mayor parte, a las personas les resulta fácil elegir dividir por una columna de fecha. Sin embargo, aunque parece lógico particionar de esa manera, si sus consultas no tienen esa columna como parte de la condición, no obtendrá suficientes beneficios de la partición (en otras palabras, su consulta afectará a toda la partición independientemente).

Es mucho más fácil particionar para bases de datos de almacenamiento de datos / minería de datos que OLTP ya que la mayoría de las consultas de bases de datos DW están limitadas por período de tiempo.

Es por eso que en estos días, debido al volumen de datos que manejan las bases de datos, es aconsejable diseñar la aplicación de tal manera que alguna consulta esté limitada por algún grupo más amplio, como el tiempo, la ubicación geográfica o tal que cuando tales columnas son elegidos para particionar, obtendrá los máximos beneficios

Answer 6

No estaría de acuerdo con el supuesto de que no se puede ganar nada con la partición.

Si los datos de la partición están física y lógicamente alineados, entonces el IO potencial de las consultas debería reducirse drásticamente.

Por ejemplo, tenemos una tabla que tiene el campo por lotes como un INT que representa un INT.

Si dividimos los datos por este campo y luego volvemos a ejecutar una consulta para un lote en particular, deberíamos poder ejecutar estadísticas establecidas io ON antes y después de la partición y ver una reducción en IO,

Si tenemos un millón de filas por partición y cada partición se escribe en un dispositivo separado. La consulta debería poder eliminar las particiones no esenciales.

No he realizado muchas particiones en SQL Server, pero tengo experiencia en particiones en Sybase ASE, y esto se conoce como eliminación de particiones. Cuando tenga tiempo, voy a probar el escenario en una máquina SQL Server 2005.