Как создать свою файловую систему на основе blob полей в базе данных. Почему это удобно. Вопросы эффективности

Я может не совсем компетентен, но всегда интересовал вопрос, что курят люди делающие такое:

Как создать свою файловую систему на основе blob полей в базе данных. Почему это удобно.

Создание файловой системы в БД, которая сама является набором файлов в нормальной файловой системе.

Но зачем?

CREATE TABLE FILES_ (
    ID                  BIGINT,
    DATA                TIMESTAMP,  --Дата добавления файла
    DATA_DEL            TIMESTAMP,  --Дата удаления файла

IMHO, было бы логичнее использовать слово «date», а не «data».

И вообще именование полей очень спорное. Например, вместо «USER» и «USER_DEL» я бы использовал «created_by» и «deleted_by» — тогда бы сразу отпала необходимость в комментариях.

Кроме того, для хранения файлов лучше использовать решения на базе NoSQL, например, упомянутый выше GridFS или HDFS.

Данный способ лишен основных уязвимостей веб приложений при загрузке файлов

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

Не городить же единый запрос в несколько БД.
Тут есть некоторая избыточность данных в этих двух таблицах

В основной базе в таблице files хранится путь к файлу. В таком варианте ничего городить не надо, запрос идет только в основную БД. После проверки прав содержимое так же отдается через stream. Для удобства переноса можно адрес сервера в отдельном поле хранить.

Все, у нас файл записан в файловую БД. На веб-сервере его нет.

"Все, у нас файл записан в файловое хранилище на другом сервере. На веб-сервере его нет."
В чем принципиальная разница?

Тут хочу обратить внимание на типовую ошибку. Перед <?php и после ?> не должно быть никаких символов – иначе ничего не получится.

Рекомендуется не закрывать тег, если в файле есть только PHP-код. Это так, к сведению.

Т.е. когда пользователь кликает на ссылку file_b.php?id=123, скрипт должен дернуть другой скрипт, который считает в себя данные из blob файла

Зачем? Что мешает разархивировать в этом же скрипте?

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

Да ну? Вы для программистов статью написали или для менеджеров?)

Следовательно, в задачах должна быть не ссылка, а некое “окно” в Диск, в котором задача будет видеть только свои файлы.

Эмм. Чем это отличается от таблицы tasks__files (task_id, file_id, ...)?

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

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

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

comments__files

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

FontAwesome, glyphicons

Готов поставить пиво, что такого рода извращения нужны в случаях написания 'велосипедов'.

Боже, какая все же печаль....

Итак, по пунктам:

• Хранить файлы в БД нужно в достаточно редких и исключительных случаях (или тогда когда у вас ну очень простой бложик и вы хотите иметь абсолютно весь контент в одном месте — БД). Поэтому для большинства случаев правильный ответ — не хранить.
  Тогда когда вам это потребуется — вы будете знать достаточно чтобы это сделать. Чаще всего это моменты связанные с шардингом и репликацией данных между шардами. И интенсивной работой с самими файлами.
• В обычном случае в БД храним метаинформацию о файле
  — реальное имя файла загруженного пользователем
  — размер
  — дату
  — путь где хранится файл (включая служебное имя сгенерированное вами) и возможно имя файлсервера
• На файлсервере вы встраиваете дерево с учетом того чтобы не хранить более 1000-2000 файлов в одном каталоге. Для этого можете именовать файлы при помощи хеширующей функции и разбивать на группы по части имени.
• Сам файлсервер может быть подключен к CDN

Все.

Ок, Fortop.

Давайте по полочкам. Рассматриваем мы бесплатную СУБД.
Oracle и MSSQL Server нет. Денег на них нет, а есть только бесплатный Firebird. У стартапов такое бывает весьма часто. Надо при минимуме бабла, выжать максимум производительности.

Решить следующее:

Файлы пользователей должны храниться вне веб сервера. Система должна быть распределенной и неограниченно масштабируемой. Файловых серверов может быть сколько угодно и они могут добавляться в процессе работы. Нужно иметь возможность достаточно просто организовать миграцию файлов клиента на другой сервер при необходимости (например заполнено 70% места, добавили еще сервер, 35% оставить на старом, 35% переместить на новый так чтобы никто ничего не заметил, и дальше равномерно раскидывать новых клиентов по двум серверам. Потом следующий сервер и т.д.).

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

Какие варианты я вижу для решения этой задачи:
а) Samba-server и cifs, класть файлы локально вне каталога веб сервера
б) Загружать их на файловый сервер по ftp
в) Хранить их в базе данных (каждому аккаунту своя база данных с которой он работает)

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

