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