// シス担のミカタ
データ型

バイナリ型・BLOB ばいなりがた・ぶろぶ

BLOBバイナリファイル画像データベースバイト列
バイナリ型・BLOBについて教えて

簡単に言うとこんな感じ！

バイナリ型・BLOBは「データベースにそのまま詰め込める大きなカプセル」だよ！画像・PDF・動画みたいな「文字じゃないデータ」をひとかたまりのバイト列として保存できるんだ。ただし中身はDBにはわからないから、検索も変換もできない「不透明な袋」扱いになるんだ。

バイナリ型・BLOBとは

バイナリ型 とは、テキスト（文字）ではなく「0と1のビット列（バイト列）」をそのまま格納するデータ型です。BLOB（Binary Large OBject） はその代表格で、「大きなバイナリデータ」を丸ごと保存するための型です。

画像ファイル・PDFドキュメント・音声データ・暗号化されたデータ・シリアライズされたオブジェクトなど、テキストでは表現できないあらゆるバイナリデータに対応します。データベースはBLOBの中身を「意味のあるデータ」として解釈せず、入れたものをそのまま返すだけという特性があります。

実務では「ファイルをDBに保存すべきか、ファイルサーバー（S3など）に置いてDBにはパスだけ保存すべきか」という設計論争が常に存在します。大容量ファイルをBLOBで大量に持つとDBが膨張しバックアップが重くなるため、現代ではファイルはストレージサービスに置き、DBにはURLやパスのみ保存する設計が主流です。

バイナリ型の種類

型名最大サイズ主な用途
BINARY(n)固定長バイト列（〜255バイト）ハッシュ値・固定長IDなど
VARBINARY(n)可変長バイト列（〜65,535バイト）短いバイナリデータ
TINYBLOB〜255バイトごく小さなバイナリ
BLOB〜65,535バイト（約64KB）小〜中サイズの画像など
MEDIUMBLOB〜16,777,215バイト（約16MB）中程度のファイル
LONGBLOB〜4,294,967,295バイト（約4GB）動画・大容量ドキュメント
BYTEA（PostgreSQL）〜1GBPostgreSQL独自のバイナリ型

BLOB vs ファイルストレージの選択基準

DBにBLOBで保存すべきケース:
  ✅ ファイルサイズが小さい（数KB〜数百KB程度）
  ✅ データとファイルをトランザクション管理したい
  ✅ アクセス制御をDBレベルで一元管理したい
  ✅ ファイル数が少ない

ファイルストレージ（S3・CDNなど）に保存すべきケース:
  ✅ ファイルが大きい（数MB以上）
  ✅ ファイル数が多い・増え続ける
  ✅ 配信速度を重視する（CDNを使いたい）
  ✅ DBのバックアップを軽くしたい

歴史と背景

  • 1980年代 — リレーショナルDBの普及とともに「テキスト以外のデータをどう扱うか」が課題に。初期は文字列型に無理やり詰め込む方法も
  • 1990年代初頭 — Oracle・Sybaseなどが BLOB / CLOB（文字のLOB）型を独自実装。大容量データをDBに格納できるようになる
  • SQL:1999 — 標準SQLに BINARY LARGE OBJECT が採用される
  • 2000年代 — Webサービスの普及で画像・動画をDBに保存するニーズが急増。一方でDBの肥大化が問題に
  • 2006年〜 — Amazon S3などのオブジェクトストレージが登場し、「ファイルはDB外に置く」設計が主流化
  • 現在 — クラウドストレージの低コスト化により、大容量ファイルをDBのBLOBで保存するケースは激減。DBにはメタデータとURLのみ保存するパターンが標準的

BLOBを使う場合の典型的なシステム構成

ファイル保存の2つのアーキテクチャ ① DBにBLOBで保存（旧来） アプリケーションサーバー データベース （BLOB列に画像データを直接保存） DB肥大化・バックアップ遅延のリスク ② ストレージ分離（現代の主流） アプリケーションサーバー DB URLのみ S3/CDN ファイル本体 DBは軽量・配信は専用サービスで高速

関連する規格・RFC

規格・RFC番号内容
ISO/IEC 9075 (SQL:1999)BINARY LARGE OBJECT（BLOB）をSQL標準に定義
RFC 2045MIME形式の仕様。バイナリデータをメールやHTTPで転送する際の Base64 エンコーディングを定義

関連用語