Хранение изображения в базе данных напрямую или как данные base64?

Общим методом хранения изображений в базе данных является преобразование изображения в данные base64 перед сохранением данных. Этот процесс увеличит размер на 33%. В качестве альтернативы можно напрямую сохранить изображение как BLOB; например:

$image = new Imagick("image.jpg");
$data = $image->getImageBlob();
$data = $mysqli->real_escape_string($data);
$mysqli->query("INSERT INTO images (data) VALUES ('$data')");

а затем отобразите изображение с помощью

<img src="data:image/jpeg;base64,' .  base64_encode($data)  . '" />

При использовании последнего метода мы сохраняем 1/3 место для хранения. Почему чаще всего хранятся изображения в base64 в базах данных MySQL?

ОБНОВЛЕНИЕ: Есть много дискуссий о преимуществах и недостатках хранения изображений в базах данных, и большинство людей считают, что это не практический подход. В любом случае, здесь я предполагаю, что мы храним изображение в базе данных и обсуждаем лучший способ для этого.

Ответ 1

Pro base64: кодированное представление, которое вы обрабатываете, является довольно безопасной строкой. Он не содержит ни контрольных символов, ни кавычек. Последнее указывает на попытки SQL-инъекций. Я бы не ожидал, что какая-либо проблема просто добавит значение в строку запроса "вручную закодированную" SQL.

Pro BLOB: программное обеспечение менеджера баз данных знает, какой тип данных он должен ожидать. Он может оптимизировать для этого. Если вы сохранили base64 в поле TEXT, он может попытаться создать для него какую-то индексную структуру или другую структуру данных, что было бы очень полезно и полезно для "реальных" текстовых данных, но бессмысленно и тратить время и пространство на данные изображения. И это меньше, чем в байтах, представление.

Ответ 2

Я утверждаю, что изображения (файлы) обычно не хранятся в кодировке базы данных base64. Вместо этого они хранятся в их исходной двоичной форме в двоичном (blob) столбце (или файле).

Base64 используется только как транспортный механизм, а не для хранения. Например, вы можете внедрить изображение с кодировкой base64 в документ XML или сообщение электронной почты.

Base64 также удобен для потока. Вы можете кодировать и декодировать "на лету" (не зная общий размер данных).

В то время как base64 отлично подходит для транспорта, не сохраняет ваши изображения base64, закодированные.

Base64 не предоставляет никаких контрольных сумм или каких-либо значений для хранения.

Кодирование Base64 увеличивает требования к хранилищу на 33% по сравнению с необработанным двоичным форматом. Он также увеличивает объем данных, которые должны считываться из постоянного хранилища, что, как правило, является самым большим узким местом в вычислениях. Как правило, быстрее читать меньше байтов и кодировать их на лету. Только если ваша система привязана к процессору вместо привязки IO, и вы регулярно выводите изображение в base64, тогда подумайте о сохранении в base64.

Встроенные изображения (кодированные в формате base64 изображения, встроенные в HTML) являются узким местом - вы отправляете на 33% больше данных по проводу и делаете это последовательно (веб-браузер должен ждать на встроенных изображениях, прежде чем он сможет закончить загрузка страницы HTML).

Если вы все еще хотите сохранить кодированные изображения base64, пожалуйста, что бы вы ни делали, убедитесь, что вы не храните данные в кодировке base64 в столбце UTF8, а затем индексируете его.

Ответ 3

Я рекомендую посмотреть современные базы данных, такие как NoSQL, а также согласен с user1252434. Например, я храню несколько < 500kb PNG в качестве base64 на моем монго-db с двоичным значением, установленным в true, при этом вообще не пострадали. Mongo можно использовать для хранения больших файлов, таких как 10MB-видео, и которые могут предложить огромные преимущества экономии времени при поиске метаданных для этих видео, см. хранение больших объектов и файлов в mongodb.