Sna*_*zer 317 database sqlite performance
我知道sqlite对于非常大的数据库文件表现不佳,即使它们受支持(曾经在sqlite网站上发表评论,说明如果你需要的文件大小超过1GB,你可能要考虑使用企业rdbms.再找不到它,可能与旧版本的sqlite有关.
但是,出于我的目的,我想在考虑其他解决方案之前了解它到底有多糟糕.
我说的是数千兆字节的sqlite数据文件,从2GB开始.有人对此有经验吗？任何提示/想法？
Sna*_*zer 236
所以我使用sqlite对非常大的文件进行了一些测试,并得出了一些结论(至少对于我的特定应用程序而言).
测试涉及单个sqlite文件,包含单个表或多个表.每个表有大约8列,几乎所有整数和4个索引.
想法是插入足够的数据,直到sqlite文件大约50GB.
单表
我试图在一个只有一个表的sqlite文件中插入多行.当文件大约7GB(抱歉我不能具体说明行数)时,插入时间太长了.我估计我插入所有数据的测试需要24小时左右,但即使在48小时后也没有完成.
这使我得出结论,单个非常大的sqlite表将存在插入问题,并且可能还有其他操作.
我想这并不奇怪,因为表变大,插入和更新所有索引需要更长时间.
多个表格
然后,我尝试将数据按时间分成几个表,每天一个表.原始1表的数据被分成约700个表.
这种设置没有插入问题,随着时间的推移,它不需要更长的时间,因为每天都会创建一个新表.
真空问题
正如i_like_caffeine所指出的,VACUUM命令是一个问题,sqlite文件越大.随着更多插入/删除操作,磁盘上文件的碎片将变得更糟,因此目标是定期VACUUM优化文件并恢复文件空间.
但是,正如文档所指出的那样,数据库的完整副本可以实现真空,需要很长时间才能完成.因此,数据库越小,此操作完成的速度就越快.
结论
对于我的特定应用程序,我可能会将数据分成几个db文件,每天一个,以获得最佳的真空性能和插入/删除速度.
这使查询变得复杂,但对我来说,能够索引这么多数据是值得的权衡.另一个优点是我可以删除整个db文件以丢弃一天的数据(我的应用程序的常见操作).
我可能还需要监控每个文件的表大小,以查看速度何时成为问题.
除了自动真空之外似乎没有增量真空方法太糟糕了.我不能使用它,因为我的真空目标是对文件进行碎片整理(文件空间不是很大),而自动真空无法做到.事实上,文档说它可能会使碎片变得更糟,所以我不得不求助于定期对文件进行全真空.
小智 160
我们在平台上使用50 GB +的DBS.没有抱怨很有效.确保你做的一切正确!您使用的是预定义语句吗？*SQLITE 3.7.3
应用这些设置(在创建数据库后立即)
PRAGMA main.page_size = 4096;
PRAGMA main.cache_size=10000;
PRAGMA main.locking_mode=EXCLUSIVE;
PRAGMA main.synchronous=NORMAL;
PRAGMA main.journal_mode=WAL;
PRAGMA main.cache_size=5000;
希望这会有所帮助,在这里工作得很好
Pau*_*vre 63
我创建了最大3.5GB的SQLite数据库,没有明显的性能问题.如果我没记错的话,我认为SQLite2可能有一些下限,但我不认为SQLite3有任何这样的问题.
根据SQLite Limits页面,每个数据库页面的最大大小为32K.并且数据库中的最大页数为1024 ^ 3.所以根据我的数学计算,最大尺寸为32TB.我想你会在点击SQLite之前达到文件系统的限制!
小智 51
花费大约48小时进行插入的大部分原因是因为你的索引.它非常快:
1 - 删除所有索引2 - 执行所有插入3 - 再次创建索引
Les*_*ung 32
除了通常的建议:
我从SQLite3的经验中学到了以下内容:
欢迎提问/评论.;-)
小智 8
在SQLite文档中曾经有一条声明,数据库文件的实际大小限制是几十GB.这主要是因为每当您启动事务时,SQLite都需要"分配脏页的位图".因此,数据库中的每个MB需要256字节的RAM.插入50 GB的DB文件需要大量(2 ^ 8)*(2 ^ 10)= 2 ^ 18 = 256 MB的RAM.
但是,从SQLite的最新版本开始,不再需要这样做了.在这里阅读更多.
小智 8
我有一个7GB的SQLite数据库.使用内部联接执行特定查询需要2.6s为了加快速度,我尝试添加索引.根据我添加的索引,有时查询下降到0.1秒,有时上升到7秒.我认为我的问题是,如果列高度重复,那么添加索引会降低性能:(
| 归档时间： |
|
| 查看次数： |
155717 次 |
| 最近记录： |