Particionamiento automático de SQL Server de tablas de bases de datos grandes

Question

Estoy tratando con tablas de bases de datos con decenas de millones de filas (con el potencial de llegar a cientos de millones a lo largo del tiempo), y estoy buscando implementar particiones de bases de datos para tratar de mantener el rendimiento estable a medida que aumenta el recuento de filas. Esto es lo que me gustaría hacer:

Digamos que tengo una mesa que almacena animales. Uno de los campos es AnimalType (es decir, Bird / Fish / Cat / Dog). Me gustaría que cada AnimalType sea una partición separada, porque el 99% de las consultas solo se relacionan con un AnimalType & amp; hay aproximadamente una cantidad igual de AnimalTypes en la tabla (es decir, 1000 peces, 1000 pájaros, 1000 perros), por lo que las particiones deben ser agradables y distribuidas de manera uniforme. Sin embargo, hay muchos tipos de animales, y no quiero ir y crear manualmente las cientos de particiones para cada AnimalType, y cada vez que se ingresa un nuevo AnimalType tengo que crear un nuevo partición.

Por lo tanto, lo que me gustaría es una forma de decirle a SQL Server que particione según AnimalType. Si ya hay una partición para AnimalType, use esa partición, de lo contrario, SQL Server creará automáticamente una nueva partición.

Suena bastante simple, pero parece que no puedo encontrar una manera de hacerlo. ¿Es posible?

Alternativamente , ¿cuáles son algunos otros métodos para mantener las velocidades de acceso a la mesa agradables y rápidas? Me gustaría evitar cualquier cosa que sea simplemente mover cosas manualmente a más tablas, como mover registros más antiguos a una tabla de estilo Historial, ya que existe la posibilidad de que las consultas necesiten datos del conjunto de datos completo y, por lo tanto, esto en realidad no ayuda. Ya tengo algunos índices básicos que ayudan significativamente.

Answer 1

Particionar es una solución para problemas de almacenamiento, es decir. determine en qué datos del grupo de archivos se ubican en función de algún valor de campo. Por sí solo, no ofrece ningún beneficio de rendimiento real, de hecho, en realidad ralentiza las consultas la mayoría de las veces porque se deben agregar nuevos operadores de ubicación de partición. La única forma de exigir consultas para considerar solo una partición es $ PARTITION sintaxis, y esto no se puede utilizar en escenarios de aplicaciones del mundo real. Las consultas que optan por buscar solo una partición lo hacen únicamente en función de los rangos de índice, y analizarían exactamente el mismo número de registros con o sin particiones.

el único momento en que la partición tiene un beneficio de rendimiento es para actividades de administración, como el cambio de partición y el cambio desde una tabla o operaciones de importación masiva.

Los beneficios de rendimiento solo pueden provenir de índices adecuados y consultas cuidadosamente diseñadas.