保存量

予約1件の大きさから始める

保存量は、残しておくデータが何バイトになるかの見積もりです。席の予約1件には、予約ID、利用者ID、公演ID、席番号、予約日時などが入ります。

まず予約1件を512バイトと仮置きします。本文では単位をそろえるため、1MB を100万バイト、1GB を10億バイトとして計算します。

最初は、数百バイトか数万バイトかという桁をつかみます。少し違うだけで結論が変わるときは、実際の予約データを保存して大きさを測ります。

予約本体の項目が増えたり、長い文字列が入ったりすれば1件の大きさも変わります。仮の値と、何を含めたかを一緒に残すと後で直せます。

件数と残す期間を掛ける

保存量は、1件のバイト数に1日の新規件数と保存日数を掛けて求めます。ここでは毎日同じ件数が増え、期間中は消さないと仮定します。

DAU 3万人、1人6回なら、要求は1日18万回です。ただし空席を見る要求は予約の行を増やさないので、この18万回をそのまま保存件数には使いません。

ここでは予約要求のうち、席を確保して新規予約として保存するものを1日3000件と仮置きします。要求が届く回数と、保存される件数は別の前提です。

要求数はサーバーが処理する回数で、保存件数は増える予約の数です。1人が空席を何度見ても、予約を1件確定するなら本体は1件だけ増えます。

操作の記録を残すなら、その分はログとして別に見積もります。要求数と予約件数を分けておけば、同じ操作を本体として数えすぎずに済みます。

予約サービスで解いてみる

1件512バイト、1日3000件の予約を365日残すとします。まず1日分を出し、次に保存日数を掛けて1年分を求めます。

1日の本体 = 512バイト × 3000件 = 1536000バイト
1年の本体 = 1536000 × 365 = 560640000バイト
1年の本体 ≒ 561MB ≒ 0.56GB

予約本体だけなら1年で1GBに届きません。この量だけを理由に、最初からデータを複数の保存先へ分ける必要はないと判断できます。

本体のほかに、操作履歴や検索用の索引が増えます。また、同じデータを複製して持つなら、コピーを含む保存量を数える必要があります。

ログが本体の3倍増えるなら、本体と合わせて4倍です。それを合計3つのコピーで持てばさらに3倍となり、「増える量」と「全体の量」を分けて掛けます。

月5万円の予算と比べる前に、本体、履歴、索引、複製のどこまでを含めた数字かを書きます。含めるものが違う見積もりは、そのまま比較できません。