Convertir des Tio en ko

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.

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.

Dans ce sens, l'opération est une multiplication, et par un nombre entier : un tébioctet fait 1 099 511 628 kilooctets, exactement, et 1 099 511 628 est la définition, pas une mesure tombée juste.

C'est donc une des rares conversions qui valent le coup de tête, et le résultat se vérifie : divisez en sens inverse et vous devez retomber exactement sur le nombre de départ, sans reste à justifier.

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.

Neuf ordres de grandeur séparent ces deux unités, et la raison de les traverser est presque toujours un compte. Combien de lignes de journal tiendront. Combien de documents. Combien de jours de rétention au rythme actuel. Un tébioctet vaut 1 099 511 627,776 ko, ce qui pour toute fin pratique est 1,1 milliard d’enregistrements d’un kilooctet chacun — un chiffre qui vaut la peine d’être retenu parce qu’il transforme la plupart de ces questions en une seule division.

À deux kilooctets par enregistrement cela donne 549,8 millions, à cinq kilooctets 219,9 millions, et à un demi-kilooctet 2,2 milliards. L’étalement sur ces trois exemples est d’un facteur dix, porté entièrement par la taille par enregistrement, tandis que la question d’unité déplace la réponse de 10 %. Cet ordre est ce qu’il y a de plus utile à tirer de cette conversion : obtenez la bonne taille d’enregistrement et le préfixe se débrouillera tout seul.

Un système qui écrit mille lignes par seconde à un kilooctet chacune produit un mégaoctet par seconde, ce qui fait 86,4 Go par jour. Un tébioctet de capacité non compressée couvre donc 12,7 jours. Doubler le rythme de lignes le divise par deux, doubler la taille de ligne le divise encore par deux, et ajouter une seconde application qui écrit au même rythme le divise une fois de plus. L’arithmétique est triviale et les paramètres sont là que se trouve le travail.

Les fenêtres de rétention sont en général spécifiées avant que le rythme ne soit connu, ce qui inverse le calcul : divisez la capacité requise par les jours, et la réponse est le budget quotidien auquel le système doit se tenir. Trente jours à 86,4 Go par jour font 2,59 To, ou 2,36 Tio, et c’est le chiffre à comparer au volume avant que quiconque n’écrive une politique de rétention que le stockage ne peut pas honorer.

Le texte structuré se compresse bien parce qu’il se répète : des horodatages dans un format fixe, des noms de champs répétés, un petit vocabulaire de modèles de messages. Des taux de cinq pour un et au-delà sont ordinaires pour des journaux, et le chiffre exact dépend du contenu et de l’algorithme plutôt que de quoi que ce soit qu’on puisse dériver d’une taille. Ce seul facteur change une estimation de rétention plus que tous les autres paramètres réunis.

Il faut aussi l’appliquer au bon endroit. La compression a lieu côté stockage, donc le compte d’enregistrements et le rythme d’ingestion sont en kilooctets non compressés tandis que la capacité est en kilooctets compressés. Diviser un rythme non compressé par une capacité compressée sans le taux au milieu donne une réponse fausse du facteur de compression entier, ce qui est une erreur de centaines de pour cent plutôt que des 10 % que valent les unités de cette page.

Un enregistrement stocké est rarement seulement sa charge utile. Les bases de données ajoutent des en-têtes par ligne, des index secondaires proportionnels aux colonnes qu’ils couvrent, des journaux de transactions qui détiennent les modifications récentes en double, et des répliques qui multiplient le tout par le facteur de réplication. Les moteurs de recherche stockent un index inversé qui peut approcher la taille des documents qu’il décrit. Rien de tout cela n’apparaît dans le chiffre en kilooctets que quelqu’un a mesuré sur un échantillon.

La méthode fiable est d’arrêter d’estimer les composants et de mesurer le système. Chargez un nombre connu d’enregistrements dans une instance représentative, lisez la taille occupée, et divisez. Le résultat est un chiffre d’octets par enregistrement qui inclut déjà tout l’overhead que le logiciel impose, et il peut être multiplié à n’importe quelle échelle avec beaucoup plus de confiance qu’une somme d’hypothèses sur les index.

Utilisez le facteur exact — 1 099 511 627,776 ko par tébioctet — parce que c’est gratuit et que cela empêche les 10 % de s’y glisser. Arrondissez ensuite la réponse franchement. Une estimation de rétention bâtie sur une taille moyenne d’enregistrement, un rythme moyen et un taux de compression supposé ne supporte pas quatre chiffres significatifs, et en rapporter un invite quelqu’un en aval à planifier sur un chiffre qui n’a jamais été aussi ferme.

La forme honnête de la réponse est une plage avec ses hypothèses attachées : environ deux semaines non compressé, environ trois mois à huit pour un, en supposant un kilooctet par ligne et mille lignes par seconde. Chacun de ces paramètres peut être vérifié et corrigé plus tard, ce qu’un chiffre unique de 12,7 jours ne permet pas.

Un téraoctet fait exactement 1 000 000 000 de ko — un billion net, sans fraction nulle part. Un tébioctet fait 1 099 511 627,776. Cette différence de netteté est un indice fiable lorsqu’on lit le tableur de quelqu’un d’autre : une ligne de capacité affichant un billion net de kilooctets a été dérivée d’un téraoctet décimal, quoi que dise l’en-tête de colonne, et une ligne affichant 1,0995 milliard provient d’un rapport de volume.

Le test vaut la peine d’être lancé sur tout document de dimensionnement qui est passé par plus d’une personne. Les conventions mélangées dans une même feuille sont fréquentes, parce que la capacité vient généralement d’un système et le rythme d’un autre, et les 10 % qui en résultent sont en général attribués à l’overhead plutôt qu’à l’arithmétique.

L’arithmétique de la rétention suppose que les enregistrements expirés cessent d’occuper de l’espace, et la plupart des moteurs de stockage ne fonctionnent pas ainsi. Les lignes marquées pour suppression restent sur le disque jusqu’à ce qu’un compactage ou une passe de nettoyage tourne, les segments de journal sont retirés entiers plutôt que ligne par ligne, et les dispositions en copie à l’écriture gardent les anciens blocs en vie tant qu’un instantané les référence. L’état stable est donc plus grand que la fenêtre de rétention ne le laisse entendre.

La taille de l’excès dépend de la fréquence à laquelle la récupération tourne. Quand un système compacte tous les jours, le dépassement est d’environ une journée d’ingestion, ce qui à 86,4 Go par jour fait 0,08 Tio et est négligeable face à un grand volume. Quand il tourne à la semaine, ou seulement quand un seuil est franchi, le dépassement peut être une fraction substantielle de la fenêtre et doit être ajouté au dimensionnement plutôt que découvert au moment où le volume se remplit.

Un calcul de rétention devrait noter cinq choses : la capacité et son unité, la taille par enregistrement et comment elle a été obtenue, le rythme, l’hypothèse de compression, et la fenêtre qui en résulte. N’importe laquelle des cinq peut changer, et un document qui les porte toutes peut être mis à jour en une minute. Un qui ne porte que la conclusion doit être refait à partir de zéro, en général par quelqu’un qui fera des hypothèses différentes.

Énoncer l’unité explicitement sur chaque chiffre de capacité est la partie la plus souvent sautée et la partie qui cause le plus de tracas. Un volume de 20 Tio fait 21 990 232 555,52 ko et un volume de 20 To fait 20 000 000 000 — deux milliards de kilooctets d’écart, ce qui à un kilooctet par enregistrement représente deux milliards d’enregistrements de différence dans une réponse qui avait l’air de parler de stockage plutôt que d’unités.