Esquema de base de datos Diseño - Consejos para mejorar la capacidad de archivar?

Question

Estoy diseñando una tabla en la base de datos que va a almacenar entradas de registro de la aplicación.Hay un par de cosas que me está haciendo pensar acerca de este diseño más que de costumbre.

• Sin embargo, estas entradas de registro será utilizado en tiempo de ejecución por el sistema para tomar decisiones por lo que deben ser relativamente rápido acceso.
• Ellos también tienen el problema es que no va a ser un montón de ellos (12,5 millones de euros por mes es mi estimación).
• No necesito más que el pasado 30 a 45 días en la mayor parte de la decisión de procesamiento.
• Tengo que mantener a todos ellos por mucho más tiempo de 45 días para apoyo y cuestiones legales, probablemente al menos 2 años.
• El diseño de la tabla es bastante simple, todos los tipos simples (sin blobs o nada), cuando sea posible, se utiliza el motor de base de datos para poner en los datos por defecto, en más de una clave externa.
• Si hace alguna diferencia será la base de datos de Microsoft SQL Server 2005.

Lo que yo estaba pensando es tenerlos por escrito de una tabla de base de datos y, a continuación, utilizando una solución ETL mover "viejo" entradas en una tabla de archivo/base de datos - que es grande y el hardware más lento.

Mi pregunta es ¿sabes de consejos, trucos o sugerencias para la base de datos/tabla de diseño para asegurarse de que esto funciona tan bien como sea posible?También si usted piensa que es una mala idea, por favor hágamelo saber, y lo que piensa una mejor idea sería.

Answer 1

Algunas bases de datos ofrecen " particiones " (Oracle, por ejemplo). Una partición es como una vista que recopila varias tablas con una definición idéntica en una. Puede definir criterios que ordenen nuevos datos en las diferentes tablas (por ejemplo, el mes o la semana del año% 6).

Desde el punto de vista del usuario, esta es solo una tabla. Desde la base de datos PoV, son varias tablas independientes, por lo que puede ejecutar comandos completos de la tabla (como truncar, soltar, eliminar de la tabla (sin una condición), cargar / volcar, etc.) contra ellos de manera eficiente.

Si no puede tener una partición, obtendrá un efecto similar con las vistas. En este caso, puede recopilar varias tablas en una sola vista y redefinir esta vista, por ejemplo, una vez al mes a & Quot; free & Quot; una tabla con datos antiguos del resto. Ahora, puede archivar eficientemente esta tabla, borrarla y adjuntarla nuevamente a la vista cuando se haya realizado el gran trabajo. Esto debería ser de gran ayuda para mejorar el rendimiento.

[EDITAR] SQL Server 2005 en adelante (Enterprise Edition) admite particiones. Gracias a Mitch Wheat

Answer 2

Grandes mesas de frenar rápidamente, y es una gran sobrecarga de rendimiento para el uso de ETL para tirar de datos basado en la fecha, a partir de una gran tabla y, a continuación, eliminar el antiguo filas.La respuesta a esto es el uso de varias tablas - probablemente de la tabla de 1/mes basado en sus figuras.Por supuesto, usted necesitará un poco de lógica para generar la tabla de nombres dentro de las consultas.

Estoy de acuerdo con el uso de Desencadenadores para rellenar el 'CurrentMonthAudit de la mesa, al final de mes, a continuación, puede cambiar el nombre de la tabla a MonthAuditYYYYMM.Moviendo las viejas mesas fuera de su servidor principal mediante ETL será fácil, y cada una de las tablas será manejable.Confía en mí, esto es mucho mejor que tratar de manejar una sola tabla con 250M aprox filas.

Answer 3

Su primera buena decisión es mantener todo lo más simple posible.

He tenido buena suerte con su patrón de un simple archivo de registro de transacciones de solo escritura donde los registros se establecen en orden cronológico. Entonces tiene varias opciones para cambiar los datos antiguos. Incluso tener tablas mensuales dispares es manejable en cuanto a consultas siempre que tenga en cuenta la simplicidad. Si tiene algún tipo de replicación en funcionamiento, sus tablas replicadas se pueden implementar y servir como archivo. Luego comience con una nueva mesa vacía al principio de cada mes.

Normalmente me estremezco por las consecuencias del diseño relacional de hacer algo como esto, pero he descubierto que las tablas de registro cronológico de solo escritura son una excepción a los patrones de diseño habituales, por las razones que está tratando aquí.

Pero manténgase alejado de los desencadenantes. Tan lejos como sea posible. La solución más simple es una tabla primaria del tipo del que está hablando aquí, con un mecanismo de replicación probado en el tiempo robusto y simple.

(Por cierto, las tablas grandes no disminuyen su velocidad rápidamente si están bien diseñadas, disminuyen lentamente).

Answer 4

Si no necesita buscar en los registros de registro recientes, hay otra opción: no utilizar una base de datos en absoluto. En su lugar, escriba la información de registro en un archivo y gire el nombre del archivo todas las noches. Cuando se ha escrito un archivo, puede iniciar un trabajo en segundo plano para importar los datos directamente a la base de datos de archivo.

Las bases de datos no siempre son la mejor opción, especialmente para archivos de registro :)