Access SQLite数据库插入数据速度对比(LabSQL/sqlite3.dll/SQLite Library等方法)

石鑫华视觉

Access SQLite数据库插入数据速度对比(LabSQL/sqlite3.dll/SQLite Library等方法)

LabVIEW基于ODBC使用LabSQL操作SQLite数据库
http://visionbbs.com/thread-28283-1-1.html?fromuid=9
(出处: 视觉论坛VISIONBBS|视觉之家VISIONHOME)

LabVIEW基于sqlite3.dll动态链接库函数操作SQLite数据库
http://visionbbs.com/thread-28286-1-1.html?fromuid=9
(出处: 视觉论坛VISIONBBS|视觉之家VISIONHOME)


在上面的两个主题中，我们分别介绍了基于ODBC和基于sqlite3.dll函数的方法来操作SQLite的方法。综合作者的经验，Access在使用LabVIEW操作时（ODBC），内存会缓慢增加，且64位LabVIEW下会的崩溃的问题，这里再来对比看看SQLite会不会增加内存。以及SQLite和Access的插入数据的速度对比。

下面先来看一下Access的操作。这里使用的是LabSQL的库，程序只是简单的打开、循环插入、关闭。

运行前LabVIEW占用104992K内存

运行开始时内存114892K，速度2800+

插入约20万条数据时，内存125184K，比开始时增加了10292K。也就是运行了一段时间插入了20条数据，内存增加了10M左右。而从开始时到结束时，以及观察中间的实时速度，插入的速度大概是在2800条/秒左右。最快也不到3000条/秒的样子。速度其实是比较慢的。插入的数据其实是很简单的，就是前面主题中介绍的用户表的数据（用户名、密码、权限）这样的。三个字符串字段，每个字段使用随机10字符的的方式来插入数据。每条插入的数据量其实非常小。
下面再来看一下LabSQL操作SQLite：

LabSQL方式操作SQLite初始情况，内存108808K

运行初108848K，速度1.28条/秒

中间108864，4.66条/秒

内存108892，速度7.33条/秒
这里首先不看其占用内存情况，光看这速度，完全接受不了啊。每秒钟插入几条数据，这谁顶得住？然后又搜索了一些知识点。原来SQlite是属于事务型数据库，频繁的插入数据，相当于是频繁的打开磁盘上的文件，非常占用IO。所以，这里的速度是非常慢的。解决办法，当然是优化一下这个速度。比较合适的方法是打开事务功能，在插入的循环前，执行SQL语句begin;，表示开始插入。在插入的循环后，执行commit;，表示提交数据。这里的过程，begin时相当于是插入的数据，仅保存在内存中，并没有实际写到数据库文件中。仅当commit提交后，才将数据写入SQLite的数据库文件中。

使用事务功能，运行初，速度12364，内存113672K

插入50万条数据，内存113612K，速度11821

插入100万条数据，内存113612，速度11386

停止，提交，提交过程100万数据花费了很多秒钟，有卡顿的问题。数据量越大，卡顿越久。内存113620K。
从上面的对比来看，LabSQL操作SQLite数据库时，LabVIEW的内存没有增加，一直保持在113M左右。而这种事务方式，插入速度也保持在11000+以上。但是这种方法，最后提交时，会卡顿。对于实际运行测试测量程序，可能不是太理想。
借鉴其他人的参考知识，可以关闭数据库的同步操作，执行语句PRAGMA synchronous = OFF;这样可以提交时不用同步操作，而执行异步的操作，这样程序就不会卡顿了。

启用异步操作时，开始内存120460，速度11094

插入50万条数据内存120524，速度 11437
可以看到，速度同样稳定在11000条/s左右。而内存则在12000K左右。而且停止LabVIEW时，程序立马停止。

通过SQLiteStudio查看数据库数据，可以看到有200多万条数据，前面同步时写了100万条数据，后面异步时写了50万条数据。作者其它测量还有50多万条数据。
通过异步方式，就可以在LabVIEW的WHILE测试循环内，定时的使用commit指令来提交数据。

下面再来看一下sqlite3.dll函数方式的执行速度与内存占用：

操作1.db，数据库为空，初始时内存为112480K

同步不开事务直接写速度也是非常慢的，没有意义

运行初始时，速度41492（开始时内存开销少，速度快），内存113612K

中间50万条数据，速度28322，内存114188K

100万条数据，速度27341，内存114188
在后面时可以看到，内存稳定在114M左右，而速度则稳定在28000左右。

停止后提交数据到数据库中，数据库保存了数据
从上面的的效果可以看到，这个sqlite3.dll的28000条/秒的速度，就要比LabSQL的11000条/秒的速度要快一倍不止。是access的2800条/秒的10倍。如果有高速数据库插入的测试测量项目，使用sqlite数据库，并且使用sqlite3.dll的库函数来驱动数据库的方式，效率要高不少。不过作者看到别人使用VC编程时，开启事务功能，速度要达到37000，而使用异步则42000条左右，而使用prepare先编译再执行，速度更是达到了26万条/秒。使用LabVIEW时，除了LabVIEW本身的执行效率外，还有很多可优化的空间，这里作者没有太多研究（按照他人的方法，稍微研究了一下使用prepare+bind_double+step+reset+finalize方式，但是因为LabVIEW的while中要添加bind_double+step+reset三类函数，实际运行起来，感觉还没有exec的执行速度快）。
prepare+bind_text+step+reset+finalize方式的执行效率
平稳工作时，写入速度仅11000条/秒左右的速度。还不如前面的exec的速度。这里应该是作者还没有掌握sqlite的精髓。
在NI VIPM中可以搜索安装一个SQLite Library的库，专门用于SQLite操作的。这个库和LabSQL一样，也是免费的。另外还有GDataBase for SQLite的库也可以操作SQLite，不过这个库中要收费的，仅能试用30天。因为是第三方工具，还不能使用你懂的工具来破姐。

VIPM安装SQLite Library

SQLite Library库位于LabVIEW程序框图的位置

开始时94336K内存

运行初始时，内存95896K，速度59480条/秒

写入150万条数据时，内存95924K，速度32559

写入200万条数据时，内存95896K，速度31741

停止工作，数据提交到数据库文件中
从上面的效果来看SQLite Libray的效率，要比我们前面使用的几种方法都要高，稳定在32000条左右的速度。查看了一下内部的框图，SQL语句使用了字符串指针来处理，还使用了一些元素同址操作之类的，应该是可以加快处理速度的。想深入了解的，可以研究一下框图的内部，不过相对来说还是比较复杂的。

cxksjy

还有个库速度更快，基本能达到你说的26W+/S

石鑫华视觉

cxksjy 发表于 2022-3-30 11:07
还有个库速度更快，基本能达到你说的26W+/S

神马库？免费的吗？