memlink浅析


123 Product Report 产品报道Products 产品 非关系型数据库memlink浅析 文 / 冯勇 赵威 NoSQL系统种类繁多,从数据模型角度划 分,有KV类型、文档类型、对象类型 等;从存储方式角度划分,有行存储和列存储 等。但有一种类型,业界很少提及,它就是 Key→List类型,即Key指向的Value是List类型。 这种类型很少提及,一方面是可被KV类型代 替,比如,将List打包放入Value中;另一方面是 大多数场景中采用SQL系统来存储List关系。 然而,还有一些特殊需求,上述方案不能 满足,比如:海量论坛和海量微博服务。它们 对List有下面两个独特的需求: List是海量的。比如,百度贴吧的“李宇春 吧”有超过2800万主题帖,李开复的新浪微博 有超过400万粉丝数。这意味着为相应的数据模 型,主题List有超过2800万元素、粉丝List有超 过400万元素。 List中元素有动态排序需求。比如,贴吧的 主题帖列表按最后回复时间排序,微博中的个 人首页按微博发表时间排序。 如果再加上性能需求,使用传统的KV/SQL 系统就很难解决了。稍有经验的开发者知道, 使用KV系统的Value存储List,光打包解包就要 花费很长时间,更不用说排序功能,SQL系统 里上千万的数据order by也是非常缓慢的。 因此memlink应运而生!这是一款由天涯 社区赞助的开源Key→List数据引擎,被应用于 天涯来吧、天涯微博等产品。类似的产品还有 Redis。而没有选择Redis,有以下几点原因: Redis数据持久化不够完善; 主从同步有缺陷,从服务器重启后,数 据需要完全重新同步; 读操作为单线程,无法发挥多核CPU的处 理能力; 内存消耗过大。 介绍 如名称中的mem所示,memlink所有数据 都建构在内存中,保证了系统的高性能(读性 能大约是Redis几倍到十倍),同时采用块技术 压缩内存,内存消耗比Redis小得多;持久化方 面,使用redo-log技术;分布式方面,支持一 主多从复制;此外还增加了数据过滤、读写分 离、多核计算等工业级需求。 memlink支持三种List类型,其中,List中 数据项顺序在插入时由参数指定;有序List的顺 序按照数据项的值自动排序决定;Queue就是双 向队列。 memlink客户端支持C、PHP、Python、 Java等语言。核心的API详见http://code.google. com/p/memlink/wiki/ClientAPI。 设计原理 主框架 m e m l i n k采 用 异 步I/O网 络 模 型 ( 基 于 libevent),由连接线程来管理大量并发连接, 多线程处理实际命令。比起Redis单线程模型, memlink能很好利用服务器的多核特性。另外, 因读写线程分离和多读一写模式,写线程拥有 独立的端口和处理流程,即使在高并发的读请 求下,写请求也能优先完成,符合大多数场景 多读少写、写优先的特性。 核心数据结构 与Redis相似,memlink的核心数据结构就 124 Product Report 产品报道Products 产品 是HashTable。但出于内存和性能的考虑,存储 List上,memlink采用的是块链(Block),每N 个结点构成块,块与块之间采用指针相连。这 样处理的好处如下: 节省内存空间的使用。Block才有头指针和 尾指针,不需要每个node都有。 遍历按块跳跃,提高查找效率。块链的大 小是memlink的配置项,比如,在论坛中每页主 题贴数量是50,则N可配置成50。memlink内部 并不是所有的Block大小都是N,而是动态变化 的。考虑这样的场景:我们有100万个Key,每 个Key下的List只有1~2个数据项。这时如果分 配的是N,内存浪费会非常严重。所以这里采 用的是类似STL Vector动态增长的方法,动态增 长到N,避免存在大量List的长度小于N时,造 成空间浪费。 memlink中的node大小由API指定,建议只 存放id类型数据。每个节点还可附带一些简单 的数字属性值。 为了提高并发性,memlink尽量不用锁。因 为Block由内存池预分配,添加、修改node并不 会造成内存非法访问,仅有可能某次读请求取 到的是脏数据,但下次访问就是正确的数据。 读操作远远大于写操作的情况下,读到脏数据 的概率是很小的。未来如果有强一致性的需 求,memlinke可以提供读写锁。 数据持久化 Redis持久化两种方式:第一、定时同步内 存到文件系统中,这种方式不保证在两次同步 操作期间的数据的完整性;第二、将所有写操作 命令记录到redo-log,重启时回放Log,这种方式 由于Log大小不断增加,回放时间会越来越长。 memlink同时借鉴了Redis这两种方式的优点,定 期同步内存,在本次同步内存和下次之间采用 redo-log保证数据的完整性。如果此期间memlink 重启,会首先加载内存镜像,然后重放redo- log,这样就恢复到系统上次退出时的状态。 主从复制 memlink支持基于redo-log的一主多从的数 据同步方式。从服务器会自动连接主服务器, 并且发送同步的日志位置,主服务器将接着这 个日志位置主动向从推送日志。这非常类似 MySQL主从复制。 性能对比 下面我们对memlink、Redis、MySQL进行 简单性能测试对比,只针对insert和range。测 试都是单机提供服务,且客户端在本机进行测 试,并发50个短连接。测试一个Key下有1000 万Value的情况(Key为5字节,Value为10字 节),在0、1万、10万、100万、1000万的位 置分别取100个Value。版本分别为Redis-2.2.2、 MySQL-5.1.53,都使用默认配置。 硬件环境如下: OS:CentOS release 5.4 (final) Kernel:2.6.18-164.el5 x86_64 Memory:8G Disk:2T SATA CPU:Intel Xeon E5405 2.0Gx2(4核x2) 数据模型如下: 其中,MySQL的数据表为: CREATE TABLE TestList ( listkey` char(5) not null, `listvalue` char(10) not null, `change_time` int unsigned not null, 图2 memlink同步 图1 memlink框架 125 Product Report 产品报道Products 产品 key `testlist` (`listkey`, ‘change_ time`) )ENGINE=InnoDB DEFAULT CHARSET=utf8; MySQL查询语句为select listvalue from TestList where listkey=’$key’ order by change_time limit $start,$len Redis命令为LRANGE $key $start $end memlink命令为RANGE $key $start $len 使用场景 假设某款微博,日均发微博数2500万,活 跃用户500万。下面是基于memlink的解决方 案,供大家参考。核心的数据模型如下: 微博主要的提交操作有添加关注、删除 关注、发布微博。主要浏览操作有查看我的首 页、我(他人)的微博、我(他人)的关注列 表、我(他人)的粉丝列表。 本系统采用推模式将feed推送到所有粉 丝,在大型微博产品中会采用推拉相结合的模 式。下面单机环境下的性能测试结果:(硬件 环境和之前的测试一样),这里Key-Value系统 使用的memcachedb。结果如表2所示(实现伪 代码请参见《程序员》官网)。 memlink的特性限制 memlink是全内存存储,系统容量上限取决 于系统的内存大小,因此正确的用法是只存储 需要排序的ID数据。(Redis支持VM,即交换 到文件中存储)。 因所有数据都存储在内存中,memlink对 内存消耗比较大。List中的每个Value项是定长 的,必须要占用固定大小的空间。每个Block也 必须占用固定的node数。memlink中以value值作 为条件来进行的操作(如delete、tag、mask、 delete_by_mask),是逐个顺序查找的,因此这 些操作性能上不会特别好。 未来的发展 memlink定位于高性能、持久化、分布式的 Key→List数据引擎,并非存储模型的万能解决 方案,没有计划去支持KV/Doc等其他类型。后 面会加强对后面会加强对memlink管理、监控、 统计、更好的分布式等方面的支持,可能增加 新的List类型,以及非热点数据存储到磁盘等 新特性。memlink将在天涯社区的一些产品中使 用,成为天涯云计算的基础模块之一。 我关注的人(关注列表) key-list 上限2000 关注我的人(粉丝列表) key-list 无限制 我的微博(feed列表) key-list 无限制 我的首页(关注对象的feed 列表) key-list 有时间(15天内) 和数量(500)双 重限制 Feed id => Feed content key-value value为小数据块 操作 性能(qps) 添加关注(关注的人有100条以上微博) 1007 删除关注 3797 发布微博(有1000个粉丝) 149 查看首页 498 查看我的微博 502 图3 内存消耗对比 图4 insert性能对比(qps) 图5 range性能对比(qps) 表1 对于微博产品中,核心的数据模型 表2 性能测试结果 前百度贴吧、地图产品架构师,前天涯高级架 构师。 天涯社区系统平台部数据系统架构师。喜爱开 源技术,关注高性能分布式系统,乐于技术交 流和分享。坚持simple is better,简单就是美。 责任编辑:高松(gaosong@csdn.net) 冯勇 赵威
还剩2页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 10 金币 [ 分享pdf获得金币 ] 0 人已下载

下载pdf

pdf贡献者

floating

贡献于2012-01-07

下载需要 10 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf