none
Contadores tipo de datos int RRS feed

  • Pregunta

  • Hola,

    Tengo una base de datos que maneja tablas muy grandes, sobre 300 millones de filas las mas grandes, con identificadores Pk con tipo de datos int.
    Me surge la duda  si es viable llegar al tope de lo que admite el tipo de datos int (2.147.483.647).

    Con este numero de filas se comparte bien la base de datos?
    Se podría cambiar la pk en vez de INT pasarla  a BigINT?, habría repercusión en el rendimiento de las consultas por utilizar este tipo de datos?

    Muchas gracias
    Un saludo

    viernes, 5 de febrero de 2021 11:20

Todas las respuestas

  • Hola cheredia79:

    Con este numero de filas se comparte bien la base de datos?

    Supongo que a la pregunta de si se comportaría bien la base de datos, en función de lo que se le solicite y de lo que tenga de hardware, para poder abastecer las solicitudes.

    300 millones de filas por 4 bytes para la clave primaria, 1200 millones de bytes. Pero el almacenamiento de los datos, no es un montón, va en función de lo que tenga cada tabla en su definición, por tanto la segunda pregunta, es si se podría, si, pero realmente implica redefinir la tabla. Drop table y create table. O un drop index, alter table, create index.

    Por tanto si una tabla tiene 2100 millones de filas y 4 bytes para la clave primaria y luego tiene una columna adicional también de tipo int son otros 4 bytes. Total 2100 por 8. Seguro que 2100 por 8 se comportan más efectivamente que una tabla con 300 millones y 4 bytes y un campo varchar de una longitud de 500 bytes. Pero esta segunda opción se comportaría mucho mejor que la misma pero con una columna varchar(max). 

    Eso al final es ponerse en hipótesis sobre un escenario que está completamente basado en opiniones, ya que cada tabla tiene en función de su definición y datos, su comportamiento.

    Un ejemplo

    https://javifer2.wordpress.com/2020/10/01/por-que-limitar-el-tamano-de-las-columnas-varchar-o-nvarchar-si-le-puedo-poner-max/

    Y la repercusión, al final también tiene su importancia. Pasamos de 4 a 8 bytes, por 300 millones pasamos a 2400 millones, ocupa mucho más tanto en disco, como en memoria, por tanto si tenemos que leer la tabla entera, recuperar el id para algo, etc... si que importa. ¿Cuantos Kbs más ocupa ahora la tabla? Ahora bien, seguro que tienes muchos sitios donde optimizar consultas, que en base a que una tabla tenga una clave primaria que sea int o bigint.

    No estás cerca del límite, por tanto en mi opinión, para lo que comentas, yo no me plantearía tan siquiera esa posibilidad.

    viernes, 5 de febrero de 2021 11:51
  • [...] sobre 300 millones de filas las mas grandes, con identificadores Pk con tipo de datos int.
    Me surge la duda  si es viable llegar al tope de lo que admite el tipo de datos int (2.147.483.647).

    ¿El identificador es un IDENTITY? ¿Y con qué frecuencia añades y borras registros? Si, por ejemplo, una vez al día borras todos o casi todos los registros y vuelves a insertar otros tantos registros nuevos, entonces en una semana alcanzarías el tope de dos mil millones y empezarían a producirse errores. Todo depende de con qué frecuencia añadas registros nuevos.

    Si existe algún riesgo de que tengas ese tipo de cambios en la tabla, entonces es preferible que cambies el tipo por BIGINT. Sí, producirá un pequeño impacto debido al incremento de tamaño. Pero esto es comparativamente poco importante en comparación con el problemón que se te presentará si alcanzas el tope. Por otra parte, si los registros son prácticamente fijos y apenas hay nuevas inserciones, entonces tienes margen de sobra con el INT y no hay motivo para cambiarlo.

    viernes, 5 de febrero de 2021 21:19
  • Los registros en principio son fijos y a dia de hoy se estan creando unos 500 millones de registros por año, pero se espera que vaya a mas.

    Estamos valorando la opción del archivado de datos pasandolos a otra tabla y ahi nos surge el problema de que hacer con los ids, si volver al inicio y o cambiar a bigint.

    Creo que la mejor opcion seria quiza añadirle a la pk una columna "año", de esta forma no habria problema con los ids.

    Como veis esta opcion?
    El campo año lo pondriais int o nvarchar(4)?

    Muchas gracias
    Un saludo

    lunes, 8 de febrero de 2021 8:18