有关创建自定义文件存储服务的建议

Question

在我的项目中，服务之一是仅执行两个任务的文件存储服务：上传文件并获取ID，然后按ID下载文件。没有其他的。没有花哨的东西，例如UI，加密（HTTPS就足够了），100％的可用性，重复数据删除等。只有2个简单的任务。

使用ASP .Net Core，此服务需要半小时才能创建和开始使用，因为该服务仅在组织的本地网络中使用。

但是在开始之前，我有几件事要考虑：

1. 哪个Db引擎？
2. 如何存储文件？

在调查时，我发现了两种变体：

1. SQLite +将文件存储在子文件夹中，例如年/月/日/guid.bin。数据库将包含具有适当GUID的文件的完整路径。
2. LiteDB并将所有内容存储在其中。

（1）的优点：

• 没有文件系统在一个文件夹中浪费大量文件
• 具有简单查询的基于简单文件的数据库

（1）的缺点：

• 在这里不确定，也许数据库的稳定性？文件损坏？有什么方法可以恢复文件完整性？
• 使用基于SQL的引擎在NO-SQL更好的情况下使用

（2）的优点：

• 一切都集中在一个地方（文件二进制数据带有GUID）

（2）的缺点：

一切都集中在一处？换句话说，一段时间后，非常大的单个文件。出现一个小故障就全部消失了，但是当将文件存储在子文件夹中时，所有文件损坏的可能性很小（对于整个硬盘驱动器故障而言，它们并不占优势）。

此外，选择一个嵌入式的基于文件的数据库也将强制使用某些手动备份（第三方服务），并且仅依赖于此。它使开发和部署变得简单（例如，备份时文件将始终与数据库同步），但另一方面却很难。

什么是最佳选择？还是有更多更好的解决方案？也许没有很多功能膨胀的简单第三方服务？

Answer 1

假设多个用户将使用同一数据库，我建议使用数据库服务器（Sql Server / MongoDB）而不是基于文件的数据库（SqlLite / LiteDb）。即使它不是单独的物理服务器，使用旨在由多个并发客户端访问的技术也会为您提供更好的可伸缩性。基于文件的数据库通常是为单用户方案设计的，由于每次只能有一个线程访问文件，因此它会很快成为瓶颈。

关于使用Sql还是NoSql-我建议设计您编写的代码以最大程度地减少改变主意的成本。从当前的需求列表中选择一项似乎并没有多大好处，以我个人的经验，这种情况通常会导致以下两种结果之一：

1. 该项目的使用量有限，技术选择无关紧要
2. 该项目被广泛采用，以我们无法预料的方式使用，现在我们急于赶上

在任何一种情况下，花在前期尝试上的时间都没有多大用处。话虽这么说，但仍然有必要进行预先研究（就像您一样），因为先验知识是在时间紧迫的情况下做出良好决策的绝佳工具。

最后，您没有提及任何有关安全性的信息-如果您的组织有安全性专家，我强烈建议您在设计系统时与他们紧密合作。任意文件上传都可以用作攻击媒介，因此验证上传内容和目的地非常重要。