eXtremeDB 与 SQLite的对比

表1. eXtremeDB IMDS与SQLite的对比（所有数据都存储在内存中）。

显示为红色的是SQLite性能优于eXtremeDB的方面 

 

内存存储基准测试 （时间，以毫秒为单位）
	SQLite	eXtremeDB		eXtremeDB相对于SQLite的优势	eXtremeSQL		eXtremeSQL相对于SQLite的优势
Test1-1000次INSERT操作	4	<1		至少4倍	2		2.0
Test2-在单事务中进行25,000次INSERT操作	154	47		3.28	58		2.7
Test3-在一个已经建立索引的表中，进行25,000次INSERT操作	239	59		4.05	68		3.5
Test 4-在没有建立索引的情况下，进行100次SELECT操作	325	499		0.65	905		0.4
Test 5-在字符串比较中，进行100次SELECT操作	800	734		1.09	1440		0.6
Test 6-创建索引	87	29		3.00	不适用		不适用
Test 7-在已经建立索引的情况下，进行5,000次SELECT操作	119	52		2.29	119		1.0
Test 8-在没有建立索引的情况下，进行1,000次UPDATE操作	122	193		0.63	330		0.4
Test 9-在没有建立索引的情况下，进行25,000次UPDATE操作	313	63		4.97	87		3.6
Test 10-在已经建立索引的情况下，进行25,000次文本UPDATE操作	250	32		7.81	60		4.2
Test 11-从一个SELECT进行INSERT操作	143	135		1.06	143		1.0
Test 12-在没有建立索引的情况下，进行DELETE操作	29	27		1.07	35		0.8
Test 13-在已经建立索引的情况下，进行DELETE操作	102	69		1.48	77		1.3
Test 14-在进行一次大量DELETE操作之后，进行一次大量INSERT操作	119	81		1.47	81		1.5
Test 15-在多次小量INSERT操作之后，进行一次大量DELETE操作	73	41		1.78	46		1.6
Test 16-DROP TABLE操作	1	<1		不清楚	不适用		不适用

 

表2. eXtremeDB混合版与SQLite的对比（对所有数据使用磁盘存储）。

显示为红色的是SQLite性能优于eXtremeDB混合版的方面

持续性存储基准测试
（时间，以毫秒为单位）
	SQLite	eXtremeDB	eXtremeDB相对于SQLite的优势	eXtremeSQL	eXtremeSQL相对于SQLite的优势
Test 1-1000次INSERT操作	1073	3	357.77	3	357.77
Test 2-在一个事务中，进行25,000次INSERT操作	422	64	6.59	71	5.94
Test 3-在一个已经建立索引的表中，进行25K次INSERT操作	698	75.7	9.22	83.3	8.38
Test 4-在没有建立索引的情况下，进行100次SELECT操作	100	425	0.24	910	0.11
Test 5-在字符串比较中，进行100次SELECT操作	2185	910	2.40	2622	0.83
Test 6-创建索引	118.3	9	13.14	不适用	不适用
Test 7-在已经建立索引的情况下，进行5,000次SELECT操作	94.7	2	47.35	33.7	2.81
Test 8-在没有建立索引的情况下，进行1,000次UPDATE操作	178	156	1.14	319	0.56
Test 9-在没有建立索引的情况下，进行25,000次UPDATE操作	728	98.3	7.41	108	6.74
Test 10-在已经建立索引的情况下，进行25,000次文本UPDATE操作	634	54	11.74	37	17.14
Test 11-从一个SELECT进行INSERT操作	426	151	2.82	168	2.54
Test 12-在没有建立索引的情况下，进行DELETE操作	418	22.3	18.74	25	16.72
Test 13-在已经建立索引的情况下，进行DELETE操作	250	117	2.14	105	2.38
Test 14-在进行一次大量DELETE操作之后，进行一次大量INSERT操作	325	117	2.78	105	3.10
Test 15-在多次小量INSERT操作之后，进行一次大量DELETE操作	218	59.7	3.65	65.7	3.32
Test 16-DROP TABLE操作	940.7	267	3.52	不适用	不适用

 

 

eXtremeDB、SQLite和SpeedTest性能基准测试

 

