Convertir los bytes de una fila en un tamaño de tabla con el que planificar
Las bases de datos responden en bytes. pg_total_relation_size('orders') devuelve un entero pelado; information_schema.tables informa de data_length e index_length en bytes; la página de estadísticas del motor de almacenamiento te suelta un número de nueve o doce dígitos sin unidad alguna. La planificación de capacidad, en cambio, se hace en gigabytes: la unidad del disco que hay que aprovisionar, del volumen que hay que ampliar y de la partida presupuestaria que alguien tiene que aprobar.
GB = bytes ÷ 1 000 000 000. Así, una tabla que se reporta con 42 500 000 000 bytes son 42 500 000 000 ÷ 1 000 000 000 = 42,5 GB.Lo útil no es la división en sí, sino saber qué bytes contiene ese número. El tamaño de una relación y el tamaño de una tabla son cifras distintas, y en esa diferencia es donde suele torcerse una previsión de capacidad.
El ancho de fila nunca son solo las columnas
Los índices suelen ser la mitad más grande
El crecimiento es un ritmo, no una foto
De una cifra en bytes a un número de aprovisionamiento
Saca la cifra en bytes de la base de datos
Pide el entero en bruto en lugar de una cadena ya formateada: el valor sin formato es el que quieres convertir y evita que el servidor te lo haya redondeado a un decimal.
Pégala en el campo de bytes
El valor en gigabytes aparece mientras escribes. La salida de una consulta suele venir agrupada con espacios o con la coma como marca decimal; ambas se admiten y los espacios simplemente se ignoran.
Cópiala al plan de capacidad
El botón de copiar de cada campo te devuelve el número pelado, así que la cifra cae directa en una celda de hoja de cálculo, en el tamaño de un volumen de Terraform o en una incidencia sin tener que quitarle antes la unidad.
Invierte la operación para escribir un umbral
Intercambia las unidades para ir de gigabytes a bytes cuando una regla de monitorización o una cuota necesita el valor en la unidad que expone la base de datos. Cualquiera de los menús tiene buscador, así que los terabytes están a una pulsación cuando una tabla se sale de los GB.
Ancho de fila × número de filas: lo que cuesta de verdad una tabla
Multiplica el ancho medio de fila en disco por el número de filas y obtienes los bytes del montículo; divide entre mil millones para los gigabytes. Las cifras de abajo dan por hecho que el ancho ya incluye la cabecera por fila y excluyen los índices: esos se suman aparte.
| Tabla típica | Ancho de fila | Filas | Bytes de montículo | Tamaño en GB |
|---|---|---|---|---|
| Flujo de eventos, estrecho | 96 B | 250 000 000 | 24 000 000 000 | 24 GB |
| Registros de sesión | 128 B | 10 000 000 | 1 280 000 000 | 1,28 GB |
| Líneas de pedido | 256 B | 50 000 000 | 12 800 000 000 | 12,8 GB |
| Perfiles de usuario | 512 B | 100 000 000 | 51 200 000 000 | 51,2 GB |
| Bitácora de auditoría con JSON | 1 024 B | 5 000 000 | 5 120 000 000 | 5,12 GB |
| Documentos, filas anchas | 2 048 B | 1 000 000 | 2 048 000 000 | 2,048 GB |
Casi siempre hay que aplicar dos ajustes. Las tuplas muertas a la espera de limpieza inflan el montículo por encima de la cifra aritmética, y cualquier columna cuyo valor supere los dos kilobytes aproximadamente se comprime y se expulsa a una relación TOAST, que el tamaño de tabla a secas no incluye y el de relación total sí.
Los dos campos vivos mientras comparas tablas
Escribe en cualquiera de las casillas y la otra la sigue al momento, así que puedes recorrer la lista de tamaños de relación de una misma consulta sin borrar y volver a introducir cada valor.
Los valores de doce dígitos se leen bien
Los millares se separan con un espacio y los resultados muy grandes pasan a notación científica, lo que hace evidente de un vistazo que has contado mal los dígitos de una cifra en bytes.
Acompaña a una tabla más allá del terabyte
Los dos menús de unidades tienen buscador y listan todas las unidades de almacenamiento, así que la misma página cubre una tabla de consulta en kilobytes y una tabla de hechos particionada en terabytes.
Las cifras de producción se quedan en local
Todo se calcula en el navegador una vez cargada la página, así que los tamaños copiados de una base de datos en producción no se envían a ninguna parte.
Preguntas sobre el tamaño de las bases de datos
¿Por qué mi tabla es más grande de lo que sugiere el ancho de las columnas?
Cada fila arrastra una sobrecarga fija antes de que empiecen tus datos. En PostgreSQL son una cabecera de tupla de 23 bytes más un puntero de elemento de 4 bytes en la página, y los valores de las columnas se rellenan hasta su frontera de alineación: un bigint después de un bool puede desperdiciar siete bytes. En una tabla estrecha, esos añadidos pueden ser un tercio de la fila. Multiplica el ancho real, no el nominal, antes de dividir para pasar a gigabytes.
¿Hay que contar los índices en el tamaño que aprovisiono?
Sí, y se subestiman a menudo. Cada índice guarda sus columnas clave más un puntero de fila y su propia sobrecarga de página, así que una tabla con seis índices puede gastar más espacio en ellos que en el montículo. Dimensiona por separado el montículo y los índices, pasa cada parte a gigabytes y aprovisiona la suma; después deja margen para la copia temporal que necesita una reindexación.
¿Qué incluye exactamente el tamaño de relación total?
Devuelve los bytes del montículo, de todos los índices, de los mapas de espacio libre y de visibilidad, y de cualquier relación TOAST asociada a la tabla. La función de tamaño de tabla a secas cubre solo el montículo y sus mapas. Cuando un panel de monitorización y una consulta manual no se ponen de acuerdo sobre una tabla, casi siempre es por esto: uno contó los índices y el otro no.
¿Cómo cambian la cuenta los valores de columna demasiado grandes?
Una fila tiene que caber dentro de una página, así que en cuanto un valor pasa de unos dos kilobytes el motor lo comprime y, si no basta, lo saca fuera de línea a una relación lateral dejando un puntero pequeño en la fila. El ancho visible de la fila se desploma mientras el almacenamiento real está en otro sitio. En una tabla de textos o documentos JSON grandes, una estimación de ancho por filas puede quedarse cortísima si no mides también la relación lateral.
¿Cómo proyecto el tamaño del año que viene a partir de las filas diarias?
Multiplica las filas por día por el ancho medido en disco para obtener bytes al día, pásalo a gigabytes y multiplícalo por la ventana de retención. Con 2 000 000 de filas diarias y un ancho de 256 bytes estás añadiendo 512 000 000 de bytes al día: 0,512 GB, unos 15,4 GB al mes. Aplica encima la proporción de índices que mediste sobre los datos actuales y contrasta el resultado con el crecimiento real al cabo de un mes en vez de fiarte de la primera estimación.
Aún no hay comentarios. ¡Sé el primero en comentar!