BLOB в базах данных: что это за тип и как хранить двоичные данные

BLOB (Binary Large Object, большой двоичный объект) — это тип данных в СУБД для хранения больших двоичных данных прямо в поле таблицы: картинок, аудио, видео, документов, архивов и любых других файлов. В отличие от чисел и строк, BLOB хранит байты «как есть», без привязки к кодировке и без разбора на символы.

Ниже разберем, чем BLOB отличается от текстовых типов, какие разновидности BLOB есть в популярных СУБД и сколько данных вмещают, покажем рабочий пример на SQL с реальным выводом и разберем, когда двоичные данные стоит класть в базу, а когда — на диск. Все примеры прогнаны в SQLite, вывод в тексте — фактический.

Зачем нужен отдельный тип для двоичных данных

Обычные столбцы — число, дата, строка — рассчитаны на структурированные значения фиксированного смысла. Файл же это просто поток байтов произвольной длины, и его нельзя корректно сложить в целочисленное или строковое поле: часть байтов совпадет с управляющими символами, часть не будет валидной в кодировке столбца.

BLOB решает эту задачу: он принимает любую последовательность байтов и возвращает ее в точности такой же. СУБД не пытается интерпретировать содержимое, не применяет к нему кодировку и не сортирует по правилам языка. Для базы это непрозрачный «мешок байтов» известной длины.

Из-за этого по BLOB нельзя удобно искать оператором LIKE или сравнивать по алфавиту — для него это лишено смысла. Зато он гарантирует, что записанный PNG или PDF прочитается байт в байт, без искажений.

BLOB и TEXT: двоичные данные против символьных

BLOB часто путают с большими текстовыми типами (в MySQL это семейство TEXT), потому что оба хранят «много данных переменной длины». Разница в природе содержимого, и ее важно развести.

• BLOB хранит байты. У него нет кодировки (character set) и правил сравнения (collation). Два значения сравниваются побайтово.
• TEXT хранит символы. У него есть кодировка и collation, сравнение и сортировка идут по правилам языка, работает регистронезависимый поиск.

Практическое следствие: текст статьи, комментарий, JSON-документ — это TEXT (или VARCHAR), потому что вам нужны поиск, сортировка и корректная кодировка. Картинка, зашифрованный ключ, сериализованный объект, PDF — это BLOB, потому что любая «интерпретация» их только испортит.

Виды BLOB в разных СУБД

Единого стандарта на размеры нет: имя типа и предельный объем задает конкретная СУБД. Ориентир по популярным движкам на 2026 год:

В MySQL четыре размера BLOB отличаются только предельной длиной, во всем остальном ведут себя одинаково. Границы кратны степеням двойки: 2^8 минус 1, 2^16 минус 1, 2^24 минус 1 и 2^32 минус 1 байт соответственно.

В SQLite BLOB — один из пяти классов хранения (NULL, INTEGER, REAL, TEXT, BLOB), отдельных размерных типов нет: движок сам хранит столько байтов, сколько вы записали. В PostgreSQL типа с именем BLOB нет вовсе — для небольших данных берут bytea, для очень крупных — механизм Large Objects. В SQL Server старый тип IMAGE считается устаревшим, использовать нужно VARBINARY(MAX).

В MySQL размер выбирают по ожидаемому объему: если значение превысит предел типа, лишние байты молча отсекаются, а файл после чтения окажется битым. Поэтому под аватары обычно хватает BLOB или MEDIUMBLOB, а LONGBLOB берут осознанно — он позволяет хранить до 4 ГБ, но такие объекты почти всегда выгоднее держать вне базы (об этом ниже).

Пример на SQL: создаем таблицу и кладем байты

Соберем таблицу с BLOB-полем и запишем в нее двоичные данные. Пример полный — его можно скопировать и выполнить в SQLite. Байты задаем шестнадцатеричным литералом x'...': каждая пара цифр — один байт.

CREATE TABLE files (
    id      INTEGER PRIMARY KEY,
    name    TEXT,
    content BLOB
);

INSERT INTO files (name, content) VALUES ('hello.txt', x'48656C6C6F');
INSERT INTO files (name, content) VALUES ('logo.png',  x'89504E470D0A1A0A');

SELECT id, name, length(content), typeof(content) FROM files;

Вывод последнего запроса (каждая строка — кортеж id, имя, число байт, тип хранения):

[(1, 'hello.txt', 5, 'blob'), (2, 'logo.png', 8, 'blob')]

Литерал x'48656C6C6F' — это пять байтов 48 65 6C 6C 6F, поэтому length вернул 5; x'89504E470D0A1A0A' — восемь байтов (это сигнатура файла PNG), отсюда 8. Функция typeof подтверждает, что данные легли именно как blob, а не как строка. В реальном приложении в BLOB кладут не hex-литерал руками, а содержимое файла через параметр запроса из кода на Python, Java или другом языке.

