Resumo

  • O Cold Vault da IBM estabelece tamanho mínimo faturável de 256 KB por objeto e prazo mínimo de armazenamento de 90 dias. Um objeto hipotético de 4 KB gera uma base de capacidade 64 vezes maior.
  • O custo total também depende de tarifa, tempo e operações. Juntar objetos pode reduzir a repetição do mínimo, mas exige resolver acesso individual, atualização, exclusão e recuperação dentro dos pacotes.

O condomínio chega antes do desconto

O arquivo é pequeno, mas sua acomodação na fatura é generosa. Um objeto de 4 KB no Cold Vault, do IBM Cloud Object Storage, encontra um mínimo faturável de 256 KB. A informação ocupa um canto. A cobrança reserva o quarto inteiro.

Os 4 KB são uma hipótese para fazer a conta. Os 256 KB constam das regras publicadas pela IBM, ao lado de um prazo mínimo de 90 dias. O Vault tem limites de 128 KB e 30 dias. Standard e Smart Tier não têm tamanho ou prazo mínimo e não cobram recuperação de dados. Requisições e transferências para a internet pública continuam sendo itens separados.Classes de armazenamento

A divisão produz um número forte: 256 sobre 4 é 64. Trata-se da relação entre a base de capacidade faturável e o conteúdo daquele objeto no Cold Vault. No Vault, seria 32. A fatura completa ainda precisa da tarifa, do período e das operações. A aritmética perde utilidade se o multiplicador da base virar, no título de uma apresentação, multiplicador automático da despesa inteira.

Considere um conjunto formado só por objetos de 4 KB e que cumpra o prazo mínimo. Para o custo de capacidade do Cold Vault ficar abaixo do Standard, sua tarifa de capacidade precisa ser menor que um sessenta e quatro avos da tarifa do Standard. A proposta comercial aplicável pode responder se isso acontece. O adjetivo usado para vender a classe não resolve a divisão.

O total de bytes esconde a quantidade de compras

A previsão de orçamento costuma começar pelo volume: quantos dados existem, quanto devem crescer. Com mínimo por objeto, falta contar em quantas partes esse volume foi dividido.

Os mesmos registros podem ser guardados individualmente ou reunidos em objetos maiores. Separados, cada pequeno objeto enfrenta seu próprio piso. Agrupados, cada pacote enfrenta um piso. O conteúdo continua igual, mas a arquitetura passa a comprar outra quantidade de unidades faturáveis.

Nem a média basta. Alguns objetos enormes podem elevar o tamanho médio e esconder uma população numerosa de objetos pequenos. A distribuição por tamanho mostra o que interessa: quantos objetos estão em cada faixa e quanta capacidade faturável produzem. Para cada objeto, toma-se o maior valor entre tamanho real e mínimo da classe; depois se soma. Aplicar um único mínimo ao volume inteiro do bucket seria fazer outra conta.

A IBM explica que o uso de uma classe é agregado entre os buckets de uma instância. Essa agregação contábil não transforma os mínimos individuais em um fundo comum, no qual arquivos grandes compensariam o espaço dos pequenos. A documentação também separa armazenamento, requisições e transferência pública.Regras de cobrança

A compressão pode então produzir uma pequena comédia corporativa. A engenharia apresenta uma redução real de bytes. O financeiro procura a queda correspondente e não a encontra. Se o objeto já estava abaixo de 256 KB, comprimi-lo mais mantém o mínimo faturável do Cold Vault. As duas equipes podem estar certas: uma reduziu conteúdo, a outra paga uma base que ficou parada.

Pacote barato precisa de endereço interno

Juntar objetos parece a solução evidente. Menos objetos significam menos ocorrências do piso. Só que o objeto independente carregava algumas facilidades: um nome, uma leitura própria, uma atualização e uma exclusão delimitadas.

Depois do empacotamento, a aplicação precisa saber onde está cada registro. Precisa manter um índice e decidir como mudanças e exclusões chegam ao conteúdo armazenado. Conforme o formato e a forma de acesso, pode ler apenas uma parte ou precisar movimentar mais dados. O pacote maior não traz embutida toda a flexibilidade anterior.

Um registro alterado com frequência torna o custo visível. Uma mudança pequena pode provocar a regravação de um conjunto maior. Uma exclusão individual pede um mecanismo efetivo dentro do pacote. A recuperação depende de conteúdo e índice coerentes. O ganho em capacidade pode acabar pagando mais requisições, leituras ou trabalho operacional.

Há motivos econômicos para os dois desenhos. A independência dos registros pode valer o preço; dados que sempre viajam juntos podem funcionar bem em pacotes. A comparação útil inclui o serviço completo e o esforço necessário para entregá-lo. Uma coluna menor na planilha não representa sozinha um sistema mais barato.

Mudar de classe também tem trabalho. A IBM informa que a classe é escolhida na criação do bucket e não pode ser alterada no bucket existente. Os objetos precisam ser movidos ou copiados para outro bucket com a classe desejada.Configuração de classes Regras dos buckets

A promessa de trocar depois, portanto, inclui destino, cópia, referências das aplicações e conferência do resultado. Preservar a opção de mudar é importante. Seu valor fica mais bem calculado quando o orçamento já reconhece o custo de exercê-la.

Comprar depois do censo

Para calcular a economia de um cliente específico faltam sua distribuição de tamanhos, seus prazos de retenção, seu padrão de leitura e a cotação aplicável.

A ordem de compra pode ser corrigida desde já. Primeiro conhecer os objetos, depois comparar tarifas. Pequenos registros duradouros e pequenos registros apagados rapidamente têm comportamentos econômicos diferentes. Dados quase nunca lidos ainda podem exigir acesso individual quando chega a hora. A etiqueta “dados frios” acomoda diferenças demais para funcionar como cálculo de orçamento.

A IBM publica os limites. O comprador tem material para fazer a conta antes de assinar. O desencontro aparece quando desenvolvimento determina quantas unidades faturáveis serão criadas e compras negocia apenas o preço de cada uma. Os dois departamentos podem comemorar sua eficiência. A fatura cobra o encontro das duas decisões.

Fontes originais

As regras vêm dos documentos oficiais da IBM citados. O registro de membros do RIPE NCC é usado somente para verificar a identidade de International Business Machines Corporation no diretório. O objeto de 4 KB é uma hipótese explícita.