SQLite和eXtremeDB具有一系列共同的特征。这两款DBMS都是“嵌入式解决方案”：它们能够与应用程序软件紧密集成，几乎不需要或者只需要用户进行很少的维护。二者均部署在应用程序进程中（即它们不含独立的客户端和服务器模块），都以出色的运行速度和对硬件资源的较低需求著称于世，而且它们都支持ACID（原子性、一致性、独立性和持久性）属性的事务。

但是，eXtremeDB完全作为内存数据库系统进行设计，而SQLite是一款传统DBMS。因此，SQLite需要通过OS文件系统将记录存储到磁盘上，但是它利用缓存子系统改善了磁盘存储的性能，缓存子系统可以将经常使用的数据保留在内存中。在SQLite问世后，它加入了一种内存表特性，支持将数据库表完全部署在RAM中（请参见）。

为进行对比这两款产品的测试，McObject采用了在SQLite网站上介绍的基准测试。请注意，虽然SQLite没有重点强调网页上给出的SpeedTest结果的相关性，但是这种测试方法确实密切相关。这是一种“单纯的”DBMS基准测试，衡量了多种代表性数据库任务的执行速度。McObject采用这两款数据库系统的最新版本（SQLite 3.7和eXtremeDB/eXtremeSQL 4.5）并且在最新的硬件（运行Red Hat Enterprise Linux的英特尔至强CPU E31245，3.30GHz）运行SpeedTest基准测试。

在另一个方面eXtremeDB与SQLite也存在着巨大的差异。正如它的名字暗示的，SQLite围绕SQL语言而构建，并采用C/C++应用程序编程接口（API），然而它还包括一些特定语言的“约束”，用于控制将SQL语句传递到数据库引擎中和接收结果。eXtremeDB既提供了SQL接口又提供了一种可直接访问且更快速的低级（本机）C/C++ API，可以使用这个本机API替代SQL或者作为SQL的补充。利用下面三种不同数据库/API组合，McObject的测试得到了上述结果：含有SQL C/C++ API的SQLite；使用SQL（称为eXtremeSQL）的eXtremeDB；以及使用本机C/C++ API的eXtremeDB。

 

 

基准测试结果——内存存储

 

在内存存储和持续性存储测试中（分别为表1和表2），标有“eXtremeDB”的列是使用eXtremeDB标准版和本机C/C++应用程序编程接口（API）的结果。标有“eXtremeSQL”的列是利用eXtremeDB可选的SQL API得到的结果。这两个表中的SQLite结果均使用SQLite的标准SQL实施方案获得。

在表1中（即使用本机API的eXtremeDB），只在没有建立索引的情况下进行SELECT和UPDATE语句操作时，SQLite的性能才优于eXtremeDB。这很可能是由于SQLite能够进行真正的表扫描，而eXtremeDB没有类似的概念。相反，eXtremeDB将系统生成的标识符整理为一种树形结构，进行遍历。因此，当SQLite逐行进行遍历时，eXtremeDB需要遍历树上的值，根据该标识符访问对象本身，然后返回到树，遍历下一个标识符，再根据它访问下一个对象，以此类推。在利用本机API的情况下，eXtremeDB API在16项测试中的14项实现了优于SQLite的性能，在六项测试中实现了比SQLite的速度快至少三倍的提升，而且在四项测试中实现了比SQLite响应速度快四倍的改善。

应该注意，通常很少使用表扫描。经过高度优化的数据库使用索引来避免采用这种蛮力形式的方法。常见的例外情况是当表极小时，或者当where条件中使用的列包含很少的值时。对于第一种情况，如果一个表只含有几十或几百行，采用索引不会实现任何效率提高，表扫描与在索引和表之间来回访问的速度相差无几，甚至会更快。但是，在这种情况下，SQLite和eXtremeDB之间“实际时间”的差异非常小，几乎无法测量。在第二种情况下（在where条件中使用的列包含很少的值），eXtremeDB支持“厚索引（thick index）”特性，在SQLite和其他大多数DBMS中都没有这种概念，可以使用它获得比表扫描更高的效率。

