Предложение по созданию пользовательского сервиса хранения файлов - PullRequest
Новая
       15

Предложение по созданию пользовательского сервиса хранения файлов

0 голосов
/ 27 мая 2019

В моем проекте одной из служб является служба хранения файлов, которая выполняет всего 2 задачи: загрузить файл и получить идентификатор, загрузить файл по идентификатору.Ничего больше.Никаких сложностей, таких как пользовательский интерфейс, шифрование (достаточно HTTPS), 100% доступность, дедупликация и т. Д. Всего 2 простых задачи.

Используя ASP .Net Core, для создания и начала использования этой службы требуется полчаса,поскольку он будет использоваться только в локальной сети организации.

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

  1. Какой механизм БД?
  2. Как хранить файлы?

Во время исследования я обнаружил 2 варианта:

  1. SQLite + хранение файлов в подпапках, таких как year / month / day / guid.bin.База данных будет содержать полный путь к файлу с соответствующим GUID.
  2. LiteDB и хранить в нем все.

Плюсы (1):

  • нет файловой системы с большим количеством файлов в одной папке
  • простая файловая БД с простыми запросами

Минусы (1):

  • не уверен, стабильность БД может быть?повреждение файла?какие-либо средства восстановления целостности файлов?
  • использование механизма на основе SQL, где на основе NO-SQL будет работать лучше?

Плюсы (2):

  • все в одном месте (файлы двоичных данных с его GUID)

Минусы (2):

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

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

Что будет лучшим выбором?Или, может быть, есть более лучшие решения?Может быть, простой сторонний сервис без большого вздутия функциональности?

1 Ответ

1 голос
/ 31 мая 2019

Если несколько пользователей будут использовать одну и ту же базу данных, я рекомендую использовать сервер базы данных (Sql Server / MongoDB) вместо файловой базы данных (SqlLite / LiteDb).Даже если это не отдельный физический сервер, использование технологии, разработанной для одновременного доступа нескольких клиентов, обеспечит вам гораздо лучшую масштабируемость.Файловые базы данных обычно разрабатываются для однопользовательских сценариев и быстро становятся узким местом, поскольку только один поток может получить доступ к файлу за один раз.

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

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

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

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

...