Предложение по созданию собственной службы хранения файлов
В моем проекте один из сервисов — это сервис File Storage с двумя задачами: загрузить файл и получить ID, скачать файл по ID. Ничего больше. Никаких заумных вещей, таких как пользовательский интерфейс, шифрование (достаточно HTTPS), 100% доступность, дедупликация и т. д. Всего 2 простых задачи.
При использовании ASP .Net Core этот сервис создается и начинает использоваться за полчаса, так как он будет использоваться только в локальной сети организации.
Но есть несколько вещей, которые я хотел бы рассмотреть перед началом:
- Какой дб двигатель?
- Как хранить файлы?
При расследовании я пришел к 2 вариантам:
- SQLite + хранение файлов в подпапках типа год/месяц/день/guid.bin. База данных будет содержать полный путь к файлу с соответствующим GUID.
- LiteDB и хранить в нем все.
Плюсы (1):
- отсутствие засорения файловой системы большим количеством файлов в одной папке
- простая файловая БД с простыми запросами
Минусы (1):
- тут не уверен, стабильность БД возможно? повреждение файла? любые средства восстановления целостности файлов?
- использование движка на основе SQL, где лучше работать на основе NO-SQL?
Плюсы (2):
- все в одном месте (бинарные данные файлов со своим GUID)
Минусы (2):
- все в одном месте? другими словами, очень-очень большой файл через некоторое время. небольшой сбой в нем и все прошло, тогда как при хранении файлов в подпапках вряд ли все они будут испорчены (не считая полного отказа жесткого диска).
Кроме того, выбор встроенной файловой базы данных вынуждает использовать некоторое ручное резервное копирование (сторонний сервис) и полагаться только на него. Это упрощает разработку и развертывание (например, файлы всегда будут синхронизированы с базой данных при резервном копировании), но с другой стороны усложняет работу.
Что было бы лучшим выбором? Или, возможно, есть более лучшие решения? Возможно, простой сторонний сервис без особого наворота функционала?
Ответы 1
Предполагая, что несколько пользователей будут использовать одну и ту же базу данных, я рекомендую использовать сервер базы данных (Sql Server/MongoDB) вместо файловой базы данных (SqlLite/LiteDb). Даже если это не отдельный физический сервер, использование технологии, предназначенной для одновременного доступа нескольких клиентов, даст вам гораздо лучшую масштабируемость. Файловые базы данных обычно разрабатываются для однопользовательских сценариев и быстро становятся узким местом, поскольку только один поток может получить доступ к файлу за раз.
Что касается того, использовать ли Sql или NoSql, я рекомендую разрабатывать код, который вы пишете, чтобы свести к минимуму затраты на изменение вашего решения. Ваш текущий список требований, похоже, не сильно выигрывает от выбора одного над другим, и, по моему личному опыту, эта ситуация обычно приводит к одному из двух результатов:
- проект используется в ограниченном объеме и выбор технологии не имел значения
- проект получил широкое распространение, его используют способами, которых мы не могли ожидать, и теперь мы спешим наверстать упущенное.
В любом случае время, потраченное заранее на принятие решения, не принесет много пользы. Тем не менее, все же стоит провести предварительное исследование (как у вас), поскольку предварительные знания являются отличным инструментом для принятия правильных решений в условиях дефицита времени.
Наконец, вы ничего не упомянули о безопасности — если в вашей организации есть специалисты по безопасности, я настоятельно рекомендую тесно сотрудничать с ними при разработке системы. Произвольные загрузки файлов могут использоваться как вектор атаки, поэтому проверка содержимого и адресата загрузки очень важна.
Я выбрал файловое решение из-за простоты резервного копирования. Таким образом, они будут синхронизироваться с файлами, используя операцию резервного копирования (просто сделайте резервную копию папки с базой данных и двоичными файлами, и все). Но я понимаю вашу точку зрения. Спасибо.