Converter TiB para kB

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.

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.

Neste sentido a conta é uma multiplicação, e por um número inteiro: um tebibyte são 1.099.511.628 kilobytes, exatamente, e 1.099.511.628 é a definição, não uma medição que chegou perto.

Isso faz dela uma das poucas conversões que valem de cabeça, e o resultado dá para conferir: divida de volta e você tem que cair no número de partida, exato e sem resto para explicar.

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.

Nove ordens de grandeza separam essas duas unidades, e o motivo de atravessá-las quase sempre é uma contagem. Quantas linhas de log cabem. Quantos documentos. Quantos dias de retenção na taxa atual. Um tebibyte guarda cerca de 1,1 bilhão de registros de um kilobyte cada — uma cifra que vale lembrar porque transforma a maioria dessas perguntas numa divisão só.

A dois kilobytes por registro isso vira cerca de 550 milhões; a cinco kilobytes, cerca de 220 milhões; a meio kilobyte, mais de 2 bilhões. A diferença entre esses três é um fator de dez, movida inteiramente pelo tamanho do registro, enquanto a questão de unidade binária contra decimal move a resposta em apenas dez por cento. Essa ordem de grandeza é o mais útil a tirar desta conversão: acerte o tamanho do registro e o prefixo cuida de si mesmo.

Um sistema escrevendo mil linhas por segundo a um kilobyte cada produz um megabyte por segundo, o que dá quase 87 GB por dia. Um tebibyte de capacidade sem compressão, portanto, cobre pouco menos de treze dias. Dobrar a taxa de linhas divide isso pela metade, dobrar o tamanho da linha divide pela metade de novo, e adicionar uma segunda aplicação escrevendo na mesma taxa divide mais uma vez. A aritmética é trivial e é nas entradas que está o trabalho de verdade.

Janela de retenção costuma ser especificada antes de a taxa ser conhecida, o que inverte o cálculo: divida a capacidade exigida pelos dias, e a resposta é o orçamento diário dentro do qual o sistema precisa ficar. Trinta dias a cerca de 87 GB por dia somam quase três terabytes, e essa é a cifra a comparar contra o pool antes de alguém escrever uma política de retenção que o armazenamento não consegue honrar.

Texto estruturado comprime bem porque se repete: carimbo de tempo num formato fixo, nome de campo repetido, um vocabulário pequeno de modelos de mensagem. Taxas de cinco para um ou melhor são comuns em dado de log, e a cifra exata depende do conteúdo e do algoritmo, não de nada derivável do tamanho. Esse fator único muda uma estimativa de retenção mais que todas as outras entradas somadas.

Também precisa ser aplicado no ponto certo. Compressão acontece do lado armazenado, então a contagem de registro e a taxa de ingestão estão em kilobyte sem comprimir, enquanto a capacidade está em kilobyte comprimido. Dividir uma taxa sem compressão por uma capacidade comprimida sem a razão no meio dá uma resposta errada pelo fator de compressão inteiro, um erro de centenas por cento, não os dez que a unidade desta página vale.

Um registro armazenado raramente é só a própria carga útil. Bancos de dados acrescentam cabeçalho por linha, índice secundário proporcional às colunas que cobre, log de escrita antecipada que guarda mudanças recentes em dobro, e réplicas que multiplicam tudo pelo fator de replicação. Sistemas de busca guardam um índice invertido que pode chegar perto do tamanho dos próprios documentos. Nada disso aparece na cifra em kilobyte que alguém mediu numa amostra.

O método confiável é parar de estimar os componentes e medir o sistema. Carregue uma quantidade conhecida de registros numa instância representativa, leia o tamanho ocupado, e divida. O resultado é uma cifra de byte por registro que já inclui todo custo extra que o software impõe, e pode ser multiplicada para qualquer escala com muito mais confiança que uma soma de palpites sobre índice.

Use o fator exato para converter tebibyte em kilobyte, porque é de graça e evita que os dez por cento se infiltrem sem querer. Depois arredonde a resposta com força. Uma estimativa de retenção construída sobre um tamanho médio de registro, uma taxa média e uma razão de compressão presumida não sustenta quatro algarismos significativos, e relatar um convida quem vier depois a planejar contra um número que nunca foi tão firme assim.

A forma honesta da resposta é uma faixa com as suposições anexadas: em torno de duas semanas sem compressão, em torno de três meses numa taxa de oito para um, presumindo um kilobyte por linha e mil linhas por segundo. Cada uma dessas entradas pode ser conferida e corrigida depois, o que uma cifra única não permite.

Um terabyte são exatamente um bilhão de kilobyte redondo, sem fração nenhuma. Um tebibyte são um número consideravelmente maior e nada redondo. Essa diferença de arredondamento é uma pista confiável ao ler a planilha de outra pessoa: uma linha de capacidade mostrando um bilhão redondo de kilobyte foi derivada de um terabyte decimal, seja lá o que o cabeçalho da coluna afirme, e uma linha com um número quebrado veio de um relatório de pool binário.

Vale rodar essa conferência em qualquer documento de dimensionamento que passou por mais de uma pessoa. Convenções misturadas numa única planilha são comuns, porque a capacidade costuma vir de um sistema e a taxa de outro, e os dez por cento resultantes costumam ser atribuídos a sobrecarga em vez de aritmética.

A aritmética de retenção presume que registro expirado para de ocupar espaço, e a maioria dos motores de armazenamento não funciona assim. Linhas marcadas para apagar ficam no disco até uma passagem de compactação rodar, segmento de log é removido inteiro em vez de linha por linha, e um layout do tipo copiar-ao-escrever mantém bloco antigo vivo enquanto um instantâneo referenciar. O estado permanente, portanto, é maior do que a janela de retenção sugere.

O tamanho do excesso depende de com que frequência a recuperação de espaço roda. Onde um sistema compacta diariamente, o excesso é mais ou menos um dia de ingestão, insignificante contra um pool grande. Onde roda semanalmente, ou só quando um limiar é cruzado, o excesso pode ser uma fração substancial da janela e precisa ser somado ao dimensionamento em vez de descoberto quando o pool enche.

Um cálculo de retenção deveria registrar cinco coisas: a capacidade e sua unidade, o tamanho por registro e como foi obtido, a taxa, a suposição de compressão, e a janela resultante. Qualquer um dos cinco pode mudar, e um documento que carrega todos pode ser atualizado num minuto. Um que carrega só a conclusão precisa ser refeito do zero, geralmente por alguém que vai fazer suposições diferentes.

Declarar a unidade explicitamente em toda cifra de capacidade é a parte mais frequentemente pulada e a que causa mais problema. Um pool descrito com um número em base binária e o mesmo número em base decimal ficam bilhões de kilobyte distantes um do outro — a um kilobyte por registro, isso é uma diferença de bilhões de registros numa resposta que parecia ser sobre armazenamento e não sobre unidade.