我想存储最多10M文件，2TB存储单元。我需要的唯一属性仅限于文件名及其内容（数据）。
文件max-length为100MB，大部分都小于1MB。需要删除文件的能力，写入和读取速度都应该是优先考虑的事项 - 而不需要低存储效率，恢复或完整性方法。
我考虑过NTFS，但是大多数功能都不需要，虽然不能被禁用并被认为是一个开销问题，其中一些是：创建日期，修改日期，属性，日志和权限。
由于文件系统的本机功能不需要，您是否建议我将SQLITE用于此要求？或者我应该注意一个明显的缺点？ （有人会猜测删除文件将是一项复杂的任务吗？）
（SQLITE将通过C api）
我的目标是使用更合适的解决方案来获得性能。在此先感谢 - Doori酒吧
如果您的主要要求是性能，请使用本机文件系统。 DBMS不适合处理大型BLOB，因此SQLite根本不适合您（甚至不知道为什么每个人都认为SQLite是每个漏洞的插件）。
要提高NTFS（或您选择的任何其他文件系统）的性能，请不要将所有文件放在单个文件夹中，而是将文件按文件名的前N个字符或扩展名分组。
市场上还存在一些其他文件系统，其中一些可能会禁用某些已使用的功能。你可以检查comparison on Wikipedia并检查它们。
更正：我已经做了一些测试（虽然不是很广泛），在大多数类型的操作中将文件分组到子目录中没有显示性能优势，并且NTFS在单个目录中非常有效地处理了从AAAA到ZZZZ命名的26 ^ 4个空文件。因此，您需要检查特定文件系统的效率。
官方SQLite站点实际上是includes a page，它记录了在各种操作系统中使用数据库而不是本机文件系统的性能优势。当存储~10 KiB sqlite的文件大约快35％。
SQLite读取和写入小blob（例如缩略图图像）比使用fread（）或fwrite（）从磁盘上的单个文件读取或写入相同的blob快35％。
此外，一个容纳10千字节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的链接，您可以使用该链接在您自己的硬件/操作系统上重现这些结果。