Particionamiento de SQL Server: ¿qué usar para la clave de partición?

Nunca he trabajado con el particionamiento de SQL Server, pero actualmente me enfrento al diseño de una base de datos para la cual los volúmenes probablemente lo justifiquen. El sistema es para cupones. Los cupones se emitirán periódicamente, generalmente cada seis semanas, aunque también se emitirán ad-hoc, por ejemplo, para un evento especial. Hay 15 millones de clientes y por cada evento de emisión, cada cliente recibirá 6 tipos de cupones diferentes, lo que da un total de 90 millones de instancias de cupones. Necesitamos rastrear los datos de canje de instancias de cupones y mantenerlos durante 6 meses, aunque generalmente un cupón solo es válido por seis semanas. Cualquier solicitud de canje de un cupón no válido no llegará a la base de datos porque será validada por el TPV hasta.

Durante un período de seis meses, tendremos que almacenar hasta 360 millones de filas en la tabla de Instancias de cupones y hasta 72 millones (suponiendo una tasa de canje máxima del 20%) en la tabla de Canje. Tengo la sensación de que estos números son demasiado grandes para una sola partición?

Mi pregunta es: ¿qué usar como clave de partición? Un candidato obvio sería por evento de emisión, dando aproximadamente 6 particiones. ¿Pero entonces creo que tal vez incluso eso daría un tamaño de partición que es demasiado grande para permitir un rendimiento óptimo? ¿Sería posible particionar por dos claves, por ejemplo, por evento de emisión + último dígito del ID del cliente? Entonces la lógica sería:

If issuance event = 1 and last digit of customer id < 5 then
    Store in partition 1
Else if issuance event = 1 and last digit of customer id >4 then
    Store in partition 2
Else if issuance event =2 and last digit of customer id <5 then
    Store in partition 3
Else if issuance event =2 and last digit of customer id >4 then
    Store in partition 4
Etc...

Además, no estoy seguro de la especificación del servidor de base de datos que necesitaremos. ¿Serán suficientes 16gb y 8CPU? El db necesita poder devolver un resultado de la tabla de instancias de cupones, tecleado en un valor de código de barras numérico en menos de medio segundo. Se espera que la solicitud de transacción esperada para validar (seleccionar) y canjear (insertar) alcance un máximo de aproximadamente 3.500 por minuto.

El servidor SQL Server 2008r2 64bit db se aprovisionará como VM desde un host muy potente con acceso a un SAN de alto rendimiento y gran capacidad.

Estaría muy agradecido por cualquier consejo de aquellos que han implementado una solución de SQL Server para administrar volúmenes similares.

Saludos

Robar.

Las preguntas sobre las especificaciones del servidor deben dirigirse a Serverfault o DBA.SE.

Para la pregunta de particionamiento, no creo que necesite necesariamente particionar para esto.

Las filas de 360 ​​m son muchas, pero no demasiado difíciles de manejar.

No NO bajo ninguna circunstancia trate de partición basado en el último dígito de un campo. No estoy seguro de que esto funcione, pero no es SARGable, lo que no sería sostenible.

Si solo necesita hacer una búsqueda de una sola fila basada en una clave numérica, la partición probablemente no ayudará.

Si decide seguir la ruta de la partición, tenga en cuenta que, para ser efectivas, todas sus consultas deben incluir su (s) clave (s) de partición para que el motor sepa qué partición debe verificar. De lo contrario, los verificará a todos y realmente perjudicará el rendimiento.

PUEDE particionar en varias claves si utiliza una columna calculada persistente; como han dicho otros, sin embargo, la partición no funciona para todas las situaciones. No estoy seguro de entender su escenario lo suficiente como para darle consejos específicos, pero aquí hay algunas pautas generales:

• La partición es útil para leer datos cuando la clave de partición es parte de la instrucción SQL, lo que permite al optimizador invocar la exclusión de partición. Debe asegurarse de que la clave que elija sea útil para la mayoría de las consultas.

• Una ventaja de una buena estrategia de particionamiento es el envejecimiento de los datos; por ejemplo, si su clave de partición está basada en la fecha (es decir, el día del año), y desea eliminar todos los datos que son más antiguos que una fecha determinada, es muy fácil CAMBIAR esas particiones a una tabla vacía y truncarlas.

Realmente necesita definir sus requisitos un poco más claramente. Menciona que tendrá aproximadamente 360 ​​millones de filas en 6 meses. ¿Qué tal en 2 años? ¿Seguirá creciendo solo al ritmo que está creciendo actualmente? O existe la posibilidad de que experimente un crecimiento exponencial. ¿Desea mantener los datos en esta tabla para siempre? o desea archivar datos de forma regular.

El particionamiento se puede usar para archivar datos. Ver escenario de ventana deslizante. Vea este documento técnico y este .

El particionamiento también se puede usar para administrar la fragmentación del índice. Puede reconstruir / reorganizar particiones particulares.

También debe considerar las vistas particionadas en lugar de las tablas particionadas. Las vistas particionadas no requieren una licencia de SQL Server Enterprise. Las vistas particionadas también le permiten realizar reconstrucciones de índices en línea en una "partición" particular.

La partición también se puede considerar al hacer la planificación de recuperación ante desastres. Se puede usar para la recuperación parcial de la base de datos. Por ejemplo: puede tener sus particiones antiguas en un grupo de archivos diferente al de las particiones principales / actuales. Y luego, cuando se está recuperando, recupera el grupo de archivos primario, luego el grupo de archivos en el que residen sus particiones actuales y, por último, puede restaurar los grupos de archivos en los que residen las particiones antiguas. Esto puede reducir la cantidad de tiempo que su aplicación tiene que estar inactiva.

Mira este gran video de Kimberly Tripp sobre particiones .

A menos que realice particiones debido al archivo de datos antiguos, lo está haciendo por la razón incorrecta y no debe hacerlo.