高性能key-value数据库nessDB介绍

标签: 未分类 bloom-filter LSM-Tree nessDB | 发表时间:2012-04-02 19:13 | 作者:nosqlfan
出处:http://blog.nosqlfan.com

nessDB是一个小巧、高性能、可嵌入式的key/value存储引擎,使用标准C开发,支持Linux, *BSD, OS X and Solaris等系统,无第三方库依赖。本文来自nessDB作者@ BohuTANG 的投稿分享,推荐给大家。

同时nessDB还提供一个服务端,支持Redis的 PING, SET, MSET, GET, MGET, DEL, EXISTS, INFO, SHUTDOWN 命令,您可以使用任何一款Redis客户端来连接和操作nessDB。

整个引擎基于 LSM-Tree思想开发,对随机写非常友好。为提高随机读,nessDB使用了Level LRU和Bloom Filter策略。

nessDB结构介绍

主要包括:Memory-Table,Sorted-Table(*.sst)、Meta和Log四大部分。

1. Memory-Table 是个有序内存表,使用Skiplist实现。

所有的添加/删除首先会写到这个内存表,当这个内存表达到一定数量后,进入immutable只读状态,后台线程开始对其进行merge操作。同时会新建一个内存表,继续接受添加/删除操作。

Memory-Table数据结构如下:

key value-offset operation
  • ‘key’:key数据
  • ‘value-offset’:value在DB文件里的偏移地址
  • ‘operation’:标识,是添加还是删除操作

由于不存储value,可以对更多的数据进行缓存和排序,对随机写更友好(这点与levelDB不同)。

nessDB同时最多有2个Memory-Table,一个处于可读写的active状态,另一个处于只读的immutable状态。

2. Sorted-Table key有序存储的索引文件(*.sst)。每个sst索引文件默认存储25000条记录,任何两个sst索引文件没有区间重叠(也没有level之分,这点与levelDB不同)。

一个sst索引文件结构如下:

key1 value1-offset(big-endian)
key2 value2-offset(big-endian)
… more key and value offset …
keyN valueN-offset(big-endian)
last-key count crc

最后一行是个FOOTER结构,存储着当前索引文件最大的key(即last key),当前索引文件拥有的记录数目(count)和一个crc值。

3. Meta 索引Meta信息表

nessDB每次启动的时候,读取所有sst索引文件的FOOTER信息,组成一个内存索引meta信息表,结构如下:

begin key end key sst file name sequential number
… all the other items …

此meta信息表的作用是可根据key二分查找出所在的sst索引文件。

4. Log

log是Memory-Table在磁盘上的一个镜像,如果因为某种原因crash,下次重启时,nessDB会自动检测并进行数据恢复。

性能

这有个不太专业的性能测试报告: https://gist.github.com/2235147

该测试基于: Linux 3.0.0内核,Ext4文件系统,CFQ调度器。

如果您有兴趣,可以下载 源码:

./make db-bench
./db-bench write <count>

进行性能测试,不同机器结果会有差别。

关于nessDB

nessDB是一个开源项目,目前已有十多位代码贡献者,希望更多的人参与进来。

源码地址: https://github.com/shuttler/nessDB

最后

希望使用B树开发自己NoSql产品的朋友,可以尝试下LSM-Tree,它思想朴素、简单,性能好。

相关文章:
新的Key-Value存储Memlink介绍
NoSQL 中的 CAP 原理
基于SSD的数据库性能优化
HBase随机读写性能测试
图数据库综述
无觅

相关 [性能 key value] 推荐:

高性能key-value数据库nessDB介绍

- - NoSQLFan
nessDB是一个小巧、高性能、可嵌入式的key/value存储引擎,使用标准C开发,支持Linux, *BSD, OS X and Solaris等系统,无第三方库依赖. 本文来自nessDB作者@ BohuTANG 的投稿分享,推荐给大家. 同时nessDB还提供一个服务端,支持Redis的 PING, SET, MSET, GET, MGET, DEL, EXISTS, INFO, SHUTDOWN 命令,您可以使用任何一款Redis客户端来连接和操作nessDB.

[转][转]高性能key-value数据库nessDB介绍

- - heiyeluren的Blog
来源:http://blog.nosqlfan.com/html/3851.html . nessDB是一个小巧、高性能、可嵌入式的key/value存储引擎,使用标准C开发,支持Linux, *BSD, OS X and Solaris等系统,无第三方库依赖. 本文来自nessDB作者@ BohuTANG 的投稿分享,推荐给大家.

