Commit ac9ab1a4 authored by 张振华's avatar 张振华

add fies

parent 2c929f44
# 一、MavlDB与KVMVCC DB #
# 一、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的接口性能测试数据对比 #
##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倍。
##4.说明
上述数据主要在办公用机上安装了Ubuntu虚拟机(双核2G内存)来进行测试,不能测试系统极限性能,但从时延指标来对比看两种方案的性能差别。
目前仅测试了几万个区块的数据,随着区块数量的增加,可以推论两者的性能差别会越来越大。
附:测试用虚拟机信息
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
\ No newline at end of file
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment