Convertir des ko en Tio

Un kilooctet vaut 1 000 octets quand c’est un organisme de normalisation qui le définit, et 1 024 quand c’est un système d’exploitation. Cette page compte en 1 000 ; l’unité valant 1 024 s’appelle kibioctet.

Un tébioctet vaut 1 024 gibioctets. L’écart avec le téraoctet grandit à chaque échelon : 2,4 % au kilo, 4,9 % au méga, 7,4 % au giga, 10 % au téra.

Dans ce sens, l'opération est une division, et par un nombre entier : 1 099 511 628 de ces unités entrent dans un tébioctet sans reste. Le seul inconvénient, c'est que les résultats tombent en fractions — un tiers, un douzième — au lieu des chiffres ronds que donne le sens inverse.

Rien ne se perd pour autant : la division est exacte. Si votre résultat refuse de tenir en place en décimal — 0,0833… et compagnie —, c'est la fraction qui transparaît, pas une erreur qui s'installe.

Un TiB vaut 1 024 fois l'unité du dessous ; un TB, 1 000. Sur cette page, c'est l'écart entre 1099511627,776 kB et 1000000000 kB — 10 % — et il grandit à chaque palier : négligeable sur une photo, visible sur un disque dur.

Le mystère de l'espace disque manquant tient tout entier là-dedans, et sur cette page il vaut 10 %. Un disque vendu en TB contient exactement ce qui est annoncé ; Windows divise ensuite par 1 024 au lieu de 1 000, garde le nom décimal, et affiche 1000000000 kB là où la boîte annonçait 1099511627,776 kB. macOS compte ces tailles en unités décimales depuis 10.6, d'où le même disque qui paraît de deux tailles sur deux machines — rien n'a disparu et personne n'arrondit : les mêmes octets portent deux noms.

La prévision a quatre entrées et elles sont toujours les mêmes : la taille d’un enregistrement, combien en arrivent par unité de temps, combien de temps on les garde, et ce par quoi la couche de stockage multiplie cela. La première est en kilooctets parce que c’est l’échelle d’une ligne de journal ou d’un échantillon de métrique. La dernière est en tébioctets parce que c’est ce qu’un volume rapporte. Tout ce qu’il y a entre est une multiplication, et la seule partie difficile est de ne pas changer de système d’unités en cours de route.

Un cas travaillé : un milliard d’enregistrements par jour à 1 ko chacun font 1 000 000 000 000 d’octets par jour, ce qui est un téraoctet, ce que le volume rapportera comme 0,909 Tio. Quatre-vingt-dix jours de cela font 90 To, que le volume rapportera comme 81,85 Tio. Ces deux chiffres décrivent les mêmes données, donc un plan qui calcule 90 dans un système et provisionne 90 dans l’autre est à 8,15 unités de stockage de court — et c’est tout l’ennui que cette paire cause.

Avant de s’inquiéter de 9 pour cent, il faut fixer les facteurs qui en valent plusieurs centaines. La compression est le premier : les journaux structurés et les métriques se réduisent couramment à un cinquième ou un dixième de leur taille brute, donc une prévision qui l’ignore surestime d’un ordre de grandeur. La réplication est le second et va dans l’autre sens : trois copies font trois fois le stockage, et l’erasure coding fait typiquement de 1,2 à 1,5 fois.

Puis viennent les index, qu’il est facile d’oublier parce qu’ils ne sont pas les données. Un magasin de journaux qui indexe des champs ajoute une structure qui peut être une fraction substantielle de la charge utile, et une base de données de séries temporelles garde la sienne. La façon honnête d’établir tout cela est de faire passer un échantillon représentatif à travers le système réel pendant un jour et de mesurer ce qu’il a occupé — une mesure bat n’importe quelle quantité d’estimation, et c’est l’investissement qui rapporte le plus dans ce domaine.

La rétention est d’habitude fixée par habitude ou par le premier nombre que quelqu’un a suggéré, et c’est l’entrée qui a le plus grand levier sur le coût. Diviser la fenêtre par deux divise exactement la taille en régime établi ; la valeur perdue est rarement proportionnelle, parce que l’écrasante majorité des requêtes sur des données opérationnelles remontent des heures ou des jours plutôt que des mois. Voir le chiffre de stockage pour chaque fenêtre candidate côte à côte change la conversation, parce que la décision cesse d’être abstraite.

Là où une fenêtre plus longue est vraiment nécessaire — une obligation d’audit, une comparaison trimestrielle — elle est d’habitude nécessaire pour un sous-ensemble plutôt que pour tout. Diviser le flux pour que la petite partie de valeur soit gardée un an et la masse pendant quinze jours donne l’essentiel du bénéfice pour une fraction de la taille, et c’est une décision qui doit être prise avant que les données ne soient écrites plutôt qu’après, parce qu’après coup le coût de la réorganisation dépasse l’économie réalisée.

