Millones de Registros

16/05/2006 - 15:48 por Alf | Informe spam

Si alguien ha tenido experiencia o tiene, en una base de datos que soporten
tablas de millones de registros, me gustaría preguntaros lo siguiente:

Tengo que desarrollar un aplicativo sobre Sql Server 2000, donde en
principio una serie de tablas van a tener millones de registros, en torno a
10 millones anuales. Cada registro puede tener 175bytes en datos. En 10 años
y sólo por la tabla de marras me sale: 175x10.000.000x10/1024/1024/1024 =
16'3 Gigas.

El hardware no será problema, admito tambien sugerencias para el servidor,
procesador, memoria, sistema de redundacia de discos duros, etc.

Las preguntas son relativas al diseño de la base de datos. ¿Parto la tabla
por años, es decir, 10 tablas en 10 años?, no hace falta porque lo va a
soportar?

Opción de trasapaso a históricos desde el programa y traspaso lo que el
usuario desea a otra base de datos, sólo para consultas? En caso de esto,
aqui se me plantean tambien las mismas interrogantes que antes.

Bueno, creo que ya veis por donde voy.

Lo que no quisiera es desarrollar algo en base a un diseño malo, y después
cuando ya tengan un montonal de registros y empiecen los problemas,
solucionarlos en caliente con prisas, sin poder para el aplicativo, etc.

Gracias por vuestro tiempo y en espera de vuestras sugerencias...

Un saludo

Siga el debate

8 respuestas

Tengo una respuesta

DRAGON AGE™: INQUISITION – Matadragones

Leer las respuestas

#1 mitubi

16/05/2006 - 16:09 | Informe spam

Buenas tardes,
la verdad es que no tengo tablas con millones de registros (solo una de
22.000.000 de registros otra de 4.000.000 y varias del millón). El
problema que tuvimos era que la mayor de todas se estaba venga a
consultar (en una aplicación que la consultaba tropecientas veces por
segundo). Imagina. Como el uso es diarío, es decir, solo es necesario
usar las del día actual y el resto de histórico, lo que hizo la empresa
desarrolladora fue particionar la tabla en dos, una para consultas en
tiempo real y otra para históricos. Con esto se acababan nuestros
problemas, en cuanto a rendimiento se refería. Eso lo hizo con varias
tablas que tenían mucho meneo, y con un trato similar (de uso diarío y
el resto histórico).
No sé si particionar por varios años te ayudaría, pues creo que
dificultaría el acceso a los datos si se quiere hacer por año, y quizás
sobredimensionaría la BD bastante, pero depende de mucho de como se
trate la información.
Yo creo que la derecha es particionar la tabla, por un lado los datos
actuales y por otro los de histórico. Ahora bien, la duda queda si
hacerlo por años o no. Eso se debería mirar como se va a acceder a la
información, etc.
Un saludo

Alf escribió:

Si alguien ha tenido experiencia o tiene, en una base de datos que soporten
tablas de millones de registros, me gustaría preguntaros lo siguiente:

Tengo que desarrollar un aplicativo sobre Sql Server 2000, donde en
principio una serie de tablas van a tener millones de registros, en torno a
10 millones anuales. Cada registro puede tener 175bytes en datos. En 10 años
y sólo por la tabla de marras me sale: 175x10.000.000x10/1024/1024/1024 =
16'3 Gigas.

El hardware no será problema, admito tambien sugerencias para el servidor,
procesador, memoria, sistema de redundacia de discos duros, etc.

Las preguntas son relativas al diseño de la base de datos. ¿Parto la tabla
por años, es decir, 10 tablas en 10 años?, no hace falta porque lo va a
soportar?

Opción de trasapaso a históricos desde el programa y traspaso lo que el
usuario desea a otra base de datos, sólo para consultas? En caso de esto,
aqui se me plantean tambien las mismas interrogantes que antes.

Bueno, creo que ya veis por donde voy.

Lo que no quisiera es desarrollar algo en base a un diseño malo, y después
cuando ya tengan un montonal de registros y empiecen los problemas,
solucionarlos en caliente con prisas, sin poder para el aplicativo, etc.

Gracias por vuestro tiempo y en espera de vuestras sugerencias...

Un saludo

Leer las otras respuestas

Preguntas similares

Busqueda sugerida :