基于内存的nosql分布式数据库技术研究项目 选型与测评分析
DESCRIPTION
基于内存的NoSQL分布式数据库技术研究项目 选型与测评分析. 中科大移动云计算系统实验室 孟宁. 项目目标. 本项目需要研究一种新的快速存储与访问机制，改善内存使用的现状，同时要保证软件架构上不做大的改动，性能没有明显下降。 具体到本阶段的目标 在保留当前函数调用的基础上，用NoSQL数据库替换现有SQL数据库 普通数据库改造成NoSQL数据库需要有15倍[ 如果该指标无法达到，必须通过理论分析给出指标无法达到的原因；]的效率提升. 数据库调研. 数据库选型. SQLite作为基准数据库 Tokyo Cabinet/Tokyo Tyrant - PowerPoint PPT PresentationTRANSCRIPT
LOGO
基于内存的 NoSQL 分布式数据库技术研究项目
选型与测评分析中科大移动云计算系统实验室
孟宁
LOGO
Page 2
项目目标
本项目需要研究一种新的快速存储与访问机制，改善内存使用的现状，同时要保证软件架构上不做大的改动，性能没有明显下降。
具体到本阶段的目标 在保留当前函数调用的基础上，用 NoSQL 数据库替换现有 SQ
L 数据库 普通数据库改造成 NoSQL 数据库需要有 15 倍 [ 如果该指标无
法达到，必须通过理论分析给出指标无法达到的原因； ] 的效率提升
LOGO
Page 3
数据库调研
LOGO
Page 4
数据库选型
SQLite 作为基准数据库 Tokyo Cabinet/Tokyo Tyrant
Hash Database - O(1) time complexity fixed-length Database （ array of fixed-lengt
h elements ） - O(1) time complexity Client/Server mode
Hamsterdb Hamsterdb 相比性能远远超过 BerkeleyDB
Redis Redis 是相比同为 C/S 架构的 Memcachedb 性能更好
LOGO
Page 5
测试用例设计
读性能测试 随机读表 (table_id) 中某一行 (row_id) 的性能 重复读表 (table_id) 中某一行 (row_id) 的性能 顺序读取表 k 中若干行 (row_range) 的性能 级联查找的效率（ Level 3,Factor 10）
写性能测试 随机写（更新）表 (table_id) 中某一行 (row_id) 的性能 重复写（更新）表 (table_id) 中某一行 (row_id) 的性能 顺序写 ( 更新 ) 表 k 中若干行 (row_range) 的性能
不同读写比例的性能测试 读写混合性能测试（从 100 万 :1 到 1:1 的读写）
资源占有测试 内存资源占有测试 CPU 资源占有测试
LOGO
Page 6
测试数据库的规模
要求：数据库的规模是 1000 张表，每个表最大 20000 个记录，每条记录最大 1000 个字节，每个表的关键字小于10 个，但整个数据库的大小却只有 50M 左右。
因此，按照当前华为应用中控制器数据量为 50MB 左右的量级来进行设计，以一个较大的上界－ 200MB 左右来初始化数据库。共 100 张表，每表 5000 行，每行依旧保持400 字节规模。较小的数据规模有利于更加准确的测试在当前场景（非极端场景）下哪种数据库更适合。
LOGO
Page 7
测试系统所在的软硬件环境
Linux 单机， CPU是一块 2核 X86芯片，每个核有两个超线程。 Fedora13， x86_64， GCC 4.45。 6G内存。
SQLite(version 3.7.13) Tokyo Cabinet (version 1.4.27) / Tokyo Tyrant
(version 1.1.41) Hamsterdb Embedded Storage (version 2.0.3) Redis （ redis-v2.4.13 、 antirez-hiredis-v0.10.
1-30）
LOGO
Page 8
测试流程TokyoCabinet(tc&tcf) Testing
HamsterDB Testing
TokyoTyrant C/S Testing
Redis C/S Testing
SQLi teDB Testing
pick up the resul t data*.time as inputgenerate photo*.png as output
backup *.time *.data *.pnggenerate test-data-`date
+%y_%m_%d̀ .tar.gz
Databases Memory Testing
source build.env
make clean
make
make test
LOGO
Page 9
主要测试软件架构设计
LOGO
Page 10
基准数据库 SQLite 的优化
SQLite 的查询性能在 1w/s 左右，通过优化之后查询性能达 25w/s 左右。
具体优化措施： 取消持久化。在运行 SQLite 时，指定在内存中创建数据库
简单及常用的读、写、更新 SQL语句在创建表时就预先构造和编译，优化掉了 SQL语句的处理和编译时间
LOGO
Page 11
基本测试结果对比
LOGO
Page 12
随机读性能的测试对比
1.结果显示 tc 性能要比优化后的 SQLite 快 10 倍多，其中 tcf(Array)略快于 tc(Hash)2.C/S 模式的读性能仅有优化后的 SQLite 的 1/6 左右，但对于我们下一步做分布式是个参考
LOGO
Page 13
顺序读的性能对比
LOGO
Page 14
随机写（更新）性能对比
LOGO
Page 15
顺序写（更新）性能对比
LOGO
Page 16
反复查找同一条记录的性能对比
LOGO
Page 17
反复更新同一条记录的性能对比
LOGO
Page 18
不同读写比例的性能数据对比
LOGO
Page 19
内存资源占有率对比
LOGO
Page 20
结论及下一阶段建议
结论： Tokyo Cabinet 的性能最优完全达到我们的要求 由于我们的应用场景与一般分布式存储的应用场景在架构上有很大不
同、读性能要求又特别高、单节点上读取的数据集比较集中等特点，目前没有发现适用于我们的应用场景的分布式方案，但分布式的思想可以借鉴。
下一步工作的建议： 1、适合以 TC 为基础来实现共享内存方式的改造 2、以 TC 为存储引擎独立设计分布式解决方案
