kB を GiB に変換

1 キロバイトは、標準化団体が定義すれば 1,000 バイトで、OS が定義すれば 1,024 バイトです。このページは 1,000 で計算します。1,024 のほうはキビバイトという名前を持っています。

1 ギビバイトは 1,073,741,824 バイトで、ギガバイトより 7 % ほど大きい値です。Windows はギビバイトで測りながら、それを「GB」と表示します。「容量が足りない気がする」という疑問のからくりは、まるごとこれです。

倍率は 0.000001 で、これをそのまま持ち歩く人はまずいません。0.000001 に丸めると 0.14 % ずれます。小さい数では見えもしませんが、1,000 kB あたりで、ずれは丸ごと 1 単位になります。

丸める前に知っておく価値があるのは、ずれの大きさそのものではなく、それを無視できなくなる地点のほうです。それより下なら短い倍率が賢明で、それより上なら上の入力欄を使ってください。あちらは書き出す前に丸めません。

GiB 1 つはひとつ下の単位の 1,024 倍で、GB 1 つは 1,000 倍です。このページでは 1073741.824 kB と 1000000 kB の差——7.4 %——になり、段を上がるごとにこの隔たりは開いていきます。写真 1 枚では丸め誤差でしかないものが、ハードディスクでは目に見える割合になるのはそのためです。

「容量が消えた」という話の中身は、これだけです。GB で売られたディスクには、書いてあるとおりのバイト数が入っています。それを 1,000 ではなく 1,024 で割り、名前は GB のまま表示しているのが Windows です。macOS は 10.6 以降ディスクの容量を十進の単位で数えているので、同じディスクが 2 台のパソコンで違う大きさに見えることがあります。減ったものはなく、丸めているのでもありません。同じバイト数に、名前が 2 つあるだけです。

1 件あたりのサイズはほぼ常に 10 進法のキロバイトで届きます。1 行のログは 1.2 kB、1 件の JSON レコードは 4 kB、添付なしのメールは 15 kB、地図タイルは 30 kB。これらは内容の測定値で、バイトを数えて 1,000 で割ることで生まれ、それを作る人はストレージではなくペイロードのことを考えています。

それらの項目が収まるべき予算は、まったく別のものから報告されます。ボリューム、メモリーキャッシュ、コンテナの上限、保持ポリシーはどれもギビバイトで表され、それを報告するソフトウェアが 1,024 のべき乗で計算しているからです。ですからこの変換は、内容の測定と容量の測定の接合点にあり、100 万倍という接頭辞の差と 7.37 パーセントという単位体系の差の両方を越える必要があります。

1 ギビバイトは 1,073,741.824 kB を保持します。おおまかな「1 ギビバイトあたり 100 万キロバイト」という近似は 6.9 パーセントずれており、あるキロバイトの山が必要とするギビバイト数を過大に見積もります。それは間違ってもまだ安全な方向ですが、それでも誤った数字であることに変わりはありません。代わりに 1.074 百万を使うのに追加の手間はかからず、誤差そのものを取り除けます。

暗算では、1 ギビバイトあたりではなく 1 件あたりで考えるほうがすっきりします。1 kB のアイテムなら 1 ギビバイトあたりおよそ 1,074,000 件、4 kB なら約 268,000 件、30 kB なら約 35,800 件です。比率をキロバイトの数ではなく物の数に変えることで、はるかに検算しやすくなります。レコードの件数は、読み手がすでに感覚を持っている数字だからです。

この形の見積もりの多くは合計値ではなく率として始まり、率のところで算術が驚きをもたらします。毎秒 1 キロバイトは 1 日あたり 86,400 kB、つまり 0.0805 GiB、年間ではおよそ 29.4 GiB です。毎秒 10 kB は年間 294 GiB。毎秒 100 kB——ほどよくおしゃべりなサービス 1 つ分——は年間 2.87 TiB です。

人々が見落としがちなのは、インスタンスあたりで示された率がインスタンス数と保持期間の両方で掛け算されるということです。毎秒 10 kB のサービスが 40 個、90 日保持なら、40 × 0.805 GiB/日 × 90 で 2,898 GiB、つまり常時 2.83 TiB が保持されます。個々の数字はどれもストレージ問題には見えませんでしたが、積は棚一つ分になります。

これははっきり言っておく価値があります。単位変換についてのページはそうしないよう誘惑されるからです。10 進法と 2 進法の間の 7.37 パーセントは本物で、適用すべきです。しかし、1 件あたりのサイズから組み立てた見積もりでは、それはたいてい誤差要因として 4 番目か 5 番目の大きさにすぎません。

それより前にあるのは、測定した項目サイズがフレーミングやヘッダーを含んでいたかどうか、ストアがインデックスを保持していてそれがどれだけ大きいか、データが 2 重・3 重にレプリケーションされているか、圧縮されていてその比率はどれくらいか、保持期間がポリシー上のものか実際に設定されているものか、です。これらはどれも割合ではなく倍率であり、そのどれか一つが答えを丸ごと 2 倍にすることもあります。

ファイルシステムは通常 4 KiB のブロック単位で容量を割り当てます。2 kB のレコードを単独のファイルとして書くと 4,096 バイトを占有し、100 万件なら内容としては 2 GB でもディスク上では 3.81 GiB になります。500 バイトずつだと比率はさらに悪化し、0.5 GB の内容が同じ 4,096,000,000 バイトのディスク占有になり、測定値のおよそ 8 倍です。

同じレコードをログセグメントやデータベースのページ、オブジェクトストアのオブジェクトにまとめて格納すれば、コストはそれ自体のサイズにわずかなフレーミングを足しただけで済み、ブロックの丸めはレコードごとではなくセグメントごとに 1 回だけ発生します。だからこそ、単位変換より先にストレージのレイアウトを確定させる価値があります。丁寧に変換しても、誤ったストレージモデルを掛け合わせれば、間違った量について正確な答えが出るだけです。

テキストはよく圧縮され、ログ行はとくによく圧縮されます。フィールド名が繰り返される構造化テキストでは 5 倍から 10 倍の比率は珍しくありません。それをどの段階で適用するかは、あとで見積もりを検証できるかどうかを左右します。1 件あたりの数字を圧縮し、想定した比率を記録し、それから件数を掛けて変換してください。

逆の順序——ギビバイトに変換してから圧縮比で割る——は同じ数字を出しますが、監査の道筋を失います。ストアの実際の圧縮比が 8 対 1 ではなく 3 対 1 だと分かったとき、見積もりを直す人はどの数字が実測でどの数字が仮定だったのかを見る必要があり、混ぜ合わせた一つの数字はそれを教えてくれません。

役立つ形式は、それぞれ独自の単位を持つ行の連なりです。1 件あたりのキロバイトの実測サイズ、秒あたりの件数、インスタンス数、日数での保持期間、圧縮比、レプリケーション係数、そして最後にバイトでの合計、最後にギビバイトでの合計。7 行、そしてそのどの行も単独で異議を唱えられます。

代わりに、誰かの頭の中で計算を済ませた単一の数字を出すことは、間違っている頻度は変わらないかもしれませんが、間違ったときに直しようがありません。ストレージの見積もりは実際の消費量が乖離するたびに見直され、その見直しに耐えるのは、乖離を見積もり全体ではなく特定の行のせいにできるものだけです。