Бинарное хранилище MySQL с использованием файловой системы BLOB VS OS: большие файлы, большие количества, большие проблемы

Версии, которыми я бегу (в основном последнее из всего):
PHP: 5.3.1
MySQL: 5.1.41
Apache: 2.2.14
ОС: CentOS (последняя версия)

Вот ситуация.

У меня есть тысячи очень важных документов: от клиентских контрактов до голосовых подписей (записи авторизации клиента для контрактов), с файлами, включая, но не ограничиваясь, jpg, gif, png, tiff, doc, docx, xls, wav, mp3, pdf и т.д.

Все эти документы в настоящее время хранятся на нескольких серверах, включая Windows 32 bit, CentOS и Mac и другие. Некоторые файлы также хранятся на настольных компьютерах и ноутбуках сотрудников, а некоторые из них по-прежнему являются печатными копиями, хранящимися в сотнях ящиков и шкафах.

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

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

Структура выглядит как таковая:

drivers_license
| - Охота и рыбалка voice_signatures
| - Охота и рыбалка | - Охота и рыбалка контракты

Итак, файлы uplaoded с использованием PHP и Apache и хранятся в файловой системе ОС. Во время загрузки определенная информация о файле (файлах) хранится в базе данных MySQL. Часть сохраненной информации:

ТАБЛИЦА: FileUploads
FILEID
CustomerID (идентификатор клиента, к которому принадлежит файл, все они имеют это.)
JobID/SaleID (идентификатор связанной работы/продажи, если таковой имеется).
FileSize
FileType
UploadedDateTime
UploadedBy
FilePath (путь каталога, в котором хранится файл.)
FileName (текущее имя файла загруженного файла, комбинация CustomerID и JobID/SaleID, если применимо).
FileDescription
OriginalFileName (исходное имя исходного файла при загрузке, включая расширение.)

Итак, как вы можете видеть, файл связан с базой данных по имени файла. Когда я хочу предоставить пользователям файлы для загрузки для пользователя, все, что мне нужно сделать, это "SELECT * FROM FileUploads WHERE CustomerID = 123 OR JobID = 2345;" и это выведет все необходимые мне данные файла, а с FilePath и FileName я могу предоставить ссылку для загрузки.

http... server/ FilePath/ Имя_файла

С этим методом существует ряд проблем:

Сохранение файлов в этой "бессознательной" базе данных означает, что целостность данных не сохраняется. Если запись удалена, файл также не может быть удален, или наоборот.
Файлы разбросаны повсюду, разные серверы, компьютеры и т.д.
Имя файла - это ТОЛЬКО вещь, соответствующая двоичному файлу базы данных, профиля клиента и записей клиента.

и т.д. и т.д. Существует так много причин, некоторые из которых описаны здесь: http://www.dreamwerx.net/site/article01. Также здесь есть интересная статья: sietch.net/ViewNewsItem.aspx?NewsItemID=124.

SO, после долгих исследований я почти решил, что собираюсь хранить ВСЕ эти файлы в базе данных, как BLOB или LONGBLOB, но до сих пор все еще есть много соображений.

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

Статья, приведенная по этой ссылке: dreamwerx.net/site/article01 описывает способ разделения загруженных двоичных файлов на куски 64kb и хранения каждого фрагмента с помощью FileID, а затем потоковой передачи фактического двоичного файла клиенту с использованием заголовков. Это действительно классная идея, поскольку она облегчает предварительное заполнение памяти серверов; вместо того, чтобы загружать весь 100-мегабайтный файл в ОЗУ и затем отправлять его клиенту, он делает это 64 кбайт за раз. Я пробовал это (и обновлял его скрипты), и это полностью успешно, в очень небольшом кадре тестирования.

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

Кроме того, я рассматриваю возможность получения текущего "Управление файлами" PHP script, который предоставляет интерфейс для управления файлами, хранящимися в Файловой системе, и преобразования его для управления файлами, хранящимися в базе данных. Если у вас уже есть какое-либо программное обеспечение, которое делает это, сообщите мне.

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

Приветствия,

Quantico773

Ответ 1

Я работаю над большой программной системой, которая сделала оба механизма для хранения вложений и другого контента. Первая итерация системы хранила все данные в BLOB в БД. Я проклял его в то время. Как программист, я мог писать боковые скрипты, чтобы немедленно работать с данными и изменять их, когда захочу.

Продвигайтесь около 10 лет, и я все еще управляю одним и тем же программным обеспечением, но архитектура изменилась, и он был написан с указателями файловой системы. Я проклинаю его сейчас и желаю, чтобы он вернулся в БД. У меня есть дополнительное преимущество в течение нескольких лет, и, работая над этим приложением в гораздо большей степени во многих более и более крупных ситуациях, я чувствую, что мое мнение сейчас лучше образовано. Продвижение или миграция системы приложения требует обширного сценария и копирования миллионов файлов. Однажды мы изменили ОС, и у всех указателей файлов был неправильный разделитель каталогов, или имя сервера изменилось там, где находился файл, и нам пришлось писать и планировать простые инструкции SQL-обновления с администратором базы данных в выходные, чтобы исправить. Другим является то, что записи файловой системы и БД не синхронизированы, почему неясно, но после тысяч дней работы иногда не транзакционные системы (файловая система и БД не разделяют транзакционные контексты) просто перестают синхронизироваться. Иногда файлы таинственно пропадают.

Когда все это было в БД, миграция или продвижение среды были вопросом дампа и импорта БД. Изменения в строке могут быть правильно проверены, все в синхронизации и журналы могут быть воспроизведены до момента времени, если это необходимо. Конечно, DB становится большим, но это 2011 год, и этот материал просто не является проблемой для баз данных.

Для чего у нас были некоторые аналогичные проблемы с большими буферами данных при потоковой передаче некоторых данных, но А) мы могли бы накачивать данные в байтовых буферах с помощью Input | OutputStreams в JDBC и B) при использовании других инструментов, мы писали хранимую процедуру, которая будет блокировать BLOB в временную таблицу и итеративно обслуживать куски из временной таблицы. Отлично работает.

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

Обновление: легко читайте комментаторы, они просто высказывают свое мнение по этому вопросу.