[置顶] 常见Key-Value存储系统的内存管理策略解析

        Key-Value存储作为NoSQL存储的一种常见方式,提供了比SQL数据库更好的可扩展性和 读写性能 。比如当前开源最热门的Memcached和Redis;淘宝的Tair、腾讯的Cmem、 Amazon的Dynamo等等,无论是做缓存还是持久存储,均使用内存作为主要存储介质,故内存管理策略就显得尤为重要了,是影响性能的重要因素。
        这里从源代码层面对Memcached、Redis和UDC(腾讯以前用的一套KV持久化存储系统)的内存管理策略进行分析,3者的内存管理策略各不相同,其他KV系统也和这3种方法大同小异了。最后对这3种策略进行了实际的性能测试分析,有出入的请使劲拍砖!

--------------------------------------------------------------------------

1 MemCached:Slab Allocation机制

3个 主要的 概念:
1 Chunk块:固定大小的数据块,数据存储的基本单位,1个Chunk 存1个数据,剩余空间不做其他用途
2 Slab页:固定大小的内存块(页),申请内存的基本单位,默认为1MB,每个SlabClass会把申请的Slab切分成相同大小Chunk来存数据
3 SlabClass:由Chunk的大小确定,是大小相同的所有Chunk块集合

如上图所示,Memcahed启动时, 会根据传入的-n(最小数据尺寸,默认48B),-f(增长因子,默认为1.25)启动选项初始化SlabClass。默认情况下,首个SlabClass的Chunk大小为80B(32B元数据头+48B最小数据尺寸),然后以1.25为比值生成等比数列,直到1MB(1个Slab页大小)为止。生成的SlabClass如下所示(perslab值为每个Slab页能分割出的Chunk个数):
$ memcached -vv
slab class 1: chunk size 80 perslab 13107
slab class 2: chunk size 104 perslab 10082
slab class 3: chunk size 136 perslab 7710
.....
slab class 41: chunk size 717184 perslab 1
slab class 42: chunk size 1048576 perslab 1

当用户发来请求时,Memcahed 会根 key+value 的值(能存放在1个Chunk内)来判断属于哪个SlabClass 。确定这个SlabClass 有无空闲的Chunk块,没有的话则先给这个SlabClass 申请一个Slab 页, 将该Slab页按 SlabClass Chunk 块大小进行切割,然后分配1个来存放用户数据。(这里还有LRU算法淘汰旧数据的逻辑,就不放在这里分析)。

这种策略的特点:
  • 实现较复杂
  • 参数的选择(最小数据尺寸,增长因子)直接影响性能及内存利用率
  • 每个数据存放于1个Chunk块,读写简单
相关源代码:主要由slab.h/c(SlabClass Slab 相关)、item.h/ c(Chunk块相关)这几个文件实现

SlabClass数据结构:

[置顶] 常见Key-Value存储系统的内存管理策略解析_第1张图片

* 初始化 SlabClass(通过增长因子计算各个SlabClass的Chunk块大小等)



* 为SlabClass[i]申请一块新Slab内存页

[置顶] 常见Key-Value存储系统的内存管理策略解析_第2张图片

---------------------------------------------------------------------------

2 Redis:简单mallc/free封装

相比Memcached,Redis做了一些优化。包括支持数据持久化( AOF和RDB两种持久化方式 ), 支持主从复制读写分离,支持更丰富的数据结构( string、hash、set、list等 )。
然而在内存管理方面,相比于 Memcached的Slab Allocation机制,Redis的实现就显得简单粗暴得多了,就只是 mallc/free的简单封装(屏蔽底层差异,添加相关元数据等)。

这种策略的特点:
  • 简单易实现,不易出错
  • 内存的利用率高
  • 大量系统调用开销大
  • 导致内存碎片,加重操作系统内存管理器负担
相关 源代码: zmalloc.h/c这两个文件实现,相对简单

* 申请内存

