我想存储多达 1000 万个文件，2TB 存储单元。我需要的唯一属性仅限于文件名及其内容（数据）。
文件最大长度为 100MB，大部分小于 1MB。删除文件的能力是必需的，写入和读取速度都应该是优先考虑的 - 而不需要低存储效率、恢复或完整性方法。
我考虑过 NTFS，但它的大部分功能都不需要，虽然不能禁用并且被认为是开销问题，但其中一些是：创建日期、修改日期、属性、日志，当然还有权限.
由于不需要文件系统的本机功能，您是否建议我使用 SQLITE 来满足此要求？还是我应该注意一个明显的缺点？ （有人会猜测删除文件将是一项复杂的任务？）
（SQLITE 将通过 C api）
我的目标是使用更合适的解决方案来获得性能。在此先感谢 - Doori 酒吧
【问题讨论】：
标签： database sqlite filesystems archive ntfs
官方 SQLite 站点实际上是 includes a page，它记录了在各种操作系统中使用数据库而不是本机文件系统的性能优势。存储大约 10 KiB 的文件时，sqlite 的速度大约快 35%。
SQLite 读取和写入小块（例如，缩略图） 比读取或写入相同 blob 的速度快 35%¹ 使用 fread() 或 fwrite() 在磁盘上的单个文件。
此外，拥有 10 KB blob 的单个 SQLite 数据库使用 与将 blob 存储在单个文件中相比，磁盘空间减少了约 20%。
出现性能差异（我们相信）是因为在工作时 从 SQLite 数据库中，open() 和 close() 系统调用是 只调用一次，而 open() 和 close() 只调用一次 使用存储在单个文件中的 blob 时的每个 blob。看起来 调用 open() 和 close() 的开销大于 使用数据库的开销。尺寸减小源于 事实上，单个文件被填充到下一个倍数 文件系统块大小，而 blob 被更紧密地打包到 SQLite 数据库。
本文中的测量是在 2017-06-05 使用 3.19.2 和 3.20.0 之间的 SQLite 版本。你 预计未来版本的 SQLite 性能会更好。
您在使用较大的文件时可能会遇到不同的结果，SQLite 站点包含一个指向 kvtest 的链接，您可以使用该链接在您自己的硬件/操作系统上重现这些结果。
【讨论】：
如果您的主要要求是性能，请使用本机文件系统。 DBMS 不太适合处理大型 BLOB，因此 SQLite 根本不适合您（甚至不知道为什么每个人都认为 SQLite 是每个漏洞的塞子）。
为了提高 NTFS（或您选择的任何其他文件系统）的性能，不要将所有文件放在单个文件夹中，而是按文件名的前 N 个字符或扩展名对文件进行分组。
市场上还存在一些其他文件系统，其中一些可能提供禁用某些已使用功能的可能性。您可以查看comparison on Wikipedia 并查看它们。
更正：我已经进行了一些测试（虽然不是很广泛），但在将文件分组到大多数类型的操作的子目录中没有表现出性能优势，并且 NTFS 非常有效地处理了 26^4 个空文件在单个目录中从 AAAA 命名为 ZZZZ。因此，您需要检查特定文件系统的效率。
【讨论】：