五、对测试结果的综合比较和分析.DOCVIP

基于内存的NoSQL分布式数据库技术研究项目 Version?: 1.0.0 2012-10-23 By 中科大移动云计算系统实验室 DOCUMENT HISTORY Ed. Version Author Change 1 0.9.0 吴昊 Initial 2 1.0.0 孟宁 增加了些分析，并完善了整个文档 孟宁 电话:0512E-mail:mengning@ustc.edu.cn 目录 目录 2 一、实验环境及预定目标 4 1.1 实验环境 4 1.2 预定目标 4 二、共享内存方式 4 2.1 实现方案 4 2.2 测试结果及统计分析 5 2.3 和运行单独一个进程的测试结果比较 9 2.4 结论 10 三、板内分布式 10 3.1 实现方案 10 3.2 测试结果及统计分析 11 3.3 结论 12 四、缓存方式 12 4.1 实现方案 12 4.2 测试结果及统计分析 13 4.3 结论 14 五、对测试结果的综合比较和分析 14 六、结论及下一步板间分布式方案 15 一、实验环境及预定目标 1.1 实验环境 系统测试运行在X86平台上，具体配置如下： Linux单机，CPU是一块2核X86芯片，每个核有两个超线程。Fedora13，x86_64， GCC 4.45。6G内存。 1.2 预定目标 板内数据库改造，方法不限于共享内存和分布式，在改造的基础上，保证系统性能下降2%以内。 保持函数访问接口不变 性能下降在2%以内 要考虑数据一致性，写数据生效时间小于1ms，（读写关系类似于CPU CACHE读写关系） 要评估出进程同时访问数据库时对数据库性能的影响及影响因素（如计算能力、内存带宽等）, 并给出部分分布和全部分布方案的理论分析和实现方案。 分布式算法要考虑数据备份和数据恢复 分布式算法要考虑数据均衡 分布式算法中，节点的增加和减少要考虑数据不丢失 二、共享内存方式 2.1 实现方案 采用mmap方式实现共享内存方案，将板内所有进程通过mmap方式共享同一个数据库，每个单板的进程数目达到32个；主要进行了基本读写性能测试。 mmap方式实现共享内存方案的方法为： 初始化数据库，插入所需的测试数据，把数据库内存映像保存为文件； 测试进程将数据库文件使用mmap方式映射到本进程地址空间； 利用shell脚本分别同时执行1个、2个、4个、6个、8个、10个、12个、14个、16个和32个进程，在执行时还使用了taskset -c将进程与CPU绑定。 2.2 测试结果及统计分析 分别测试了以下项目：顺序插入、随机读、顺序读、级联查找、随机修改、顺序修改、查找同一条记录（重复多次）、修改同一条记录（重复多次），实验结果数据统计表格见：Nosql分布式存储第二阶段共享内存测试数据整理.xls 随机读50万次的测试结果及分析 图1是板内共享内存随机读测试(a)横坐标即为1个、2个、4个、6个、8个、10个、12个、14个、16个和32个进程，纵坐标即为各进程所测得的随机读50万次测试所耗时间，单位为秒。 由图1可以看出，在不同CPU上运行不同数量的相同测试进程，随机读测试所耗时间大致相同，在某一时间轴附近波动。其中同时运行1个、2个、4个进程时，各进程随机读测试所耗时间基本相同，大致在0.2秒左右，显然这与测试机器拥有2个CPU 4个核的硬件环境相符。当同时执行6个进程时所耗时间却跳跃到0.6秒左右，之后依次增加2个进程（即每CPU增加一个进程）所耗时间有规律地依次增加0.2秒左右。 图1 板内共享内存随机读测试(a) 因此，基本可以断定当每个进程独占一个核的时候所耗时间为0.2秒左右，当多个进程共享一个核的时候，除了0.2秒*进程数外，还需要有大约0.2秒的进程调度开销。图2是板内共享内存随机读测试(b)，由图中的随机读测试所得各组进程的平均运行时间曲线，可以更加清晰的呈现上述结论。 图2 板内共享内存随机读测试(b) 2）随机修改50万次测试结果及分析 图3图4为随机修改测试结果统计，大致呈现了与随机读相同的曲线形状，只是随机修改所耗时间明显高于随机读，大约是随机读的2倍多，达到平均0.45秒左右。 图3 板内共享内存随机修改测试(a) 图4 板内共享内存随机修改测试(b) 3）顺序读5000条测试结果及分析 图5是顺序读测试的结果，具体表现为不管同时运行的进程数如何增加，大部分进程都在极短的时间内（大约0.001秒）完成了测试，而从6进程开始每组进程中总有少数进程耗费较多时间，如图5呈现为跳跃性，而且随着每组进程数目的增大跳跃的幅度也在不断增大。 图5 板内共享内存顺序读测试(a) 图6是板内共享内存顺序读测试(b)，从各组进