# 一、MavlDB与KVMVCC DB #

目前Chain33支持两种Store类型Mavl DB与KVMVCC DB，对应不同的系统配置：  
[store]  
name="mavl"  
driver="leveldb"  
dbPath="datadir/kvdb"  
dbCache=128


[store]  
name="kvmvcc"  
driver="leveldb"  
dbPath="datadir/kvdb"  
dbCache=128 

关于两者的区别，详细请参见：  
[Store新增支持MVCC的KVDB实现.md](https://gitlab.33.cn/richardzhang/share/blob/master/Store新增支持MVCC的KVDB实现.md)

简单来说，Mavl DB以树形结构来组织StateDB中的数据，通过StateHash来索引，对于数据状态变化的维护比较方便，缺点是随着数据量增加，效率不断下降，另外查找效率慢，不能通过主键直接查找。而KVMVCC DB则通过数据版本控制，对数据存储时主键增加版本信息，可以实现数据的平铺存储，根据主键及版本快速查找数据，并且处理性能不随数据量增加而明显下降。

当然，KVMVCC DB相比mavl也存在自己的不足，就是在对特定高度的数据进行统计分析时，KVMVCC DB需要遍历数据库，该场景中存在比较严重的性能问题。  

没有完美的方案，两者分别适用于不同的场景，根据需求进行取舍。

# 二、MavlDB与KVMVCC DB的接口性能测试数据对比 #


##  说明  


<font color=#FF0000>下面的性能测试数据主要在办公用机上安装了Ubuntu虚拟机（双核2G内存）来进行测试，不能测试系统极限性能，仅从时延指标来对比看两种方案的性能差别对比。 </font>  


##  1.如下通过BenchMark测试用例，对几个主要接口进行了性能测试及数据记录  


![MavlDB与KVMVCC DB的接口性能数据](./resource/mavl-kvmvcc-perf-data.png)  

从上述测试数据可以看出，在上述几个接口的适用场景中，KVMVCC DB的响应时延占优，从而整体性能会占优，但具体对整体的性能影响如何要放到系统全局来看，来测试。  

# 三、MavlDB与KVMVCC DB的系统性能测试数据对比 #  

##  1.测试场景  


分别配置chain的Store类型分别为mavl及kvmvcc，测试区块从零高度开始，进行性能呼叫，促使区块高度不断增长，并进行数据查询，统计查询时延。  

##  2.测试数据  


![KVMVCCDB性能数据](./resource/kvmvcc-perf-data.jpg)  
afa  

![MavlDB性能数据](./resource/mavl-perf-data.jpg)  


##  3.测试结论  


从上述两组数据对比来看：  
（a）kvmvcc随着区块高度增加保持在写数据的同时，读取数据时延相对稳定。  
（b）mavl读数据时延随区块高度增加、数据增多而逐步增大，且绝对时间比kvmvcc相同高度时要长许多。  
（c）mavl的读数据响应时延大概是kvmvcc的5到8倍。  

##  说明  


<font color=#FF0000>上述性能测试数据不是系统极限数据，仅从随着区块高度增加、数据量增加查询时延指标的变化来对比看两种方案的性能差别。  
目前仅测试了增长到几万个区块时的查询时延数据，可以推论：随着区块数量的增加，两种方案的查询性能差别会逐渐拉大。</font>


附：测试用虚拟机信息  
zzh@zzh-VirtualBox:~/go/src/gitlab.33.cn/chain33/chain33/system/store/mavl$ lsb_release -a  
No LSB modules are available.  
Distributor ID:	Ubuntu  
Description:	Ubuntu 17.10  
Release:	17.10  
Codename:	artful  


zzh@zzh-VirtualBox:~/go/src/gitlab.33.cn/chain33/chain33/system/store/mavl$ cat /proc/cpuinfo  
processor	: 0  
vendor_id	: GenuineIntel  
cpu family	: 6  
model		: 158  
model name	: Intel(R) Core(TM) i5-8400 CPU @ 2.80GHz  
stepping	: 10  
cpu MHz		: 2808.002  
cache size	: 9216 KB  
physical id	: 0  
siblings	: 2  
core id		: 0  
cpu cores	: 2  
apicid		: 0  
initial apicid	: 0  
fpu		: yes  
fpu_exception	: yes  
cpuid level	: 22  
wp		: yes  
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti retpoline rsb_ctxsw fsgsbase avx2 invpcid rdseed clflushopt  
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass  
bogomips	: 5616.00  
clflush size	: 64  
cache_alignment	: 64  
address sizes	: 39 bits physical, 48 bits virtual  
power management:  

processor	: 1  
vendor_id	: GenuineIntel  
cpu family	: 6  
model		: 158  
model name	: Intel(R) Core(TM) i5-8400 CPU @ 2.80GHz  
stepping	: 10  
cpu MHz		: 2808.002  
cache size	: 9216 KB  
physical id	: 0  
siblings	: 2  
core id		: 1  
cpu cores	: 2  
apicid		: 1  
initial apicid	: 1  
fpu		: yes  
fpu_exception	: yes  
cpuid level	: 22  
wp		: yes  
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti retpoline rsb_ctxsw fsgsbase avx2 invpcid rdseed clflushopt  
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass  
bogomips	: 5616.00  
clflush size	: 64  
cache_alignment	: 64  
address sizes	: 39 bits physical, 48 bits virtual  
power management:  


zzh@zzh-VirtualBox:~/go/src/gitlab.33.cn/chain33/chain33/system/store/mavl$ free  
              total        used        free      shared  buff/cache   available  
Mem:        2041392      647432      312708       20268     1081252     1212104  
Swap:       2097148       22284     2074864  