基于内存的NoSQL分布式数据库技术研究项目选型与测评分析

基于内存的NoSQL分布式数据库技术研究项目选型与测评分析基于内存的NoSQL分布式数据库技术研究项目选型与测评分析中科大移动云计算系统实验室孟宁

项目目标 • 本项目需要研究一种新的快速存储与访问机制，改善内存使用的现状，同时要保证软件架构上不做大的改动，性能没有明显下降。 • 具体到本阶段的目标 • 在保留当前函数调用的基础上，用NoSQL数据库替换现有SQL数据库 • 普通数据库改造成NoSQL数据库需要有15倍[ 如果该指标无法达到，必须通过理论分析给出指标无法达到的原因；]的效率提升

数据库调研

数据库选型 • SQLite作为基准数据库 • Tokyo Cabinet/Tokyo Tyrant • Hash Database - O(1) time complexity • fixed-length Database（array of fixed-length elements） - O(1) time complexity • Client/Server mode • Hamsterdb • Hamsterdb相比性能远远超过BerkeleyDB • Redis • Redis是相比同为C/S架构的Memcachedb性能更好

测试用例设计 • 读性能测试 • 随机读表(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资源占有测试

测试数据库的规模 • 要求：数据库的规模是1000张表，每个表最大20000个记录，每条记录最大1000个字节，每个表的关键字小于10个，但整个数据库的大小却只有50M左右。 • 因此，按照当前华为应用中控制器数据量为50MB左右的量级来进行设计，以一个较大的上界－200MB左右来初始化数据库。共100张表，每表5000行，每行依旧保持400字节规模。较小的数据规模有利于更加准确的测试在当前场景（非极端场景）下哪种数据库更适合。

测试系统所在的软硬件环境 • 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）

测试流程

主要测试软件架构设计

基准数据库SQLite的优化 • SQLite的查询性能在1w/s左右，通过优化之后查询性能达25w/s左右。 • 具体优化措施： • 取消持久化。在运行SQLite时，指定在内存中创建数据库 • 简单及常用的读、写、更新SQL语句在创建表时就预先构造和编译，优化掉了SQL语句的处理和编译时间

基本测试结果对比

随机读性能的测试对比 • 结果显示tc性能要比优化后的SQLite快10倍多，其中tcf(Array)略快于tc(Hash) • C/S模式的读性能仅有优化后的SQLite的1/6左右，但对于我们下一步做分布式是个参考

顺序读的性能对比

随机写（更新）性能对比

顺序写（更新）性能对比

反复查找同一条记录的性能对比

反复更新同一条记录的性能对比

不同读写比例的性能数据对比

内存资源占有率对比

结论及下一阶段建议 • 结论： • Tokyo Cabinet的性能最优完全达到我们的要求 • 由于我们的应用场景与一般分布式存储的应用场景在架构上有很大不同、读性能要求又特别高、单节点上读取的数据集比较集中等特点，目前没有发现适用于我们的应用场景的分布式方案，但分布式的思想可以借鉴。 • 下一步工作的建议： • 1、适合以TC为基础来实现共享内存方式的改造 • 2、以TC为存储引擎独立设计分布式解决方案

感谢各位 孟宁中科大移动云计算系统实验室 mengning@ustc.edu.cn

基于内存的NoSQL分布式数据库技术研究项目选型与测评分析