关于创建自定义文件存储服务的建议
Suggestion about creating custom File Storage Service
在我的项目中，其中一项服务是文件存储服务，只有 2 个任务：上传文件并获取 ID，通过 ID 下载文件。没有其他的。没有花哨的东西，比如 UI、加密（HTTPS 就足够了）、100% 可用性、重复数据删除等。只有 2 个简单的任务。
使用 ASP .Net Core 此服务需要半小时才能创建并开始使用，因为它将仅在组织的本地网络中使用。
但是在开始之前我想考虑一些事情：
- 哪个数据库引擎？
- 如何存储文件？
在调查过程中，我发现了 2 个变体：
- SQLite + 将文件存储在子文件夹中，例如 year/month/day/guid.bin。数据库将包含带有适当 GUID.
的文件的完整路径
- LiteDB 并将所有内容存储在其中。
(1) 的优点：
- 没有文件系统垃圾，一个文件夹中有很多文件
- 具有简单查询的基于文件的简单数据库
(1) 的缺点：
- 这里不确定，也许是数据库的稳定性？文件损坏？任何恢复文件完整性的方法？
- 使用基于 SQL 的引擎，而基于 NO-SQL 的引擎效果更好？
(2) 的优点：
- 一切都在一个地方（文件二进制数据及其 GUID）
(2) 的缺点：
- 一切都集中在一个地方？换句话说，一段时间后一个非常非常大的单个文件。一个小故障就全部消失了，而当将文件存储在子文件夹中时，它们不太可能全部损坏（不考虑完全硬盘驱动器故障）。
此外，选择基于文件的嵌入式数据库会强制使用一些手动备份（第三方服务）并且仅依赖于此。它使开发和部署变得简单（例如，备份时文件将始终与数据库同步），但另一方面却很难。
最好的选择是什么？或者也许有更多更好的解决方案？也许是一个简单的第三方服务，没有太多的功能膨胀？
假设多个用户将使用同一个数据库，我建议使用数据库服务器（Sql服务器/MongoDB）而不是file-based数据库（SqlLite/LiteDb） .即使它不是单独的物理服务器，使用设计为可同时被多个客户端访问的技术也会为您提供更好的可扩展性。 File-based 数据库通常是为 single-user 场景设计的，并且很快就会成为瓶颈，因为一次只有一个线程可以访问文件。
关于是使用Sql还是否Sql——我建议设计你写的代码，尽量减少改变主意的成本。您当前的需求列表似乎并没有从选择一个需求中受益太多，而且根据我个人的经验，这种情况通常会导致以下两种结果之一：
- 该项目的使用能力有限，技术选择无关紧要
- 该项目被广泛采用，以我们无法预料的方式使用，现在我们正赶上进度
在任何一种情况下，花费时间 up-front 试图做出决定都没有多大用处。话虽如此，研究 up-front（正如您所做的那样）仍然值得，因为先验知识是在时间压力下做出正确决策的绝佳工具。
最后，您没有提及任何有关安全的内容 - 如果您的组织有安全专家，我强烈建议您在设计系统时与他们密切合作。任意文件上传都可以用作攻击媒介，因此验证上传的内容和目的地非常重要。
在我的项目中，其中一项服务是文件存储服务，只有 2 个任务：上传文件并获取 ID，通过 ID 下载文件。没有其他的。没有花哨的东西，比如 UI、加密（HTTPS 就足够了）、100% 可用性、重复数据删除等。只有 2 个简单的任务。
使用 ASP .Net Core 此服务需要半小时才能创建并开始使用，因为它将仅在组织的本地网络中使用。
但是在开始之前我想考虑一些事情：
- 哪个数据库引擎？
- 如何存储文件？
在调查过程中，我发现了 2 个变体：
- SQLite + 将文件存储在子文件夹中，例如 year/month/day/guid.bin。数据库将包含带有适当 GUID. 的文件的完整路径
- LiteDB 并将所有内容存储在其中。
(1) 的优点：
- 没有文件系统垃圾，一个文件夹中有很多文件
- 具有简单查询的基于文件的简单数据库
(1) 的缺点：
- 这里不确定，也许是数据库的稳定性？文件损坏？任何恢复文件完整性的方法？
- 使用基于 SQL 的引擎，而基于 NO-SQL 的引擎效果更好？
(2) 的优点：
- 一切都在一个地方（文件二进制数据及其 GUID）
(2) 的缺点：
- 一切都集中在一个地方？换句话说，一段时间后一个非常非常大的单个文件。一个小故障就全部消失了，而当将文件存储在子文件夹中时，它们不太可能全部损坏（不考虑完全硬盘驱动器故障）。
此外，选择基于文件的嵌入式数据库会强制使用一些手动备份（第三方服务）并且仅依赖于此。它使开发和部署变得简单（例如，备份时文件将始终与数据库同步），但另一方面却很难。
最好的选择是什么？或者也许有更多更好的解决方案？也许是一个简单的第三方服务，没有太多的功能膨胀？
假设多个用户将使用同一个数据库，我建议使用数据库服务器（Sql服务器/MongoDB）而不是file-based数据库（SqlLite/LiteDb） .即使它不是单独的物理服务器，使用设计为可同时被多个客户端访问的技术也会为您提供更好的可扩展性。 File-based 数据库通常是为 single-user 场景设计的，并且很快就会成为瓶颈，因为一次只有一个线程可以访问文件。
关于是使用Sql还是否Sql——我建议设计你写的代码，尽量减少改变主意的成本。您当前的需求列表似乎并没有从选择一个需求中受益太多，而且根据我个人的经验，这种情况通常会导致以下两种结果之一：
- 该项目的使用能力有限，技术选择无关紧要
- 该项目被广泛采用，以我们无法预料的方式使用，现在我们正赶上进度
在任何一种情况下，花费时间 up-front 试图做出决定都没有多大用处。话虽如此，研究 up-front（正如您所做的那样）仍然值得，因为先验知识是在时间压力下做出正确决策的绝佳工具。
最后，您没有提及任何有关安全的内容 - 如果您的组织有安全专家，我强烈建议您在设计系统时与他们密切合作。任意文件上传都可以用作攻击媒介，因此验证上传的内容和目的地非常重要。