sqlite java性能,具有非常大的数据库文件的sqlite的性能特征是什么？ [关闭]

所以我用sqlite对非常大的文件进行了一些测试，得出了一些结论(至少对我的具体应用来说) .

测试涉及单个sqlite文件，包含单个表或多个表 . 每个表有大约8列，几乎所有整数和4个索引 .

想法是插入足够的数据，直到sqlite文件大约50GB .

Single Table

我试图只用一个表将多行插入sqlite文件 . 当文件大约7GB(抱歉我不能具体说明行数)时，插入时间太长了 . 我估计我插入所有数据的测试需要24小时左右，但即使在48小时后也没有完成 .

这使我得出结论，单个非常大的sqlite表将存在插入问题，并且可能还有其他操作 .

我想这并不奇怪，因为表变大，插入和更新所有索引需要更长时间 .

Multiple Tables

然后我试着通过分割数据时间超过几张 table ，每天一张 table . 原始1表的数据被分成约700个表 .

这个设置没有插入问题，随着时间的推移，它不需要更长的时间，因为每天都会创建一个新表 .

Vacuum Issues

正如i_like_caffeine所指出的，VACUUM命令是一个问题，sqlite文件越大 . 随着更多插入/删除操作，磁盘上文件的碎片将变得更糟，因此目标是定期VACUUM优化文件并恢复文件空间 .

但是，正如documentation所指出的那样，数据库的完整副本是做真空的，需要很长时间才能完成 . 因此，数据库越小，此操作完成的速度就越快 .

Conclusions

对于我的特定应用程序，我可能会将数据分成几个db文件，每天一个，以获得最佳的真空性能和插入/删除速度 .

这使查询变得复杂，但对我来说，能够索引这么多数据是值得的权衡 . 另一个优点是我可以删除整个db文件以删除一天的数据(我的应用程序的常见操作) .

我可能不得不监控每个文件的表大小，以查看速度何时成为问题 .

它's too bad that there doesn'似乎是除了auto vacuum之外的增量真空方法 . 我可以't use it because my goal for vacuum is to defragment the file (file space isn'一个大问题，这是自动真空无法做到的 . 事实上，文档说它可能会使碎片变得更糟，所以我不得不求助于定期对文件进行全真空 .