У меня вопрос о типе данных blob в MySQL.
Я читал, что тип данных можно использовать для хранения файлов. Я также читал, что альтернативой является сохранение файла на диске и включение указателя на его местоположение в базе данных (через столбец varchar).
Но я немного смущен, потому что я читал, что поля blob не хранятся в строке и требуют отдельного поиска для извлечения его содержимого. Так что это не что иное, как сохранение указателя на файл в файловой системе?
Я читал, что тип данных можно использовать для хранения файлов.
В соответствии с Руководство по MySQL на Blob, A BLOB - это двоичный большой объект, который может содержать переменный объем данных.
Так как это тип данных, специфичный для хранения двоичных данных, он обычно используется для хранения файлов в двоичном формате, поскольку хранение файлов изображений очень распространено в веб-приложениях.
Для веб-приложений это означало бы, что вам сначала нужно будет преобразовать ваш файл в двоичный формат, а затем сохранить его, и каждый раз, когда вам нужно получить файл, вам нужно будет сделать обратный процесс преобразования их обратно в исходное формат.
Кроме того, хранение большого количества данных в вашем db MAY замедляет его. Специально в системах, которые не предназначены только для размещения базы данных.
Я также читал, что альтернативой является сохранение файла на диске и включение указателя на его расположение в базе данных
Учитывая все вышеприведенные соображения, обычной практикой для веб-приложений является хранение ваших файлов в другом месте, кроме вашего MySQL, а затем просто сохранение пути в базе данных. Этот подход МАЙ ускоряет работу вашей базы данных при работе с большим объемом данных.
Но я немного смущен, потому что я читал, что поля blob не хранятся в строке и требуют отдельного поиска для извлечения его содержимого.
Фактически это зависит от того, какой механизм хранения вы используете, поскольку каждый движок обрабатывает данные и сохраняет их по-разному. Для механизма InnoDB, который подходит для реляционной базы данных, вы можете прочитать эту статью из Блог производительности MySQL о том, как blob хранится в MySQL,
Но абстрактно, на MySQL 5 и пересылаем blob хранится следующим образом:
Innodb хранит либо целую блоб на странице строки, либо только 20-битовый указатель BLOB, предпочитающий меньшие столбцы, которые будут храниться на странице, что разумно, поскольку вы можете хранить их больше.
Итак, вы, вероятно, сейчас думаете, что правильный путь - хранить их в виде отдельного файла, но есть некоторые преимущества использования blob для хранения данных, первая (на мой взгляд) - это резервная копия. Я управляю небольшим сервером, и мне пришлось создать еще одну подпрограмму только для копирования моих файлов, хранящихся в виде путей на другой диск (мы не могли позволить себе купить приличную систему резервного копирования на магнитную ленту). Если бы я разработал мое приложение для использования blobs, простым mysqldump будет все, что мне нужно для резервного копирования всей моей базы данных.
Преимущество хранения блоков для резервных копий лучше обсуждается на этом сообщении, где у человека, который ответил, была аналогичная проблема, чем у меня.
Еще одно преимущество - безопасность и простота управления разрешением и доступом. Все данные на вашем сервере MySQL защищены паролем, и вы можете легко управлять разрешениями для своих пользователей о том, кто имеет доступ к тому, а кто нет.
В приложении, которое полагается на систему привилегий MySQL для аутентификации и использования. Это определенно плюс, поскольку было бы немного сложнее позволить захватчику получить изображение (или двоичный файл, такой как заархивированный), с вашего диска или пользователя без прав доступа для доступа к нему.
Итак, я бы сказал, что
Если вы собираетесь управлять своим MySQL и всеми данными, которые у вас есть, и должны делать регулярные резервные копии или намереваться изменить или даже рассмотреть будущую смену ОС, а также иметь достойное оборудование и оптимизировать свой MySQL, перейдите в BLOB,
Если вы не будете управлять вашим MySQL (например, в веб-хосте) и не собираетесь менять ОС или делать резервные копии, придерживайтесь столбцов varchar, указывающих на ваши файлы.
Надеюсь, это помогло. Приветствия
Если вы храните данные в поле BLOB, вы делаете его частью своей абстракции объекта.
Преимущества BLOB:
Если вы хотите удалить строку с BLOB или удалить ее как часть отношения к главной/подчиненной таблице или, возможно, всей иерархии таблицы, ваш BLOB обрабатывается автоматически и имеет такое же время жизни, как и любой другой объект в базе данных.
В ваших сценариях нет необходимости обращаться к чему-либо, кроме базы данных, чтобы получить все необходимое. Во многих ситуациях, имея прямой доступ к файлам, можно открыть целую червь червей о том, как обойти доступ или ограничения безопасности. Например, при доступе к файлу им может потребоваться монтирование файловых систем, содержащих фактические файлы. Но с BLOB в базе данных вы должны иметь возможность подключаться к базе данных независимо от того, где вы находитесь.
Если вы сохраните его в файле, а файл будет заменен, удален или уже недоступен, ваша база данных никогда не узнает - на самом деле вы не можете гарантировать целостность. Кроме того, при использовании файлов трудно надежно поддерживать несколько версий. Если вы используете транзакции и полагаетесь на них, это становится практически невозможным.
Преимущества файла:
Некоторые базы данных обрабатывают BLOB довольно плохо. Например, хотя официальное ограничение BLOB в MySQL составляет 4 ГБ, но на самом деле это только 1 МБ в конфигурации по умолчанию. Вы можете увеличить это до 16-32 МБ, настроив конфигурацию клиента и сервера, чтобы увеличить буфер команд MySQL, но это имеет множество других последствий с точки зрения производительности и безопасности.
Даже если в базе данных нет каких-то странных ограничений по размеру, всегда будет накладные расходы на хранение BLOB по сравнению с только файлом. Кроме того, если BLOB большой, некоторые базы данных не предоставляют интерфейс для доступа к блоку по частям или stream, что может быть большим препятствием для вашего рабочего процесса.
В конце концов, это зависит от вас. Обычно я пытаюсь сохранить его в BLOB, если это не создает необоснованных проблем с производительностью.
Да, бласты MySQL, которые не помещаются на одной странице, как строка, хранятся на страницах переполнения. Обратите внимание, что некоторые капли достаточно малы, чтобы они сохранялись вместе с остальной частью строки, как и любой другой столбец. Страницы blob не смежны со страницей, на которой хранится их строка, поэтому они могут привести к дополнительному вводу/выводу, чтобы прочитать их.
С другой стороны, точно так же, как и с любым другим типом страницы, страницы blob могут занимать память в пуле буферов InnoDB, поэтому чтение блобов впоследствии очень быстро, даже если они находятся на отдельных страницах. Файлы могут кэшироваться операционной системой, но обычно они считываются с диска.
Вот несколько других факторов, которые могут повлиять на ваше решение:
Блоки хранятся логически с помощью строки. Это означает, что если вы удалите строку, связанный с ней блок будет удален автоматически. Но если вы храните blob вне базы данных, вы получаете сиротские BLOB файлы после удаления строк из базы данных. Вы должны выполнить ручные действия для поиска и удаления этих файлов.
Блобки, хранящиеся в строке, также следуют семантике транзакций. Например, новый blob или обновленный blob невидимы для других транзакций, пока вы не зафиксируете. Вы также можете отменить изменение. Сохранение блоков в файлах вне базы данных делает это намного сложнее.
При резервном копировании базы данных, содержащей blob, база данных намного больше, но при резервном копировании вы получаете все данные и связанные с ними капли в один шаг. Если вы храните blobs извне, вам нужно создать резервную копию базы данных, а также создать резервную копию файловой системы, в которой вы храните файлы blob. Если вам нужно обеспечить, чтобы данные и капли были захвачены с одного момента времени, вам в значительной степени нужно использовать какие-то снимки файловой системы.
Если вы используете репликацию, единственный автоматический способ обеспечения того, чтобы blobs автоматически копировались в ведомое устройство репликации, - это хранить в базе данных blob.
Лучший подход заключается в том, чтобы сохранить файл в папке файловой системы и указать их пути через поле varchar в базе данных. Один из недостатков сохранения файлов в базе данных замедляет его или снижает его производительность.
Доступ к файловой системе будет быстрее, чем через базу данных. Столбцы Blobs имеют некоторые недостатки в отношении индексирования/сортировки и т.д., Которые вы могли бы сделать со своим столбцом имени файла, если хотите в будущем.
База данных также может быстро расти с большими блобами, а затем задачи, такие как резервное копирование, становятся медленнее. Я бы пошел с файлом в базу данных с физическим хранилищем в файловой системе.