Un stockage avec une fenêtre de rétention fixe ne croît pas indéfiniment : il croît jusqu’à ce que les données les plus anciennes commencent à expirer, puis il reste à peu près constant au taux quotidien fois la fenêtre. Ce plateau est le nombre pour lequel dimensionner, et il arrive une période de rétention après le démarrage du système. Dimensionner pour la courbe de croissance plutôt que pour le plateau achète de la capacité qui ne servira jamais ; dimensionner sous le plateau signifie que la politique d’expiration commence à faire votre gestion de capacité à votre place, et cela finit mal.

Le plateau bouge chaque fois que le taux quotidien bouge, et c’est la partie qui mérite d’être surveillée. De la nouvelle instrumentation, une augmentation de trafic ou un niveau de debug laissé en production élèvent tous le taux, et l’effet de stockage apparaît graduellement sur une fenêtre de rétention entière plutôt qu’immédiatement. Un tableau de bord d’octets ingérés par jour prédit le problème ; un tableau de bord d’octets stockés le signale une quinzaine de jours en retard, et la différence entre les deux est ce qui distingue un plan de capacité d’un pompier.

Ils se cachent à la frontière entre le calcul et l’achat. La prévision est faite naturellement en unités décimales, parce que les débits et les tailles d’enregistrement sont décimaux et que l’arithmétique est facile. Le volume est rapporté en unités binaires, parce que c’est ce que font les systèmes de fichiers. Si le plan dit 90 To et que le volume dit 82 Tio, c’est la même quantité et cela ressemble à un manque ; si le plan dit 90 Tio et que 90 To sont provisionnés, c’est un vrai manque de 9 pour cent et cela ressemble à une correspondance.

Le second cas est le dangereux parce que rien ne le signale. Le stockage est acheté en téraoctets décimaux, et une demande de « 90 téraoctets » satisfaite par un fournisseur vendant de la capacité décimale face à un besoin calculé en tébioctets arrive près de 9 To en deçà. Énoncer le besoin en octets sur le bon de commande supprime l’ambiguïté pour le coût d’un seul chiffre supplémentaire, et c’est l’investissement le moins cher disponible sur cette page.

Une prévision est une chaîne de multiplications, et l’arrondi à chaque pas compose dans une direction imprévisible. Débit fois taille fois fenêtre fois réplication fois surcharge d’index, chacun arrondi à deux chiffres, peut atterrir à dix pour cent de la réponse exacte avec chaque étape individuelle paraissant raisonnable. Multipliez les nombres exacts et arrondissez une fois, à la fin, là où l’arrondi est visible et délibéré, parce qu’un arrondi pris tôt est invisible et un pris tard est défendable.

C’est aussi le moment de décider combien de précision la réponse mérite. Une prévision de stockage vaut au mieux deux chiffres significatifs, parce que les entrées sont des estimations et que le coefficient de compression à lui seul porte plus d’incertitude que tout le reste combiné. Ce qu’elle ne vaut pas, c’est la fausse précision générée par un tableur, parce qu’un chiffre cité à cinq chiffres invite un lecteur à le traiter comme mesuré plutôt que comme projeté, et l’invitation est presque toujours acceptée.

Il faut environ 1,1 milliard de kilooctets pour faire un tébioctet, donc un repère utile est qu’un kilooctet par seconde, soutenu, fait environ 31,5 Go par an — grossièrement 29,4 Gio — et mille kilooctets par seconde font environ 31,5 To par an, ou 28,7 Tio. La plupart des prévisions à cette échelle peuvent être vérifiées contre ces deux nombres en quelques secondes, et une réponse qui n’est proche d’aucun de leurs multiples a une erreur quelque part dans la chaîne. Le même repère fonctionne vers le bas : cent octets par seconde font environ 3,15 Go par an, ce qui est où se situe d’habitude la télémétrie par appareil avant d’être multipliée par le parc.

L’autre vérification est la direction de la correction. Convertir de décimal en binaire rend toujours le nombre plus petit, à cette étendue de 9 pour cent, donc un chiffre en Tio qui sort plus grand que le chiffre en To a été multiplié là où il aurait fallu diviser. C’est l’erreur arithmétique la plus fréquente dans cette catégorie et la plus facile à attraper, parce qu’elle n’a pas besoin de la réponse exacte pour être visible, et le test ne coûte que quelques secondes de calcul mental.