文件系统 vs SQLite,在存储高达10M的文件时。

12

我想存储高达10M个文件,2TB的存储单元。我只需要对文件名和它们的内容(数据)进行限制。

文件的最大长度为100MB,其中大多数小于1MB。需要能够删除文件,并且写入和读取速度应该是优先考虑的,而存储效率、恢复或完整性方法则不是必须的。

我考虑使用NTFS,但大部分功能都不需要,而且无法禁用,因此被视为一个额外的负担。其中一些功能包括:创建日期、修改日期、属性、日志以及许可证。

由于不需要文件系统的本机功能,您是否建议我在这种情况下使用SQLITE?或者有一些明显的缺点需要注意吗?(人们可能会猜测删除文件将是一项复杂的任务?)

(SQLITE将通过C API实现)

我的目标是使用更适合的解决方案来提高性能。谢谢!- Doori Bar

2个回答

15

SQLite官方网站实际上包含一个页面,记录了在各种操作系统中使用数据库与本地文件系统相比的性能优势。当存储大约10 KiB的文件时,SQLite大约快35%。

SQLite读写小的blob(例如缩略图图像)比使用fread()或fwrite()从磁盘上的单个文件读取或写入相同的blob快35%¹。

此外,一个包含10 KB blob的单个SQLite数据库使用的磁盘空间大约比将blob存储在单独的文件中少20%。

性能差异产生的原因是(我们认为)在使用SQLite数据库时,只调用一次open()和close()系统调用,而在使用存储在单独文件中的blob时,每个blob都会调用一次open()和close()。看来调用open()和close()的开销比使用数据库的开销更大。大小减小的原因在于单独的文件被填充到下一个文件系统块大小的倍数,而blob更紧密地打包到SQLite数据库中。

本文中的测量是在2017-06-05周使用介于3.19.2和3.20.0之间的SQLite版本进行的。您可以期望未来的SQLite版本表现得更好。

当使用较大的文件时,您可能会遇到不同的结果,并且SQLite网站包含一个kvtest链接,您可以使用它在自己的硬件/操作系统上重现这些结果。


10

如果您主要需求是性能,那么请选择本地文件系统。DBMS 并不适合处理大型 BLOBs,因此 SQLite 完全不适用于您(甚至不知道为什么每个人都认为 SQLite 可以填补所有漏洞)。

为了提高 NTFS(或您选择的任何其他文件系统)的性能,请不要将所有文件放入单个文件夹中,而是按其文件名前 N 个字符或扩展名对文件进行分组。

此外,市场上还有一些其他文件系统,也许其中一些提供禁用某些已使用功能的可能性。您可以在维基百科上查看比较表并进行检查。

更正:我进行了一些测试(虽然不是非常广泛),发现将文件分组到子目录中对大多数操作没有性能优势,而 NTFS 在单个目录中有效地处理了26^4个空文件,它们的名称从AAAA到ZZZZ。因此,你需要针对你特定的文件系统进行效率测试。


1
事实上,任何大于页面大小(有关页面大小相关详细信息,请检查DBMS手册)的blob都可以被视为大型数据。这是因为当数据不适合页面时,存储它的过程比处理短变量大小数据的过程更加复杂。据我所知,一些DBMS也将这些blobs存储为文件系统中的文件。这非常类似于Microsoft推荐的注册表方式 - “您可以在注册表中存储var-sized二进制块,但对于超过2Kb的块,请将这些块放入文件并在注册表中保留引用”。 - Eugene Mayevski 'Callback
@Adrian,您发布的参考链接谈论的是特定的文件系统,而不是用户所询问的NTFS。此外,该链接中介绍的是访问特定文件名的用例场景。在其他场景下,例如目录枚举或添加文件时,随着文件数量的增加,性能会急剧降低。例如,在线性列表中添加文件可能相对较快,但查找速度会变慢。对于索引目录,添加文件将需要重建索引或重新平衡树。因此,通常最好不要过多地向目录中添加文件。 - Eugene Mayevski 'Callback
@Eugine,我想我的主要观点是通过测试验证假设很重要 - 只有在可证明解决问题的情况下才应引入额外的复杂性(非平面)。NTFS使用索引/哈希结构用于文件名,因此也应该很快,但我没有测试过。无论是平面还是非平面,枚举所有文件都需要很长时间。关于重新平衡树的真实情况,但在tru64上添加文件时没有明显的下降,也许NTFS不同,但我怀疑。 - Adrian Smith
6
SQLite实际上有一个页面讨论了在数据库中将文件保存为blob还是外部文件更有效的问题: https://www.sqlite.org/intern-v-extern-blob.html。对于小于一定大小的文件,TL;DR(总之)是将其存储在数据库中会更快(最多快2倍),而对于大文件,访问速度可能会慢得多(慢5倍)。虽然具体细节会随着硬件速度而改变,但对于引用的特定用例,最佳大小范围从默认页面大小下的<25k到更大文件的更优页面大小下的<100k。 - Michael
@EugeneMayevski'Callback - 从这里得知,FAT32分区上的最大文件大小为4GB,可能不超过4,294,967,295字节 - Vérace
显示剩余11条评论

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接