BBDD mill de registros!

Buenas noches a todos,

 

Estoy realizando un proyecto con una base de datos SQL-Server 2008. Al año se generan más de 3 millones de registros en un par de tablas, mientras que en las otras van creciendo a un ritmo de unos pocos centenares de miles de registros.

 

Supongo que hay varias maneras de optimizar, gestionar, en definitiva de organizar tal volumen de datos. Estas son las diferentes opciones que he podido recopilar tras una breve búsqueda por internet.

 

1.- Realizar una copia de la base de datos original cada año: De esta manera tendríamos la original vacía al iniciar el año y las otras harían la función de historial. (Esto puede ser un caos a la hora de buscar ciertos datos)

2.- Crear diferentes tablas secundarias que actúen de historial para la original. 

3.- Implementarlo todo en una única base de datos.

 

Quiero saber la manera más adecuada o cual elegiríais a la hora de gestionar tablas con ingentes cantidades de registros. He leído el post de Carlos sobre www.dataprix.com/forum/2010/03/bases-datos-ideadas-para-gestionar-grandes-volumenes pero solo dicen qué sistema gestor utilizan grandes sistemas como facebook.

 

Creo que me he explicado con claridad. Espero vuestras respuestas.

Muchas gracias!

Si quieres seguir teniendo acceso directo a los datos históricos, y no perder rendimiento, también tienes la opción de particionar estas dos tablas. Por lo que dices, si te puedes plantear 'apartar' los datos del año anterior, lo vas a tener muy fácil para definir un particionamiento por fecha. Puedes particionar por año, o incluso definir un intervalo más reducido, trimestral, por ejemplo.

Te enlazo el tema Particionamiento de tablas en SQLServer 2005, donde se discute bastante sobre esta opción.

Un saludo,

Como muy bien dices, esos datos historicos han de ser accesibles. Leere el tema del particionado por fecha e intentare implementarlo.

 

Muchas gracias Carlos.

Buenas tardes a todos,

 

He estado informándome  sobre las particiones de tablas. Lo he provado y funciona aunque sigo haciendo pruevas. Otra solución que he encontrado es todo lo referente a cubos OLAP.

 

En este tema estoy un poco perdido y me surgen un par de dudas.

 

Se que una vez creada la estructura de los cubos es imposible cambiarla. Otra característica es que me permite hacer consultas con gran cantidad de datos.

Hay alguna "limitación" o diferència respecto a las bases de datos relacionadas a la hora de insertar nuevos registros en los cubos? Me refiero si en los cubos la inserción es mas lenta o costosa.

 

Espero vuestras respuestas.

 

Muchas gracias!

En respuesta a por swagger

Los cubos OLAP se utilizan para explotarlos con herramientas de Business Intelligence, y se diseñan especialmente para satisfacer necesidades analíticas, nunca como una solución puntual a problemas de volumetría o rendimiento.

A menos que te estés planteando comenzar un proyecto de Business Intelligence yo me olvidaría de los cubos OLAP. Piensa que, por ejemplo, los datos de los cubos se mantienen con cargas de datos cada cierto tiempo, no en tiempo real, que no se eliminan registros, y que no siguen las reglas de normalización de los modelos relacionales.