データベース容量計算機｜行数・列数・平均バイトから実務推定

DB容量計算式と実務調整

データサイズ = 行数 × 列数 × 平均バイト数
インデックスサイズ = データサイズ × 30%
実容量 = データ + インデックス + オーバーヘッド20〜40%
バックアップ込み = 実容量 × (1 + バックアップ倍率1〜2)

DB容量の第一近似は「行数×列数×平均バイト数」ですが、実際の本番環境では以下の要素で容量が膨らみます。

• インデックス：主キー・ユニーク・複合インデックスで、テーブル本体の20〜40%（目安30%）
• DBMSオーバーヘッド：ページヘッダ、レコードヘッダ、フリースペース、統計情報等で20〜40%
• WAL/バイナリログ：更新頻度に応じて日次1〜10GBが蓄積（保管期間×日次量）
• 一時ファイル：クエリソート、テンポラリテーブルで数GB〜数十GB
• バックアップ：フル1回＋差分・トランザクションログで実容量の1〜2倍

1000万行×20列×50byte/列のテーブルならデータ約10GB、インデックス込み約13GB、実容量17〜18GB、バックアップ込み30〜50GBが現実的な見積もりです。

設計フェーズでは3年後の想定行数×1.5のキャパシティで初期設計するのがベストプラクティス。データが予想以上に増えた場合の容量拡張・シャーディング検討ラインを事前に決めておく必要があります。

DBMS別の容量特性

PostgreSQL・MySQL InnoDBが最も一般的で、企業内基幹系はOracle・SQL Server、分析用途はマネージド型の列指向DWH、大規模分散はCassandraやクラウドのマネージドKVSが選ばれます。用途に合わせたDBMS選定が容量・性能・コスト最適化の第一歩です。

データ型別バイトサイズ

設計時は必要最小限のデータ型を選ぶことが容量削減の基本。フラグをINTで持つとTINYINTの4倍の容量を無駄に消費します。文字列は用途に応じてCHAR/VARCHAR/TEXTを使い分け、TEXTは検索インデックスが張りにくい点も考慮が必要です。

インデックス設計と容量影響

インデックスは検索を高速化しますが、容量とINSERT/UPDATE性能に負の影響を与えます。「必要な検索・結合・ソートに必要な最小限」が設計原則です。

インデックス数の目安は1テーブルあたり3〜5個。8個を超えるとINSERT/UPDATE性能が明らかに低下します。使用頻度の低いインデックスは削除の検討を（pg_stat_user_indexes、sys.dm_db_index_usage_stats等で確認可能）。

パーティショニング・シャーディング

単一テーブル・単一サーバの容量には限界があり、1テーブル1TB、単一DBサーバ10TBが分割検討ラインとされます。

• パーティショニング（垂直/水平）：単一DB内でテーブルを分割。範囲（日付）・ハッシュ・リスト・複合パーティションが選択可能。PostgreSQL 10+、MySQL 5.5+、Oracle、SQL Server全対応。
• シャーディング：複数DBサーバに分散。顧客ID・地域・ユーザーID等でシャードキーを設計。運用は複雑化するがスケーラビリティは無限に近い。大規模SNSが自作した分散フレームワークや、分散DBに標準搭載されたシャーディング機能が代表例。
• 読み取り専用レプリカ：読み取り負荷分散に有効。MySQL・PostgreSQLの標準機能で構成でき、主要クラウドのマネージドRDBなら管理画面から数クリックで作成できます。
• アーカイブ：3年前・5年前の古いデータは低コストのアーカイブ用オブジェクトストレージ（$0.004〜0.01/GB/月、取り出しに時間がかかる代わりに標準ストレージの1/10以下）へ移動。ホット・ウォーム・コールドの3層設計が実務標準。

シャーディングは後付け実装が非常に高コストのため、想定容量が1TB超なら初期設計時にシャードキー戦略を検討しておくべきです。「マルチテナントSaaSはtenant_idシャード」「B2CはユーザーID範囲シャード」等が定石です。

クラウドDB料金試算

クラウドDB料金はストレージ＋インスタンス＋IOPS＋データ転送の合算で決まり、ストレージ単体は全体の10〜30%程度。インスタンス（CPU/RAM）が最も大きなコスト要因で、100GB規模のDBならインスタンス費用が月$200〜$2,000となります。

コスト最適化の実務ではリザーブドインスタンス（1〜3年契約で40〜70%割引）、サーバレス型RDBの自動スケール、開発環境の休止機能、コールドデータのアーカイブストレージ移行等を組み合わせます。単価は改定されるため、契約前に各社の料金表で最新値を確認してください。

バックアップ設計

バックアップ容量は本番DBの1〜2倍が目安。3-2-1ルール（3コピー、2種類のメディア、1つはオフサイト）がベストプラクティスです。

• フルバックアップ：週1回、実容量の1倍。日曜深夜等の低負荷時間帯に。
• 増分/差分バックアップ：日次、実容量の1〜10%程度。RPO（目標復旧時点）に応じて設計。
• トランザクションログ：15分〜1時間毎、日次数GB。ポイントインタイムリカバリに必須。
• オフサイト：異地リージョン・別クラウドへ複製。BCP（事業継続計画）に対応。
• 圧縮：バックアップは圧縮率50〜80%が期待でき、実容量の30〜60%まで削減可能。