Tair: 淘宝的key/value解决方案

- duxin - 若海的blog
今天我们对外开源了Tair,Tair是由淘宝开发的key/value解决方案,你可以在这里获取更多信息. Tair在淘宝有着大规模的应用,在你登录淘宝、查看商品详情页面、在淘江湖和好友“捣浆糊”等等时候,后面都在直接或间接的和Tair交互. Tair是一个分布式的key/value结构数据的解决方案,系统默认支持基于内存和文件的存储引擎,对应于通常我们所说的缓存和持久化存储.

400行代码实现本地Key-Value缓存,性能每秒几百万次,进程重启有效,LRU淘汰——HashTable

- - CSDN博客数据库推荐文章
[email protected]原创,转载请注明出处: http://blog.csdn.net/gdutliuyun827. Key-Value缓存有很多,用的较多的是memcache、redis,他们都是以独立服务的形式运行,在工作中有时需要嵌入一个本地的key-value缓存,当然已经有LevelDb等,但感觉还是太重量级了.

使用key/value数据库redis和TTSERVER的体会

- - 开源软件 - ITeye博客
redis是一个类似memcached的key/value存储系统,它支持存储的value类型相对较多,包括string(字符串)、 list(链表)、set(集合)和zset(有序集合). 在此基础上,redis支持各种不同方式的排序. 与memcached一样,为了保证效率,数据都是缓存在内存中.

镀金键盘帽:Gold Key

- Paul - 爱…稀奇~{新鲜:科技:创意:有趣}
传统上而言,判断一个人是不是暴发户,最主要不是看小三的数量,也不是看有没有玛莎拉蒂,最重要的是——看他有没有一颗金牙. 这在改革刚开放那会,一颗金灿灿的门牙,简直就是“老子很有钱”的代名词,可比名片管用多了~. 所以,从这个角度而言,如果你怀念着那个光辉的时代,并想给自己来点后现代的色彩,那么,一颗镀金键盘帽(Gold Key)就是必须的了~4美元一颗,这里有售:chihapaura.com,用来替换自己键盘上的数字“4”,那“仇恨”吸得,我kao,即便是美美也不过如是啊.

mysql中的ON DUPLICATE KEY UPDATE

- - haohtml's blog
INSERT INTO ON DUPLICATE KEY UPDATE 与 REPLACE INTO,两个命令可以处理重复键值问题,在实际上它之间有什么区别呢. 前提条件是这个表必须有一个唯一索引或主键. 1、REPLACE发现重复的先删除再插入,如果记录有多个字段,在插入的时候如果有的字段没有赋值,那么新插入的记录这些字段为空.

给钥匙加上套子:Key Keeper

- Chuyue - 爱…稀奇~{新鲜:科技:创意:有趣}
来自日本设计师青木亮作(Ryosaku Aoki)的创意,Key Keeper是给钥匙用的硅胶TT——能干嘛呢. 在平时,它可以一定程度地将钥匙的棱角包裹起来(兼具防尘的作用),避免运动或者玩闹时不小心戳到自己,或者划伤手机外壳,同时多样的色彩又会是漂亮的分类标签,一种颜色对应一种钥匙~并且丝毫不会影响到钥匙本来的功能,开门的时候握住一头,仍然能轻松地插进钥匙孔,这时,Key Keeper会缩回,等抽出钥匙的时候它又能自动弹回.

Cloud Key,躲在 U 盘里的云

- SotongDJ - 爱范儿 · Beats of Bits
看看 Goolge 建立了多少个数据中心. 搭建云服务,需要要众多的服务器吧. 然而位于旧金山的 Piston 推出新产品 Cloud Key,把云服务装进了 U 盘. 那么,Cloud Key 能否像 U 盘那样方便易用呢. 根据公司描述,当 Cloud Key 插进交换机后,只需要短短几分钟,用户就能够完成云计算平台 OpenStack 的设置.

用 InnoDB 時關於 PRIMARY KEY 的建議

- - Gea-Suan Lin's BLOG
Percona 的「 InnoDB scalability issues due to tables without primary keys」這篇文章在討論 InnoDB 在沒有 PRIMARY KEY 時的效能問題. 在討論效能問題前,應該先讀過 MySQL 官方文件裡提到 InnoDB index 架構的文章,其中就有提到 PRIMARY KEY 以及其他的 INDEX KEY 的底層架構:「 InnoDB Table and Index Structures」.