TiB を kB に変換

1 テビバイトは 1,024 ギビバイトです。テラバイトとの隔たりは階段を上がるごとに開いていきます。キロで 2.4 %、メガで 4.9 %、ギガで 7.4 %、テラで 10 %。

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

こちら向きの計算は掛け算で、しかも整数です。テビバイト 1 つはちょうど 1,099,511,628 キロバイト。この 1,099,511,628 は近い値に落ち着いた測定値ではなく、定義です。

だからこれは、暗算する価値のある数少ない計算のひとつです。検算もできます。割り戻せば、始めた数にきっかり戻るはずです。余地はいっさい残りません。

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

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

この 2 つの単位の間には 9 桁の開きがあり、それをまたぐ理由はほぼ常に件数を知りたいからです。ログの行が何行入るか。文書が何件入るか。今のペースで何日分の保持期間になるか。1 テビバイトは 1,099,511,627.776 kB で、実用上はおよそ 11 億件の 1 キロバイトレコードです。これは覚えておく価値がある数字で、こうした問いのほとんどを 1 回の割り算に変えてくれます。

レコードあたり 2 キロバイトならおよそ 5 億 4,980 万件、5 キロバイトならおよそ 2 億 1,990 万件、0.5 キロバイトならおよそ 22 億件です。この 3 つの間には 10 倍の開きがあり、それはすべてレコードあたりのサイズによって決まっていて、単位の接頭辞の選び方が答えに与える影響はわずか 1 割ほどです。この順序こそがこの換算からいちばん役立つ形で持ち帰れることです。レコードのサイズさえ正しく押さえれば、接頭辞は勝手に片付きます。

毎秒 1,000 行、1 行あたり 1 キロバイトのシステムは 1 秒あたり 1 メガバイト、1 日あたり 86.4 GB を書き込みます。したがって無圧縮の 1 テビバイトはおよそ 12.7 日をカバーします。行のレートを 2 倍にすればこの日数は半分になり、行のサイズを 2 倍にしても半分になり、同じレートで書き込む 2 つ目のアプリケーションを加えればさらに半分になります。算数自体は単純で、実際の作業は入力値にあります。

保持期間はレートがわかる前に指定されることが多く、その場合は計算が逆向きになります。必要な容量を日数で割れば、システムが守らなければならない 1 日あたりの予算が出ます。30 日、1 日あたり 86.4 GB なら 2.59 TB、つまり 2.36 TiB で、これが誰かが保持ポリシーを書く前にプールの容量と照らし合わせるべき数字です。

構造化されたテキストはよく圧縮できます。決まった形式のタイムスタンプ、繰り返されるフィールド名、少ない語彙のメッセージテンプレートなど、繰り返しが多いからです。ログデータで 5 対 1 かそれ以上の圧縮率は珍しくなく、正確な数字は内容とアルゴリズム次第で、サイズから導き出せるものではありません。この 1 つの係数だけで、保持期間の見積もりはほかのどの入力よりも大きく動きます。

この係数は正しい場所に適用する必要もあります。圧縮は保存側で起きるので、件数と取り込みレートは無圧縮のキロバイトで測られ、容量は圧縮後のキロバイトで測られます。その間に圧縮率を挟まずに無圧縮のレートを圧縮後の容量で割ると、この単位の話全体が持つ 1 割の誤差よりはるかに大きい、何百パーセントもの誤りになります。

保存されるレコードは、そのペイロードだけで済むことはめったにありません。データベースは行ごとのヘッダーを追加し、対象とする列に比例したセカンダリインデックスを持ち、直近の変更を二重に保持する先行書き込みログを持ち、レプリカは全体をレプリケーション係数分だけ増やします。検索システムは文書とほぼ同じ規模になり得る転置インデックスを保存します。これらはどれも、サンプルから測ったキロバイトの数字には現れません。

確実な方法は、構成要素を推測するのをやめ、実際のシステムを測ることです。既知の件数を代表的な構成に投入し、占有された容量を読み、それを件数で割ってください。得られる「レコードあたりのバイト数」にはソフトウェアが課すあらゆるオーバーヘッドがすでに含まれていて、それをどんな規模にも掛け算で拡張できます。個々の要素を推測して積み上げるより、はるかに信頼できます。

正確な係数——1 テビバイトあたり 1,099,511,627.776 kB——は無料で使えるので使ってください。1 割のずれが入り込むのを防いでくれます。ただしその先の答えは大きく丸めてください。平均レコードサイズと平均レート、想定した圧縮率をもとに組み立てた保持期間の見積もりは、有効数字 4 桁を支えるものではなく、それを報告してしまうと、下流の誰かがもう固まっていない数字を前提に計画を立ててしまいます。

正直な答えの形は、前提を添えた幅を持たせることです。無圧縮でおよそ 2 週間、8 対 1 の圧縮でおよそ 3 か月、1 行あたり 1 キロバイト、毎秒 1,000 行という前提のもとで、というように示してください。この形なら、入力値はどれも後から確認して修正できますが、12.7 日という単一の数字ではそれができません。

1 テラバイトはちょうど 1,000,000,000 kB——端数のない丸い 10 億——です。1 テビバイトは 1,099,511,627.776 です。この丸さの違いが、他人の作ったスプレッドシートを読むときの信頼できる手がかりになります。丸い 10 億キロバイトを示す容量の行は、列見出しが何と書いてあろうと 10 進法のテラバイトから来ていて、1.0995 倍の端数が付いた行はプールの容量報告から来ています。

この確認は、複数人の手を経たサイジング資料には行う価値があります。1 つのシートの中で慣習が混在するのはよくあることです。容量はあるシステムから来て、レートは別のシステムから来ることが多く、その結果生じる 1 割の差は算数の問題としてではなく、オーバーヘッドのせいだと片付けられがちです。

保持期間の算数は、期限切れのレコードがすぐに容量を空けるという前提に立っていますが、多くのストレージエンジンはそう動きません。削除対象としてマークされた行はコンパクションやクリーンアップの処理が走るまでディスク上に残り、ログセグメントは行単位ではなくまとめて削除され、コピーオンライトのレイアウトはスナップショットが参照している限り古いブロックを残します。つまり定常状態の容量は、保持期間の想定より大きくなります。

この超過分の大きさは、回収処理がどれだけの頻度で走るかに左右されます。毎日コンパクションを行うシステムでは超過はおよそ 1 日分の取り込み量にとどまり、86.4 GB/日なら 0.08 TiB でほとんどのプールにとって無視できる量です。毎週、あるいは閾値を超えたときだけ実行するシステムでは、超過はプールのかなりの割合になり得るため、後からプールが満杯になって気づくのではなく、あらかじめサイジングに加えておく必要があります。