主要クラウドのマネージドRDBは、自動バックアップを35日程度まで追加料金なしで保管できるのが一般的で、それを超える分はオブジェクトストレージ料金が別途かかります。保管期間の設定幅はサービスにより7日〜365日、長期保持ポリシーを備えたものなら最大10年まで伸ばせます。

実務ケーススタディ（5例）

実際の設計現場で想定される5つのケースで、DB容量とインフラ選定を試算します。

小規模なら単一VPS、中規模はマネージドRDB、大規模はシャーディングまたは列指向分析DB、IoTは時系列DB。用途別に最適解が異なる点に注意して設計します。

目的別の活用シーン

容量モニタリングと運用アラート

DB容量は成長率と閾値監視が運用の基本。設計時の想定を実測で追跡し、逸脱時に早期対応します。

• ディスク使用率：80%到達で警告、90%で緊急アラート。各クラウドの標準監視サービスで設定。
• 行数成長率：月次で行数推移を記録、想定より速い成長なら容量拡張・シャーディング前倒し。
• インデックス肥大：pg_stat_user_indexes、sys.dm_db_index_usage_stats等で未使用インデックスを検出、削除。
• WAL/バイナリログ蓄積：更新頻度に応じて日次GBが増える。保管期間の見直しでコスト削減。
• クエリスロー化：p95応答時間の劣化を統計情報更新・EXPLAIN分析で早期対応。
• バックアップ成功率：日次バックアップの成功率100%を維持。失敗時は即再実行＋原因調査。

これらの指標を監視SaaS（APMツール）で統合ダッシュボード化し、DBA・SRE・開発チーム全員が可視化するのがベストプラクティスです。料金は監視対象ホスト数の従量制が主流で、1ホストあたり月$15〜30が相場です。

よくある勘違い・注意点

• データ本体だけで見積もる — 実容量はデータ×1.5〜2倍（インデックス＋オーバーヘッド）が実務値。第一近似の1.5倍以下で見積もると本番運用開始後に容量不足になる典型的な失敗パターンです。
• 3年後を考えない — 「初期50GB」で契約したのに3年後に500GB超という事例は多発。年成長率30〜100%を想定した3年後キャパシティで初期設計するべきです。
• バックアップを忘れる — バックアップ容量は本番の1〜2倍必要。フル＋増分＋トランザクションログ＋オフサイト複製までを見積もりに含めないと、実運用開始後のコスト超過が生じます。
• インデックスを張りすぎ — 「検索が遅いから」と何でもインデックスを張るのはアンチパターン。INSERT/UPDATE性能低下＋容量増の副作用が大きく、1テーブル3〜5個が目安。使用頻度の低いインデックスは削除の検討を。
• シャーディングを後付けで検討 — 「まずは1台で始めて増えたらシャード」は運用不能状態を招きます。1TB超が想定されるなら初期設計でシャードキーを決めておくべきです。マルチテナントならtenant_id、B2CならユーザーID範囲等。
• TEXT/BLOBを何でも入れる — TEXT/BLOBは別領域格納＋インデックス張りにくい特性があり、検索・レポート用途には不向きです。画像・動画はオブジェクトストレージに置き、DB内にはURLのみを持つのが定石です。
• 統計情報を古いまま放置 — DBMSの実行計画は統計情報に依存。ANALYZE/UPDATE STATISTICSを定期実行しないとクエリが劣化し、実容量以上に「体感が遅い」となります。

参考文献・公的資料

データベース設計、容量計画、クラウド移行に関する詳細は、以下の公的機関・公式ドキュメントを参照してください。

• 経済産業省「クラウドサービスガイドライン」 ― 官民のクラウド利用における技術・契約・セキュリティの指針。DB選定・容量設計にも影響。
• 内閣官房サイバーセキュリティセンター（NISC） ― 政府機関のクラウド利用基準、機密情報の取り扱い、暗号化ガイドライン。
• 独立行政法人 情報処理推進機構（IPA） ― 「情報システム・モデル取引・契約書」、「非機能要求グレード」、DB可用性・性能設計の実務資料。
• PostgreSQL 日本語ドキュメント ― PostgreSQL公式ドキュメントの日本語版。容量・パーティショニング・インデックスの詳細。
• MySQL 8.0 リファレンスマニュアル（日本語） ― MySQL公式ドキュメント。InnoDB・MyISAMのストレージエンジン特性、容量最適化。
• 政府情報システムのためのセキュリティ評価制度（ISMAP） ― 政府調達で認められたクラウドサービスの登録簿。可用性・データ保護要件の確認に。
• デジタル庁 デジタル・ガバメント推進標準ガイドライン ― クラウド・バイ・デフォルト原則、システム設計・調達の標準。
• ISO/IEC 27017 クラウドサービスの情報セキュリティ ― クラウド固有の管理策を定めた国際規格。データ保護・可用性の設計根拠。
• Transaction Processing Performance Council（TPC） ― DB性能ベンチマーク標準団体。TPC-C・TPC-H・TPC-DSベンチマーク結果。
• 日本データベース学会 ― データベース技術の学術研究・論文誌。設計理論の一次情報。

よくある質問（FAQ）

関連計算ツール