¿Cuál es la mejor manera de administrar una gran cantidad de tablas en MS SQL Server?

Question

Esta pregunta está relacionada con otra:
¿Tener varios grupos de archivos ayudará a acelerar mi base de datos?

El software que estamos desarrollando es una herramienta analítica que utiliza MS SQL Server 2005 para almacenar datos relacionales.El análisis inicial puede ser lento (ya que estamos procesando millones o miles de millones de filas de datos), pero existen requisitos de rendimiento para recuperar análisis anteriores rápidamente, por lo que "guardamos" los resultados de cada análisis.

Nuestro enfoque actual es guardar los resultados del análisis en una serie de tablas "específicas de la ejecución", y el análisis es lo suficientemente complejo como para terminar con hasta 100 tablas por análisis.Por lo general, estas tablas consumen unos cientos de MB por análisis (lo cual es pequeño en comparación con nuestros cientos de GB, o a veces varios TB, de datos de origen).Pero en general, el espacio en disco no es un problema para nosotros.Cada conjunto de tablas es específico de un análisis y, en muchos casos, esto nos proporciona enormes mejoras de rendimiento en comparación con la referencia a los datos de origen.

El enfoque comienza a fallar una vez que acumulamos suficientes resultados de análisis guardados; antes de agregar una capacidad de archivo/limpieza más sólida, nuestra base de datos de prueba aumentó a varios millón mesas.Pero no es difícil para nosotros tener más de 100.000 mesas, incluso en producción.Microsoft impone un límite teórico bastante enorme al tamaño de los objetos del sistema (~2 mil millones), pero una vez que nuestra base de datos crece más allá de los 100.000 aproximadamente, consultas simples como CREATE TABLE y DROP TABLE pueden ralentizarse dramáticamente.

Tenemos cierto margen para debatir nuestro enfoque, pero creo que podría ser difícil hacerlo sin más contexto, por lo que quiero hacer la pregunta de manera más general:Si nos vemos obligados a crear tantas tablas, ¿cuál es el mejor enfoque para gestionarlas?¿Varios grupos de archivos?¿Múltiples esquemas/propietarios?¿Varias bases de datos?

Otra nota:No me entusiasma la idea de "simplemente lanzar hardware al problema" (es decir,agregando RAM, potencia de CPU, velocidad del disco).Pero tampoco lo descartaremos, especialmente si (por ejemplo) alguien puede decirnos definitivamente qué efecto tendrá agregar RAM o usar múltiples grupos de archivos en la gestión de un catálogo de sistema grande.

Answer 1

Terminamos dividiendo nuestra base de datos en varias bases de datos.Por lo tanto, la base de datos principal contiene una tabla de "bases de datos" que hace referencia a una o más bases de datos "ejecutadas", cada una de las cuales contiene conjuntos distintos de resultados de análisis.Luego, la tabla principal de "ejecución" contiene un ID de base de datos y el código que recupera un resultado guardado incluye el prefijo de base de datos relevante en todas las consultas.

Este enfoque permite que el catálogo del sistema de cada base de datos sea más razonable, proporciona una mejor separación entre las tablas principales/permanentes y las tablas dinámicas/en ejecución, y también hace que las copias de seguridad y el archivado sean más manejables.También nos permite dividir nuestros datos en múltiples discos físicos, aunque usar múltiples grupos de archivos también lo habría hecho.En general, ahora nos está funcionando bien dados nuestros requisitos actuales y, según el crecimiento esperado, creemos que también escalará bien para nosotros.

También hemos notado que SQL 2008 tiende a manejar catálogos de sistemas grandes mejor que SQL 2000 y SQL 2005.(No habíamos actualizado a 2008 cuando publiqué esta pregunta).

Answer 2

Sin ver primero todo el sistema, mi primera recomendación sería guardar las ejecuciones históricas en tablas combinadas con un RunID como parte de la clave; un modelo dimensional también puede ser relevante aquí.Esta tabla se puede dividir en particiones para mejorarla, lo que también le permitirá distribuir la tabla en otros grupos de archivos.

Otra posibilidad es colocar cada ejecución en su propia base de datos y luego separarlas, adjuntándolas solo según sea necesario (y en formato de solo lectura)

CREATE TABLE y DROP TABLE probablemente tengan un rendimiento deficiente porque las bases de datos maestras o modelo no están optimizadas para este tipo de comportamiento.

También recomiendo hablar con Microsoft sobre su elección de diseño de base de datos.

Answer 3

¿Son todas las tablas estructuras diferentes?Si tienen la misma estructura, es posible que se salga con la suya con una sola tabla particionada.

Si son estructuras diferentes, pero solo subconjuntos del mismo conjunto de columnas de dimensiones, aún puede almacenarlas en particiones en la misma tabla con valores nulos en las columnas no aplicables.

Si esto es analítico (¿quizás cálculos de precios derivados?), podría volcar los resultados de una ejecución de cálculo en archivos planos y reutilizar sus cálculos cargándolos desde los archivos planos.

Answer 4

Este parece ser un problema/aplicación muy interesante con el que está trabajando.Me encantaría trabajar en algo como esto.:)

Tienes una superficie problemática muy grande y eso hace que sea difícil empezar a ayudar.Hay varios parámetros de solución que no son evidentes en su publicación.Por ejemplo, ¿cuánto tiempo piensa conservar las tablas de análisis de ejecución?Hay MUCHAS otras preguntas que deben hacerse.

Necesitará una combinación de almacenamiento de datos serio y partición de datos/tablas.Dependiendo de la cantidad de datos que desee conservar y archivar, es posible que deba comenzar a desnormalizar y aplanar las tablas.

Este sería un caso bastante bueno en el que ponerse en contacto directamente con Microsoft puede resultar mutuamente beneficioso.Microsoft obtiene un buen caso para mostrárselo a otros clientes y usted obtiene ayuda directamente del proveedor.