Converter kB para TiB

Um kilobyte são 1.000 bytes quando quem define é um órgão de normalização e 1.024 quando quem define é um sistema operacional. Esta página calcula com 1.000; a unidade de 1.024 se chama kibibyte.

Um tebibyte são 1.024 gibibytes. A distância em relação ao terabyte cresce a cada degrau: 2,4 % no quilo, 4,9 % no mega, 7,4 % no giga e 10 % no tera.

Neste sentido a conta é uma divisão, e por um número inteiro: 1.099.511.628 dessas cabem em um tebibyte sem sobrar nada. O incômodo é só que os resultados saem em frações — um terço, um doze avos — em vez dos números redondos que o sentido contrário dá.

Mesmo assim não se perde nada, porque a divisão é exata. Se o seu resultado não quer parar quieto em decimais — 0,0833… e parentes —, isso é a fração aparecendo, não um erro se instalando.

Um TiB são 1.024 da unidade de baixo; um TB, 1.000. Nesta página isso é a diferença entre 1099511627,776 kB e 1000000000 kB — 10 % — e a distância cresce a cada degrau: por isso é arredondamento desprezível numa foto e um pedaço visível de um HD.

O mistério do espaço que some é inteiro isso. Um disco vendido como um terabyte tem exatamente o que diz em unidades decimais; o Windows reconta em unidades binárias e mantém o nome decimal, então o número encolhe sem que nada tenha se perdido. O macOS conta em unidades decimais desde o 10.6, e é por isso que o mesmo disco pode aparecer com dois tamanhos em dois computadores.

A previsão tem quatro entradas e são sempre as mesmas: o tamanho de um registro, quantos chegam por unidade de tempo, quanto tempo ficam guardados, e o que a camada de armazenamento multiplica em cima disso. A primeira está em kilobyte porque é a escala de uma linha de log ou uma amostra de métrica. A última está em tebibyte porque é o que um pool relata. Tudo entre elas é multiplicação, e a única parte difícil é não trocar de sistema de unidade no meio do caminho.

Um caso trabalhado: um bilhão de registros por dia a um kilobyte cada dá um trilhão de bytes por dia, que é um terabyte, que o pool vai relatar como cerca de 0,909 TiB. Noventa dias disso são 90 TB, que o pool vai relatar como cerca de 81,85 TiB. As duas cifras descrevem o mesmo dado, então um plano que calcula 90 num sistema e provisiona 90 no outro fica errado por cerca de 8,15 unidades de armazenamento — o problema inteiro que este par causa.

Antes de se preocupar com nove por cento, acerte os fatores que valem várias centenas por cento. Compressão é o primeiro: log e métrica estruturados costumam reduzir para um quinto ou um décimo do tamanho bruto, então uma previsão que ignora isso superestima por uma ordem de grandeza. Replicação é o segundo e corre na direção contrária: três cópias são três vezes o armazenamento, e codificação de correção de erro tipicamente fica entre 1,2 e 1,5 vezes.

Depois há o índice, fácil de esquecer porque não é o dado em si. Um repositório de log que indexa campo acrescenta uma estrutura que pode ser uma fração substancial da carga útil, e um banco de dados de série temporal guarda o próprio. O jeito honesto de estabelecer tudo isso é rodar uma amostra representativa no sistema de verdade por um dia e medir o que ocupou — uma medição vence qualquer quantidade de estimativa.

Retenção costuma ser definida por hábito ou pelo primeiro número que alguém sugeriu, e é a entrada com a maior alavanca sobre custo. Reduzir a janela pela metade reduz o tamanho em regime permanente exatamente pela metade; a quantidade de valor perdido raramente é proporcional, já que a esmagadora maioria das consultas sobre dado operacional alcança horas ou dias atrás, não meses. Ver a cifra de armazenamento de cada janela candidata lado a lado muda a conversa.

Onde uma janela mais longa é genuinamente exigida — uma obrigação de auditoria, uma comparação trimestral — costuma ser exigida para um subconjunto, não para tudo. Separar o fluxo para que a parte pequena e valiosa fique um ano e o volume geral fique duas semanas dá a maior parte do benefício numa fração do tamanho, e é uma decisão que precisa ser tomada antes de o dado ser escrito, não depois.

Um repositório com janela de retenção fixa não cresce para sempre: cresce até o dado mais antigo começar a expirar, e então se estabiliza mais ou menos na taxa diária vezes a janela. Esse platô é o número certo para dimensionar, e chega uma janela de retenção depois de o sistema começar. Dimensionar pela curva de crescimento em vez do platô compra capacidade que nunca vai ser usada; dimensionar abaixo do platô significa que a política de expiração começa a fazer a sua gestão de capacidade por você.

O platô se move sempre que a taxa diária muda, o que vale monitorar. Instrumentação nova, aumento de tráfego ou um nível de depuração esquecido ligado em produção elevam a taxa, e o efeito no armazenamento aparece gradualmente ao longo de uma janela de retenção inteira, não imediatamente. Um painel de bytes recebidos por dia prevê o problema; um de bytes armazenados relata com duas semanas de atraso.

Se escondem na fronteira entre o cálculo e a compra. A previsão naturalmente é feita em unidade decimal, porque taxa e tamanho de registro são decimais e a conta é fácil. O pool é relatado em unidade binária, porque é o que sistema de arquivo faz. Se o plano diz 90 TB e o pool diz 82 TiB, são a mesma quantidade e parece um déficit; se o plano diz 90 TiB e 90 TB é provisionado, é um déficit real de nove por cento e parece uma correspondência.

O segundo caso é o perigoso porque nada sinaliza isso. Armazenamento é comprado em terabyte decimal, e um pedido de "90 terabytes" atendido por um fornecedor vendendo capacidade decimal contra uma exigência calculada em tebibyte chega quase 9 TB aquém. Declarar a exigência em byte no pedido de compra remove a ambiguidade pelo custo de um número extra.

Uma previsão é uma cadeia de multiplicações, e arredondar a cada passo se acumula numa direção imprevisível. Taxa vezes tamanho vezes janela vezes replicação vezes sobrecarga de índice, cada um arredondado para dois algarismos, pode cair dez por cento longe da resposta exata com cada passo individual parecendo razoável. Multiplique os números exatos e arredonde uma vez, no final, onde o arredondamento é visível e deliberado.

Esse também é o ponto de decidir quanta precisão a resposta merece. Uma previsão de armazenamento vale no máximo dois algarismos significativos, porque as entradas são estimativas e só a razão de compressão já carrega mais incerteza que tudo o mais somado. O que não vale é falsa precisão gerada por uma planilha, já que uma cifra citada com cinco dígitos convida o leitor a tratar como medida em vez de projetada.

Leva cerca de 1,1 bilhão de kilobyte para fazer um tebibyte, então uma referência útil é que um kilobyte por segundo sustentado dá em torno de 31,5 GB por ano — cerca de 29,4 GiB — e mil kilobytes por segundo dá em torno de 31,5 TB por ano, ou 28,7 TiB. A maioria das previsões nessa escala pode ser conferida contra esses dois números em poucos segundos, e uma resposta que não fica perto de um múltiplo deles tem um erro em algum ponto da cadeia.

A outra conferência é a direção da correção. Converter de decimal para binário sempre torna o número menor, nesse intervalo por nove por cento, então uma cifra em TiB que saiu maior que a em TB foi multiplicada onde deveria ter sido dividida. Esse é o erro aritmético mais frequente nesta categoria, e o mais fácil de pegar, porque não precisa da resposta exata para perceber.