BLOB не равен строке с теми же байтами

Даже если байты BLOB совпадают с байтами текста, для базы это разные значения. Проверим на SQLite: положим в одну строку BLOB x'48656C6C6F' и текст 'Hello' (это те же пять байтов) и сравним их.

CREATE TABLE t (b BLOB, s TEXT);
INSERT INTO t VALUES (x'48656C6C6F', 'Hello');

SELECT hex(b), (b = s), length(b), length(s) FROM t;

Вывод:

[('48656C6C6F', 0, 5, 5)]

Функция hex показала содержимое BLOB как 48656C6C6F — те же байты, что у строки Hello. Но сравнение b = s вернуло 0 (ложь): в SQLite BLOB и TEXT относятся к разным классам хранения и никогда не считаются равными, BLOB при сортировке идет после любого текста. Длины при этом совпали — по 5. Вывод для новичка: тип хранения — часть значения, и молчаливого приведения BLOB к строке не происходит.

BLOB в базе или путь к файлу: что выбрать

Двоичные данные не обязательно держать в базе. Частая альтернатива — хранить файл на диске или в объектном хранилище (S3 и аналоги), а в таблице держать только путь или ссылку в обычном VARCHAR. Выбор зависит от задачи.

Хранить в BLOB удобно, когда важны целостность и простота: файл попадает в те же транзакции и резервные копии, что и остальные данные, к нему применяются те же права доступа, не нужно синхронизировать базу с файловой системой. Это хорошо подходит для небольших вложений — подписи, миниатюры, сгенерированные PDF.

Хранить файл снаружи, а в базе только ссылку, выгоднее для крупных и часто отдаваемых объектов: база остается компактной и быстрой в резервном копировании, файлы можно раздавать напрямую через веб-сервер или CDN, не нагружая СУБД. Минус — целостность приходится поддерживать вручную: удалили строку, не забудьте удалить файл.

Практический ориентир: мелкие двоичные вложения, для которых критична транзакционная целостность, — в BLOB; крупные медиафайлы под массовую раздачу — во внешнее хранилище со ссылкой в базе.

Выводы

• BLOB (Binary Large Object) — тип данных СУБД для хранения произвольной последовательности байтов «как есть»: картинок, аудио, видео, документов, архивов; база не интерпретирует содержимое и не применяет к нему кодировку.
• BLOB и TEXT различаются природой данных: BLOB хранит байты без кодировки и collation и сравнивается побайтово, TEXT хранит символы с кодировкой, сортировкой и регистронезависимым поиском.
• Единого стандарта на размеры нет: в MySQL четыре типа (TINYBLOB/BLOB/MEDIUMBLOB/LONGBLOB) от 255 Б до 4 ГБ, в SQLite BLOB — класс хранения до ~2 ГБ, в PostgreSQL вместо BLOB используют bytea или Large Objects.
• Тип хранения — часть значения: BLOB и текст с теми же байтами для базы не равны (в SQLite сравнение вернуло 0), молчаливого приведения не происходит.
• Мелкие вложения с требованием транзакционной целостности держат в BLOB, крупные медиафайлы под массовую раздачу — во внешнем хранилище со ссылкой в базе.

Где применяется и что учить дальше

BLOB встречается почти в любой прикладной базе: аватары и вложения в мессенджерах, миниатюры товаров, вложения к письмам, сгенерированные документы, кэш бинарных артефактов. Умение осознанно выбрать между BLOB и внешним хранилищем, а также правильно записать и прочитать байты через параметры запроса — базовый навык при работе с данными.

FAQ

Чем BLOB в JavaScript отличается от BLOB в базе данных? Это разные вещи с похожим именем. В браузере Blob — объект Web API для работы с сырыми данными в памяти (например, чтобы собрать файл для загрузки). Тип данных СУБД, о котором эта статья, к нему отношения не имеет, хотя идея «контейнер для двоичных данных» общая.

Чем BLOB отличается от CLOB? BLOB хранит двоичные данные (байты, без кодировки), CLOB (Character Large Object) — большой текст с кодировкой и правилами сравнения. Проще говоря, CLOB для BLOB — то же, что TEXT для бинарного поля: символы против байтов.

Можно ли искать по содержимому BLOB? Полноценного текстового поиска по BLOB нет: для базы это непрозрачные байты. Обычно ищут по соседним столбцам — имени файла, MIME-типу, хэшу содержимого, — которые заводят рядом с BLOB как раз для фильтрации и поиска.