[置顶] 常见Key-Value存储系统的内存管理策略解析_第3张图片

* 释放内存



---------------------------------------------------------------------------

3 UDC:切分Shm成固定长度的块,组织空闲块链和用户数据块链

UDC是腾讯以前用的一套基于Shm的、全Cache的键值存储系统。 和MemCached或Redis使用进程堆内存不一样,UDC使用共享内存来存储数据,一方面进程Core的时候数据还在,一方面利于其他进程做数据落地、同步等操作。

[置顶] 常见Key-Value存储系统的内存管理策略解析_第4张图片

如上图所示,UDC启动时会申请一块大Shm(LinkTable),然后将这块Shm分割成固定长度的Chunk块(默认200B),通过下标组织成一条空闲块链。当收到添加数据的请求时,从空闲块链中不断取出空闲块存放用户数据,直到存放完成形成一条用户数据块链,链头下标存放于索引层中(基于Shm的多阶Hash)。当收到删除数据的请求时,直接将对应的用户数据块链清零,插入空闲块链中即可。

这种策略的特点:
  • 实现较复杂
  • 代码不健壮有写乱Shm块链的风险
  • Shm数据块大小的选择直接影响性能及内存利用率
  • 用户数据块链组织成用户数据需多一次拷贝影响性能
相关源代码: 主要由hash_cache.h/c 这2个文件实现

初始化 LinkTable

[置顶] 常见Key-Value存储系统的内存管理策略解析_第5张图片

* Set()操作,添加用户数据

[置顶] 常见Key-Value存储系统的内存管理策略解析_第6张图片

* Get()操作,获取用户数据

[置顶] 常见Key-Value存储系统的内存管理策略解析_第7张图片

-- -------------------------------------------------------------------------

性能测试:

实验前提:
* 机器:Intel(R) Xeon(R) CPU X3440 @2.53GHz (单线程,这里只用到1核),8G内存
* key为uint32_t,值为 [1, 50w] 的随机数
* value为string,串长度为 [50, 500] 之间的随机字节数

1 不同块大小选择对UDC性能的影响:

实验方案:
* 对不同的块大小,进行1000w次读+写操作(即每次1个Set加1个Get),计算总耗时和内存利用率
* 开足够大的Shm(400MB)保证能存下所有数据

实验数据:
* 块大小与总耗时(单位:s)的关系:
[置顶] 常见Key-Value存储系统的内存管理策略解析_第8张图片
* 块大小与内存利用率的关系:
[置顶] 常见Key-Value存储系统的内存管理策略解析_第9张图片

实验结论:
* 内存块越大,系统性能越好,但内存利用率越低。需要在这2着间取个平衡点
* 一般取值为"平均(key+value)长度/2 " ,且很容易理解,用户数据长度基本一致即波动范围小时,内存碎片会减低,内存利用率会增加

UDC、Memcache、Redis内存管理策略性能对比

实验方案:
* UDC策略使用默认块大小为200B,Memcached策略使用默认增长因子1.25
* 分别进行10w、50w.... 5千万、1亿次 压测操作, 每次进行1个Set加1个Get,计算总耗时和内存利用率

实验数据:
* 3种内存管理策略在不同压测次数下的总耗时(单位:s)情况
[置顶] 常见Key-Value存储系统的内存管理策略解析_第10张图片
* 本实验3种内存管理策略的内存利用率(与压测次数无关)
   - UDC策略:72.83%
   - Memcached策略:88.19%
   - Redis策略:98.77%

实验结论:
* Memcached的Slab Allocation机制在性能上的表现是最好的,且内存利用率也接近90%
* 当然,Memcached和Redis是基于进程堆的,主要用于缓存;UDC是基于Shm,用来做持久化存储,需考虑更多数据分布/同步/容灾等方面,3着没必要用来直接比较 ,这里只是单从内存管理策略上进行分析

你可能感兴趣的:(redis,memcached,内存管理,存储系统)