В чем разница между хранением данных в blob и хранением указателя на файл?

У меня есть вопрос о blob тип данных в MySQL.

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

но я немного смущен, потому что я прочитал, что поля blob не хранятся в строке и требуют отдельного поиска для извлечения его содержимого. Так чем это отличается от хранения указателя на файл файловая система?

15
blob mysql sqldatatypes

5 ответов

Я прочитал, что тип данных может использоваться для хранения файлов.

по данным руководство MySQL страница на Blob, a BLOB - это двоичный большой объект, который может содержать переменный объем данных.

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

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

кроме того, хранение большого объема данных в БД мая притормози. Специально в системах, которые не предназначены только для размещения базы данных.

Я также прочитал, что альтернативой является сохранение файла на диске и включение указателя на его расположение в базе данных

принимая во внимание все вышеизложенные соображения общей практикой для веб-приложений является хранение ваших файлов в другом месте, чем ваш MySQL, а затем просто хранить его путь в вашей базе данных. Такой подход мая ускорить работу базы данных при работе с большим количеством данных.

но я немного смущен, потому что я прочитал, что поля blob не хранятся в строке и требуют отдельного поиска для получения его содержание.

на самом деле это будет зависеть от того, какой механизм хранения вы используете, так как каждый двигатель обрабатывает данные и сохраняет их по-разному. Для движка InnoDB, который подходит для реляционной базы данных, вы можете прочитать эту статью из блог производительности MySQL о том, как blob хранится в MySQL.

но абстрактно, на MySQL 5 и вперед blob хранится следующим образом:

Innodb хранит либо весь blob на страница строки или только 20-байтовый указатель BLOB, отдающий предпочтение меньшим столбцам, которые будут храниться на странице, что разумно, поскольку вы можете хранить их больше.

поэтому вы, вероятно, думаете, что правильный путь-хранить их как отдельный файл, но есть некоторые преимущества использования blob для хранения данных, первый (на мой взгляд) - это резервная копия. Я управляю небольшим сервером, и мне пришлось создать другую подпрограмму только для копирования моих файлов, хранящихся как пути к другому хранилищу диск (мы не могли позволить себе купить приличную систему резервного копирования ленты). Если бы я разработал свое приложение для использования blobs простой mysqldump будет все, что мне нужно для резервного копирования всей базы данных.

преимущество хранения blobs для резервных копий лучше обсудить на этот пост где у человека, который ответил, была аналогичная проблема, чем у меня.

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

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

так что я бы сказал, что

если вы собираетесь управлять ваш MySQL и все данные, которые у вас есть в нем, и должны делать регулярные резервные копии или намереваться изменить или даже рассмотреть будущее изменение ОС, и иметь приличное оборудование и оптимизированный MySQL для него, идут на BLOB.

если вы не будет управляйте своим MySQL (как, например, в веб-хостинге) и не собираетесь менять ОС или создавать резервные копии, придерживайтесь varchar столбцы, указывающие на ваши файлы.

надеюсь, это помогло. Ура!--5-->

12

Если вы храните данные в поле BLOB, вы делаете его частью абстракции объекта.

BLOB преимущества:

  1. Если вы хотите удалить строку с BLOB или удалить ее как часть отношения таблицы master/slave или, возможно, всей иерархии таблиц, ваш BLOB обрабатывается автоматически и имеет тот же срок службы, что и любой другой объект в базе данных.

  2. скрипты не нужно ничего, но доступ к базе чтобы получить все, что им нужно. Во многих ситуациях, имея прямой доступ к файлам открыть Ящик Пандоры о том, как обойти ограничения доступа или безопасности. Например, при доступе к файлам им может потребоваться монтировать файловые системы, содержащие фактические файлы. Но с Blob в базе данных, вы только должны быть в состоянии подключиться к базе данных, независимо от того, где вы находитесь.

  3. Если вы храните его в файле и файл заменен, удален или больше не доступен, ваша база данных никогда не будет знать-в эффект, вы не можете гарантировать целостность. Кроме того, трудно надежно поддерживать несколько версий при использовании файлов. Если вы используете транзакции и зависите от них, это становится почти невозможным.

файл преимущества:

  1. некоторые базы данных обрабатывают BLOBs довольно плохо. Например, в то время как официальный предел BLOB в MySQL-4GB, но на самом деле это только 1MB в конфигурации по умолчанию. Вы можете увеличить это до 16-32MB, настроив оба конфигурация клиента и сервера для увеличения командного буфера MySQL, но это имеет много других последствий с точки зрения производительности и безопасности.

  2. даже если база данных не имеет каких-то странных ограничений размера, она всегда будет иметь некоторые накладные расходы при хранении BLOB по сравнению с файлом. Кроме того, если BLOB большой, некоторые базы данных не предоставляют интерфейс для доступа к blob по частям или stream Это, что может быть большим препятствием для вашего рабочий процесс.

В конце концов, это до вас. Обычно я пытаюсь сохранить его в BLOB, если это не создает необоснованных проблем с производительностью.

9

да, MySQL blobs, которые не вписываются в ту же страницу, что и строка, сохраняются на страницах переполнения, обратите внимание, что некоторые blobs достаточно малы, чтобы они хранились с остальной частью строки, как и любой другой столбец. Страницы blob не прилегают к странице, на которой хранится их строка, поэтому они могут привести к дополнительному вводу-выводу для их чтения.

с другой стороны, как и с любым другим типом страницы, страницы blob могут занимать память в буферном пуле InnoDB, поэтому чтение Blob впоследствии очень быстро даже если они на разных страницах. Файлы могут кэшироваться операционной системой, но обычно они считываются с диска.

вот еще несколько факторов, которые могут повлиять на ваше решение:

  • Blobs хранятся логически со строкой. Это означает, что при удалении строки связанный blob удаляется автоматически. Но если вы храните blob вне базы данных, вы получаете потерянные файлы blob после удаления строк из базы данных. Вам нужно сделать инструкции по поиску и удалению этих файлов.

  • Blobs, хранящиеся в строке, также следуют семантике транзакций. Например, новый или обновленный blob невидим для других транзакций до фиксации. Вы также можете откатить изменения. Хранение блобов в файлы вне базы данных делает это намного сложнее.

  • при резервном копировании базы данных, содержащей капли, база данных, конечно, намного больше, но при резервном копировании вы получаете все данные и связанные капли за один шаг. Если вы храните Blob-объекты извне, необходимо создать резервную копию базы данных, а также файловой системы, в которой хранятся blob-файлы. Если вам нужно убедиться, что данные и капли захватываются с одного момента времени, вам в значительной степени нужно использовать какие-то моментальные снимки файловой системы.

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

5

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

2

доступ к файловой системе будет быстрее, чем через базу данных. Столбцы Blobs имеют некоторые недостатки с точки зрения индексирования/сортировки и т. д., Что вы можете сделать с вашим столбцом filename, если захотите в будущем.

база данных также может быстро расти с большими каплями, а затем такие задачи, как резервное копирование, становятся медленнее. Я бы пошел с расположением файла в базе данных с физическим хранилищем в файловой системе.

2