Подтвердить что ты не робот

Хранилище файлов для веб-приложений: файловая система vs DB vs NoSQL

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

  • Когда мы перемещаем "папки" (как определено нашим приложением), мы также должны перемещать файлы на диск (хотя это связано, в основном, с необычными дизайнерскими решениями со стороны оригинальных разработчиков, чем с требованием хранить вещи на файловая система).
  • Трудно писать тесты для действий файловой системы; У меня есть класс файловой системы mock, который регистрирует такие действия, как move, delete и т.д., Не выполняя их, что более или менее выполняет задание, но у меня нет 100% уверенности в тестах.
  • Я добавлю некоторые другие задания, которым необходимо получить доступ к файлам из другой службы для выполнения дополнительных задач (например, индексирование в Solr, создание эскизов, преобразование формата фильма), поэтому мне нужно удаленно получать файлы. Выполнение этого по сетевым ресурсам кажется изворотливым...
  • Работа с разрешениями на файловую систему, поскольку иногда это давало нам проблемы в прошлом, хотя теперь, когда мы перешли в чистую Linux-среду, это должно быть меньше проблем.

Итак, мои основные вопросы:

  • Каковы недостатки хранения файлов в виде BLOB в MySQL?
  • Существуют ли те же проблемы с системами NoSQL, такими как Cassandra?
  • Есть ли у кого-нибудь другие предложения, которые могут быть подходящими, например. MogileFS и т.д.
4b9b3361

Ответ 1

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

Каковы недостатки хранения файлов в виде BLOB в MySQL?

Существуют ли те же проблемы с системами NoSQL, такими как Cassandra?

PS: Я не хочу быть killjoy, но я не думаю, что любое решение NoSQL решит вашу проблему (NoSQL просто не имеет отношения к большинству компаний).

Ответ 2

может быть гибридное решение.

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

любая реструктуризация "папок" может быть смоделирована в БД и разыменована из фактического местоположения ОС.

Ответ 3

Вы можете хранить файлы до 2 ГБ в Cassandra, разбивая их на столбцы 1 МБ или около того. Это довольно часто.

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

Ответ 4

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

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

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