我需要将 SQLite 数据库中的大量数据存储在文件服务器上。我有机会将数据拆分成多个文件。这意味着大部分数据损坏的风险更小，移动起来也更容易。锁定等问题更少。我的问题是，多少个文件才算太多。100,000？1,000,000？10,000,000 个文件？换句话说，在文件服务器上创建文件的开销是多少？当我谈到开销时，我指的是创建文件的旋转次数。我知道块和块大小，我并不担心存储在多个文件中会浪费存储空间。
我的问题不是关于是否最好将这样的数据库存储在文件服务器上，而不是使用利用其他数据库软件的适当的数据库服务器。
环境是微软环境，但是对于文件服务器的具体内容不太了解。
答案1
SQLite 是一款非常酷的产品 - 但如果您通过网络访问数据库，使用基于文件的访问方式是非常糟糕的主意 - 即使数据库是只读的，并且您不需要担心任何并发性，性能也会很糟糕。您必须拥有非常这样做的充分理由。
实际上，假设性能、并发性和锁定不是问题，我认为创建 1000 个文件或将相同数据批量写入 10 个文件之间不会有任何显著差异，但这将根据底层文件系统的性质而有很大差异。另一方面，由于许多事务在文件中随机发生，我预计较少的文件数量会更高效。对于读取，我预计会有类似的模式。但只有一种方法可以确定 - 尝试一下。
答案2
如果文件夹中的文件超过 10,000 个，则使用资源管理器访问会很困难。可以通过将其分解为文件夹树来避免这种情况。
此外，如果您的文件不是簇大小（通常为 4KB）的倍数，那么它们将浪费每个文件的剩余部分。根据文件大小，这可能很大，也可能不很大。
此外，由于开销，访问许多小文件的速度很慢。这可能会限制备份等操作的速度。如果您可以设计您的用法以按顺序读取较大的文件并在内存中进行随机访问，那么您会更好。