Convertir kB a TiB

Un kilobyte son 1.000 bytes cuando lo define un organismo de normalización y 1.024 cuando lo define un sistema operativo. Esta página calcula con 1.000; la unidad de 1.024 se llama kibibyte.

Un tebibyte son 1.024 gibibytes. La distancia respecto al terabyte crece en cada escalón: 2,4 % en kilo, 4,9 % en mega, 7,4 % en giga y 10 % en tera.

En este sentido la cuenta es una división, y por un número entero: 1.099.511.628 de estas caben en un tebibyte sin que sobre nada. Lo incómodo es solo que los resultados salen en fracciones —un tercio de tebibyte, un doceavo— en lugar de las cifras redondas que da el sentido contrario.

Aun así no se pierde nada al redondear, porque la división es exacta. Si el resultado no se queda quieto en decimales —0,0833… y parecidos—, eso es la fracción asomando, no un error colándose.

Un TiB son 1.024 de la unidad de debajo; un TB, 1.000. En esta página eso es la diferencia entre 1099511627,776 kB y 1000000000 kB —un 10 %—, y la distancia crece en cada escalón: por eso es un redondeo despreciable en una foto y un trozo visible de un disco duro.

En eso consiste entero el misterio del espacio que falta, y en esta página vale un 10 %. Un disco vendido en TB tiene exactamente lo que dice la etiqueta; lo que pasa después es que Windows divide entre 1.024 en vez de entre 1.000, conserva el nombre decimal y muestra 1000000000 kB donde la caja ponía 1099511627,776 kB. macOS cuenta estas cifras en unidades decimales desde 10.6, y por eso el mismo disco puede parecer de dos tamaños en dos ordenadores: no falta nada ni redondea nadie, son los mismos bytes con dos nombres.

La previsión tiene siempre las mismas cuatro entradas: el tamaño de un registro, cuántos llegan por unidad de tiempo, cuánto se conservan y por cuánto multiplica todo eso la capa de almacenamiento. La primera está en kilobytes porque esa es la escala de una línea de registro o una muestra de métricas. La última está en tebibytes porque así es como informa un depósito. Entre medias todo es multiplicación, y la única parte difícil es no cambiar de sistema de unidades a mitad de camino.

Un caso resuelto: mil millones de registros al día de 1 kB cada uno son 1.000.000.000.000 de bytes al día, es decir, un terabyte, que el depósito va a mostrar como 0,909 TiB. Noventa días de eso son 90 TB, que el depósito mostrará como 81,85 TiB. Las dos cifras describen el mismo dato, así que un plan que calcula 90 en un sistema y aprovisiona 90 en el otro se queda corto por 8,15 unidades de almacenamiento, que es todo el problema que causa este par.

Antes de preocuparse por ese 9%, conviene ajustar los factores que valen varios cientos por ciento. La compresión es el primero: los registros y métricas estructurados suelen reducirse a una quinta parte o una décima de su tamaño en bruto, así que una previsión que la ignora se pasa de largo en un orden de magnitud entero. La replicación es el segundo y actúa al revés: tres copias son tres veces el almacenamiento, y la codificación de borrado suele rondar entre 1,2 y 1,5 veces.

Después están los índices, fáciles de olvidar porque no son el dato en sí. Un almacén de registros que indexa campos añade una estructura que puede ser una fracción considerable de la carga útil, y una base de series temporales mantiene la suya propia. La manera honesta de fijar todos estos factores es pasar una muestra representativa por el sistema real durante un día y medir lo que ocupó de verdad: una sola medición vale más que cualquier estimación.

La retención suele fijarse por costumbre o por la primera cifra que alguien propuso, y es la entrada con más peso sobre el coste. Reducir el periodo a la mitad reduce exactamente a la mitad el tamaño en régimen permanente, y el valor que se pierde rara vez es proporcional, porque la inmensa mayoría de las consultas sobre datos operativos llegan solo hasta horas o días atrás, no meses. Ver la cifra de almacenamiento de cada periodo posible una al lado de otra cambia la conversación.