如果与SQL API配合使用，在内存存储测试中，eXtremeDB相对于SQLite的优势略微有所降低。在这种情况下，我们只进行了14项测试（在原来的16项测试中有两项与使用eXtremeDB的SQL API无关）。在这14项测试的八项，eXtremeDB实现了优于SQLite的性能，其中五项的性能比SQLite提高至少两倍。两项测试的结果不相上下，在四项测试中，SQLite实现了优于采用SQL的eXtremeDB方案的性能（其中三项可能是由于eXtremeDB缺少上面讨论的表扫描功能）。 

 

基准测试结果——持续性存储

 

由于从内存存储变为磁盘存储，因此表2所示的SQLite和eXtremeDB速度无一例外地都出现了下降。此外，表2还表明eXtremeDB相对于SQLite的优势进一步增大。使用本机API的eXtremeDB方案，SQLite只在一项测试中优于eXtremeDB，即“在没有建立索引的情况下，进行100次SELECT操作”。如上所述，这可能是由于SQLite能够执行表扫描。在使用本机API和持续性存储时，在16项测试中的10项，eXtremeDB实现了优于SQLite三倍的性能；并且在八项测试实现了超过SQLite四倍的性能。 

在eXtremeDB使用SQL接口的测试中，SQLite在14项测试中的三项实现了更出色的性能。然而，eXtremeDB使用SQL的方案在其余11项测试实现了优于SQLite的性能。在八项测试中eXtremeDB优于SQLite至少三倍，并且在六项测试中超过SQLite速度至少四倍。

 

结论——测试结果有何意义？

 

从上述测试结果，我们可以得出的第一个结论是使用内存存储进行数据管理比使用持续性存储快，而且不同数据库系统利用内存存储的效率不同。

表1中，eXtremeDB和SQLite对存储在内存中的记录进行排序、存储和检索。但是在内部，它们实现这些任务的方法不尽相同。SQLite是一款传统DBMS，通过操作系统的文件系统存储记录。即使利用内存表将底层文件存储在内存中，SQLite仍然是一种“走过场的”文件存储。F例如，缓存保持活跃状态以及强制处理需求等。这些步骤都需要占用时间和CPU周期。

相比之下，内存数据库系统不存在磁盘DBMS的这些缺点。所有数据存储在同一个位置（主内存中），省去了缓存或数据传输的开销。在摆脱这些负担后，即便磁盘DBMS（例如SQLite）将表存储在RAM中，IMDS（例如eXtremeDB）也能够实现比SQLite快的运行速度。在表1的测试结果中，eXtremeDB在所有16项测试的14项实现了优于SQLite的性能，其中七项测试的响应时间只有SQLite的一半，证明了数据库系统是否完全作为IMDS设计的重要性。

而数据库系统设计初衷的重要性同样影响着使用持续性存储进行的测试。当开发人员创建内存数据库时，不必考虑磁盘和文件I/O使数据库系统设计者可以专注于提高DBMS的效率，也就是对CPU周期和内存的需求。由于侧重点不同，导致的一个关键架构区别是，eXtremeDB放弃使用C/C++标准库，而使用更高效的常用库函数。

如果IMDS提供商后来决定要加入持续性存储，这一功能构建在原本已经高效使用CPU和内存的数据库系统引擎上。相反，当磁盘DBMS设计者要添加一个特性来替代内存进行磁盘存储时，他们无法“释放”产品中为了实现最大限度地降低I/O这个基本的设计目标而消耗的CPU周期或内存。这种设计起源的差异解释了eXtremeDB在使用持续性存储时优于SQLite的原因。事实上，与内存测试相比，在这些测试中，eXtremeDB相对于SQLite的性能优势更加明显，更加表明高效的底层DBMS的重要性。

事实上，IMDS在使用持续性存储时能够实现这样出色的性能丝毫不会降低其“内存性”的重要性。这只是以另一种形式指出了内存存储能够加快这种数据库系统新类型的潜在假设。但是，这种优势取决于DBMS是否是真正的IMDS（即完全作为IMDS进行设计）。内存数据库系统确实在多种解决方案中实现了显著的性能提升，为了获得这种优势，潜在用户需要认真考虑可用的方案，并且不要轻信厂商的承诺。