Отдача файлов.
1) В любом случае это не прямая ссылка, это скрипт с header. Как минимум соображения безопасности это диктуют.
2) Файл может быть сжатым. На мой взгляд для сжатия лучше использовать стандартные архиваторы (они работают эффективно). Перед отдачей пользователю, его надо разархивировать.
В случаях б) и в) файл надо стащить на веб-сервер чтобы сделать эту операцию.
В случае а) можно сразу архиватором читать файл по сети, а оригинал сохранять на веб сервере.
3) Как отдавать.
Самый простой (но возможно действительно не самый эффективный) вариант — как описан в статье. Делаем нужный header и выводим в скрипт данные файла. После файл стираем.

Возможно вы правильно советуете через nginx, я этого не пробовал, но мне стало интересно, обязательно попробую. Почитал, можно через X-Accel. Он даже может взять их с другого сервера, насколько я понял. В документации сказано что так

location / files {
internal;
proxy_pass http://127.0.0.2;
}

Да, соглашусь, неплохо все. Но как же масштабируемость? А если много серверов откуда надо брать? Т.е. надо скриптом их грузить на этот сервер с которого потом будет отдача и header(«X-Accel-Redirect: /files/». $path);
Вообще предполагаю что можно сделать location / files1{}, location / files2{} и т.д. и в зависимости от того на каком файловом сервере и изымать по нужному пути, но описания этого я сходу не нашел, поэкспериментировать придется.
А вообще именно база данных для хранения файла была выбрана из соображений удобства. Просто бекапить, просто мигрировать на другой сервер, просто накатить новый. Купил железку, накатил проксмокс, сделал копию виртуалки, поменял IP, почистил, прописал ее настройки в базе распределения – все подхватилось и все работает. Так же файловая база в моем случае решает проблему хранения типа данных image в моем внутреннем языке программирования, но это мой индивидуальный случай.

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

1. сколько угодно файловых серверов.
   
   • Можно разруливать через приложение, которое по функции определяет к какой шарде обращаться
   • Можно разруливать через nginx, где функцию определения шарды реализовать при помощи того же lua
   • Что из себя представляет функция? В простейшем виде, например, остаток от деления айди на количество серверов, или маппинг по регулярным выражениям от хеша имени файла и т.п.
2. Отдача и проверка прав через скрипт и X-Accel-redirect заголовок
   Техника стара как мир, если погуглить, то можно найти даже решения с expired токенами в ссылке на скачивание
3. Миграции при добавлении новых шард.
   Аналогично легко гуглится. В простейшем случае это несколько скриптов которые производят вычисление шарды по старому и новому методу (добавление или удаление шарды влечет за собой изменение функции).
   И затем выполняют копирование файлов на новый сервер (как и чем? Например, rsync)
   Процесс верификации может быть или одновременно с копированием (мы проверяем идентичность и доступность файла в новом месте), или отдельной задачей по завершению переноса.
   Если есть ошибки, то повторить копирование и/или выдать сообщение в лог для разбора.
   Процесс удаления старых файлов выполняется только при успешной верификации и так же может идти для каждого файла сразу при копировании, или пакетно для всех по завершении верификации.
4. бекап выполняется для всей системы сразу и отдельно администратором.
   Бекап отдельного аккаунта иногда целесообразен, если подразумевается активное удаление/добавление файлов самим пользователем и приложение хочет предоставить возможность отката действий самого пользователя.
   В общем случае вместе с отправкой этого бекапа куда-либо это функция экспорта информации. Выполняется отдельным скриптом/модулем приложения.
5. Компрессия/декомпрессия файлов не относится к общему случаю.
   Объём диска обычно дешевле процессорного времени, если вы не файл/фото хостинг
   Поэтому сжимать изначально — нет смысла, поскольку это относится к оптимизации.
   Лучше потратить время разработки на более критичные фичи.
6. Компрессия/декомпрессия, и Linux и Windows умеют сжатие разделов целиком. То есть это можно настраивать вне вашего приложения и абсолютно прозрачно для него.
7. Отдача, nginx умеет кешировать соответственно буде мы решили сжимать файлы самостоятельно и поштучно, то можно настраивать кеширование для распакованных файлов. Удалять nginx будет самостоятельно, следить нам не надо, только выставить нужные сроки инвалидации
8. Загрузка файлов.
   При наличии множества шард нам придётся реализовать загрузку на выбранную шарду
   Механизм похож на скачивание. Сначала определить на какую шарду поместить хотим, затем залить.
   Можно генерировать служебное имя файла заранее, тогда адрес загрузки вместе с нужным именем шарды отдавать сразу с формой клиенту и он при отправке будет грузить сразу в нужное место.
   Но можно и изначально грузить на сервер приложения и переносить на нужную шарду.
9. Не вижу проблемы хранения картинок в виде файлов.

Что касается простоты.
Да, хранить все в одной БД — проще.
Это пока единственный аргумент "за".
Но для случаев, когда "проще" имеет смысл — о масштабировании проще забыть.
Или то, или другое.

Более конкретные рецепты реализации зависят от того что именно пишется.
Какие задачи выполняет приложение и т.д.
Ну и для почитать http://ruhighload.com/server