it-swarm.com.ru

MySQL - Base64 против BLOB

Для простоты предположим, что я разрабатываю мобильное приложение, такое как Instagram. Пользователи могут загружать изображения с сервера и загружать собственные изображения. В настоящее время сервер хранит все изображения (на самом деле, только небольшие эскизы) в базе данных MySQL как BLOB. Кажется, что наиболее распространенный способ передачи изображений - использование кодировки Base64, что оставляет мне два варианта:

  1. Сервер хранит все изображения в виде больших двоичных объектов. Чтобы загрузить изображение, клиент кодирует его в строку Base64, а затем отправляет его на сервер. Сервер декодирует изображение BACK в двоичный формат и сохраняет его как BLOB в базе данных. Когда клиент запрашивает изображение, сервер повторно кодирует изображение в виде строки Base64 и отправляет его клиенту, который затем декодирует его обратно в двоичный файл для отображения.
  2. Сервер сохраняет все изображения в виде строк Base64. Чтобы загрузить изображение, клиент кодирует его в строку Base64 и отправляет его на сервер. Сервер не кодирует и не декодирует, а просто сохраняет строку в базе данных. Когда клиент запрашивает изображение, строка Base64 возвращается клиенту, который затем декодирует его для отображения.

Очевидно, что вариант № 1 требует значительно большей обработки на сервере, так как изображения должны быть закодированы/декодированы с каждым запросом. Это заставляет меня склоняться к варианту № 2, но некоторые исследования показали, что хранение строки Base64 в MySQL гораздо менее эффективно, чем сохранение изображения непосредственно в виде BLOB, и, как правило, не рекомендуется.

Я, конечно, не первый человек, который сталкивается с такой ситуацией, поэтому есть ли у кого-нибудь предложения о том, как сделать эту работу лучше?

15
hundley

JSON предполагает utf8, поэтому несовместим с изображениями, если они не кодируются каким-либо образом.

Base64 почти в 8/6 раз громче, чем двоичный (BLOB). Можно утверждать, что это легко доступно. 3000 bytes становится примерно 4000 bytes.

Каждый должен иметь возможность принимать произвольные 8-битные коды, но не все это делают. Base-64 может быть самым простым и в целом лучшим компромиссом для того, чтобы не иметь дело с 8-битными данными.

Так как они «маленькие», я бы сохранял их в таблице, а не в файле. Однако я бы сохранил их в отдельной таблице и JOIN с помощью соответствующей id, когда они вам понадобятся. Это позволяет запросам, которым не нужно изображение, работать быстрее, поскольку они не пересекают BLOB-объекты.

Технически, TEXT CHARACTER SET ascii COLLATE ascii_bin подойдет, но BLOB проясняет, что в столбце нет полезного текста.

5
Rick James

Зачем вам base64-кодировать изображения на проводе? Я думаю, вы исходите из неверного предположения.

1
Julian Reschke

Я не понимаю, почему сервер БД не всегда должен хранить двоичные данные в их исходной форме. Таким образом, используйте BLOB . (Но даже если вы сохранили данные в строке Base64, вам не нужно беспокоиться о производительности кодирования/декодирования, поскольку влияние ввода-вывода будет более значительным.)

Я не понимаю, почему клиент должен отправлять данные в base64, хотя. Почему бы просто не «передать» его с помощью простого HTTP-вызова?

0
Theodore Zographos