Donde sí haga falta un periodo largo —una obligación de auditoría, una comparación trimestral— casi siempre hace falta solo para una parte de los datos, no para todos. Separar el flujo de manera que la parte pequeña y valiosa se conserve un año y el grueso solo dos semanas da la mayor parte del beneficio por una fracción del tamaño, y es una decisión que hay que tomar antes de escribir el dato, no después.

Un almacén con un periodo de retención fijo no crece para siempre: crece hasta que empiezan a caducar los datos más antiguos, y a partir de ahí se mantiene aproximadamente constante en la tasa diaria multiplicada por el periodo. Esa meseta es la cifra para la que hay que dimensionar, y llega un periodo de retención después de que el sistema arranque. Dimensionar para la curva de crecimiento en vez de para la meseta compra capacidad que nunca se va a usar; dimensionar por debajo de la meseta hace que la caducidad empiece a gestionar la capacidad por su cuenta.

La meseta se desplaza cada vez que cambia la tasa diaria, y eso es lo que conviene vigilar. Una nueva instrumentación, un aumento de tráfico o un nivel de depuración olvidado en producción elevan la tasa, y el efecto sobre el almacenamiento aparece gradualmente a lo largo de todo un periodo de retención, no de inmediato. Un panel de bytes ingeridos por día anticipa el problema; uno de bytes almacenados lo informa con dos semanas de retraso.

Se esconde en la frontera entre el cálculo y la compra. La previsión se hace de manera natural en unidades decimales, porque las tasas y los tamaños de registro son decimales y la aritmética es sencilla. El depósito informa en unidades binarias, porque así funcionan los sistemas de archivos. Si el plan dice 90 TB y el depósito dice 82 TiB, es la misma cantidad y parece un déficit; si el plan dice 90 TiB y se aprovisionan 90 TB, es un déficit real de un 9% y parece que coincide.

El segundo caso es el peligroso porque nada lo señala. El almacenamiento se compra en terabytes decimales, y una petición de «90 terabytes» satisfecha por un proveedor que vende capacidad decimal contra un requisito calculado en tebibytes llega casi nueve TB corta. Indicar el requisito en bytes en la orden de compra elimina la ambigüedad por el coste de una sola cifra adicional.

Una previsión es una cadena de multiplicaciones, y redondear en cada paso se acumula en una dirección impredecible. Tasa por tamaño por periodo por replicación por sobrecarga de índices, redondeado a dos cifras en cada paso, puede acabar a un diez por ciento de la respuesta exacta con cada paso individual pareciendo razonable. Multiplica las cifras exactas y redondea una sola vez, al final, donde el redondeo es visible y deliberado.

Ese es también el momento de decidir cuánta precisión merece la respuesta. Una previsión de almacenamiento vale, como mucho, dos cifras significativas, porque las entradas son estimaciones y la proporción de compresión por sí sola arrastra más incertidumbre que todo lo demás junto. Lo que no vale es la falsa precisión que produce una hoja de cálculo: una cifra a cinco dígitos invita a tratarla como medida en vez de como proyección.

Hacen falta unos 1.100 millones de kilobytes para llegar a un tebibyte, así que una referencia útil es que un kilobyte por segundo, sostenido, son unos 31,5 GB al año —unos 29,4 GiB—, y mil kilobytes por segundo son unos 31,5 TB al año, o 28,7 TiB. La mayoría de las previsiones a esta escala se pueden comprobar contra esas dos cifras en unos segundos, y un resultado que no se acerca a un múltiplo de ellas tiene un error en algún punto de la cadena. La misma referencia funciona hacia abajo: cien bytes por segundo son unos 3,15 GB al año, la escala habitual de la telemetría de un solo dispositivo antes de multiplicarla por toda la flota.

La otra comprobación es la dirección de la corrección. Pasar de decimal a binario siempre reduce la cifra, a este rango en un 9%, así que un valor en TiB que salga mayor que el valor en TB tiene una multiplicación donde debería haber una división. Es el error aritmético más frecuente de esta categoría y el más fácil de detectar, porque no hace falta conocer la respuesta exacta para verlo.