¿2.000.000.000 de registros en una tabla?
Hola a todos.
El problema que es el siguiente.
Por motivos del volumen de los datos me salen unos número que a priori me parecen escandalosos, por ejemplo tengo una tabla que contendrá unos 2.000.000.000 de registros.
¿Cómo veis el tema?.
La tabla es de detalle y es de tipo clave-valor (solo tres campos) por registros, con un total de 2000 registros de detalle para cada elemento de la tabla maestra.
Otra posibilidad es hacer registros con mas campos, por ejemplo de 100 campos para reducir el número de registros de la tabla de detalle a 20 por cada elemento padre y conseguir un total de 20.000.000 de registros.
¿Cuál es la solución mejor?
¿Cuantos campos como máximo aguanta una tabla?
Usaremos Oracle 9i sobre AIX.
Muchas gracias y un saludo.
El problema que es el siguiente.
Por motivos del volumen de los datos me salen unos número que a priori me parecen escandalosos, por ejemplo tengo una tabla que contendrá unos 2.000.000.000 de registros.
¿Cómo veis el tema?.
La tabla es de detalle y es de tipo clave-valor (solo tres campos) por registros, con un total de 2000 registros de detalle para cada elemento de la tabla maestra.
Otra posibilidad es hacer registros con mas campos, por ejemplo de 100 campos para reducir el número de registros de la tabla de detalle a 20 por cada elemento padre y conseguir un total de 20.000.000 de registros.
¿Cuál es la solución mejor?
¿Cuantos campos como máximo aguanta una tabla?
Usaremos Oracle 9i sobre AIX.
Muchas gracias y un saludo.
no te preocupes por el número de registros, preocúpate por el tamaño que tendrá la tabla.... cuanto va a ocupar?
yo la crearÃa sin más, y crearÃa otra paralela particionada, dependiendo de los volúmenes o filesystems que tengas para ocupar cada partición en uno de ellos, si al hacer las pruebas encuentras que es lenta y no es por culpa de algún parámetro de la instancia o s.o.
yo he visto tablas con muchos más millones de registros y ni siquiera estaban particionadas porque tenÃan un rendimiento muy bueno.
ten muy en cuenta los Ãndices y las select´s que hagas contra ella, y mucho cuidado también cuando crees la tabla con el next_extent y pct_increase, yo te aconsejo que uses tablespaces manejados localmente....y sobre todo.... paciencia y estudio
yo la crearÃa sin más, y crearÃa otra paralela particionada, dependiendo de los volúmenes o filesystems que tengas para ocupar cada partición en uno de ellos, si al hacer las pruebas encuentras que es lenta y no es por culpa de algún parámetro de la instancia o s.o.
yo he visto tablas con muchos más millones de registros y ni siquiera estaban particionadas porque tenÃan un rendimiento muy bueno.
ten muy en cuenta los Ãndices y las select´s que hagas contra ella, y mucho cuidado también cuando crees la tabla con el next_extent y pct_increase, yo te aconsejo que uses tablespaces manejados localmente....y sobre todo.... paciencia y estudio
el tamaño aproximado es de 62,54 Gigas. He estudiado el tema de particionamiento y podrÃa hacer unas 1500 particiones para llegar a contener 1.300.000 de registros por partición (40 megas por partición) ¡que os parece?
como has sacado el tamaño? has utilizado la función vsize? es estimado? en base a que? te lo digo porque hay veces que te llevas unos sustos...
ten en cuenta también el character set y el national character set con el que la vas a crear la bbdd porque también depende del número de bytes que usen para guardar esos caracteres.
1500 particiones!!!!!!! porqué opción las vas a particionar, por rango, etc...???
es que depende de muchas, muchÃsimas cosas pero yo no tendrÃa 1500 particiones de 40 megas cada una.
Con un tamaño de 1 ó 2 gb por partición no es mucho y tendrÃas 62 o 31 particiones, que es obvio, es mucho más manejable.
sabes que puedes tener Ãndices globales a la tabla o particulares por partición?? has elegido ya??
ten cuidado con el número de extensiones, oracle recomienda que estén por debajo de 1000 para cada segmento.
suerte y saludos
ten en cuenta también el character set y el national character set con el que la vas a crear la bbdd porque también depende del número de bytes que usen para guardar esos caracteres.
1500 particiones!!!!!!! porqué opción las vas a particionar, por rango, etc...???
es que depende de muchas, muchÃsimas cosas pero yo no tendrÃa 1500 particiones de 40 megas cada una.
Con un tamaño de 1 ó 2 gb por partición no es mucho y tendrÃas 62 o 31 particiones, que es obvio, es mucho más manejable.
sabes que puedes tener Ãndices globales a la tabla o particulares por partición?? has elegido ya??
ten cuidado con el número de extensiones, oracle recomienda que estén por debajo de 1000 para cada segmento.
suerte y saludos
Gracias por vuestras contestaciones.
El tamaño lo he estimado, poniendo una media de 5 bytes por campo (son numéricos) y muchos tendrán un byte de longitud, por lo que no tengo problemas con el carácter set.
El particionamiento lo he hecho por campos de la tabla padre, año, tipo de datos (mas de 1000 tipos) , etc, por eso me salen tantas particiones. Como tu dices me parecen muchas aunque por lo que he leÃdo Oracle aguanta hasta 64000 particiones por tabla. Probablemente y siguiendo tus indicaciones lo reduzca metiendo un particionamiento por hash de entre 50 o 100 particiones dependiendo de los tamaños del volumen real que tenga una vez haya estudiado un porcentaje de registros.
Lo que comentas de tener Ãndices para toda la tabla o por partición todavÃa no he decidido nada. ¿tu que recomiendas?
Bueno un saludo y deciros que es un lujo hablar con vosotros.
El tamaño lo he estimado, poniendo una media de 5 bytes por campo (son numéricos) y muchos tendrán un byte de longitud, por lo que no tengo problemas con el carácter set.
El particionamiento lo he hecho por campos de la tabla padre, año, tipo de datos (mas de 1000 tipos) , etc, por eso me salen tantas particiones. Como tu dices me parecen muchas aunque por lo que he leÃdo Oracle aguanta hasta 64000 particiones por tabla. Probablemente y siguiendo tus indicaciones lo reduzca metiendo un particionamiento por hash de entre 50 o 100 particiones dependiendo de los tamaños del volumen real que tenga una vez haya estudiado un porcentaje de registros.
Lo que comentas de tener Ãndices para toda la tabla o por partición todavÃa no he decidido nada. ¿tu que recomiendas?
Bueno un saludo y deciros que es un lujo hablar con vosotros.
