浅谈Redis数据库的键值设计
作者:网络转载 发布时间:[ 2015/11/6 11:25:09 ] 推荐标签:Redis 数据库
丰富的数据结构使得redis的设计非常的有趣。不像关系型数据库那样,DEV和DBA需要深度沟通,review每行sql语句,也不像memcached那样,不需要DBA的参与。redis的DBA需要熟悉数据结构,并能了解使用场景。
下面举一些常见适合kv数据库的例子来谈谈键值的设计,并与关系型数据库做一个对比,发现关系型的不足之处。
用户登录系统
记录用户登录信息的一个系统, 我们简化业务后只留下一张表。
关系型数据库的设计
mysql> select * from login;
+---------+----------------+-------------+---------------------+
| user_id | name | login_times | last_login_time |
+---------+----------------+-------------+---------------------+
| 1 | ken thompson | 5 | 2011-01-01 00:00:00 |
| 2 | dennis ritchie | 1 | 2011-02-01 00:00:00 |
| 3 | Joe Armstrong | 2 | 2011-03-01 00:00:00 |
+---------+----------------+-------------+---------------------+
user_id表的主键,name表示用户名,login_times表示该用户的登录次数,每次用户登录后,login_times会自增,而last_login_time更新为当前时间。
redis的设计
关系型数据转化为KV数据库,我的方法如下:
key 表名:主键值:列名
value 列值
一般使用冒号做分割符,这是不成文的规矩。比如在php-admin for redis系统里,是默认以冒号分割,于是user:1 user:2等key会分成一组。于是以上的关系数据转化成kv数据后记录如下:
Set login:1:login_times 5
Set login:2:login_times 1
Set login:3:login_times 2
Set login:1:last_login_time 2011-1-1
Set login:2:last_login_time 2011-2-1
Set login:3:last_login_time 2011-3-1
set login:1:name ”ken thompson“
set login:2:name “dennis ritchie”
set login:3:name ”Joe Armstrong“
这样在已知主键的情况下,通过get、set可以获得或者修改用户的登录次数和后登录时间和姓名。
一般用户是无法知道自己的id的,只知道自己的用户名,所以还必须有一个从name到id的映射关系,这里的设计与上面的有所不同。
set "login:ken thompson:id" 1
set "login:dennis ritchie:id" 2
set "login: Joe Armstrong:id" 3
这样每次用户登录的时候业务逻辑如下(python版),r是redis对象,name是已经获知的用户名。
#获得用户的id
uid = r.get("login:%s:id" % name)
#自增用户的登录次数
ret = r.incr("login:%s:login_times" % uid)
#更新该用户的后登录时间
ret = r.set("login:%s:last_login_time" % uid, datetime.datetime.now())
如果需求仅仅是已知id,更新或者获取某个用户的后登录时间,登录次数,关系型和kv数据库无啥区别。一个通过btree pk,一个通过hash,效果都很好。
假设有如下需求,查找近登录的N个用户。开发人员看看,还是比较简单的,一个sql搞定。
select * from login order by last_login_time desc limit N
DBA了解需求后,考虑到以后表如果比较大,所以在last_login_time上建个索引。执行计划从索引leafblock 的右边开始访问N条记录,再回表N次,效果很好。
过了两天,又来一个需求,需要知道登录次数多的人是谁。同样的关系型如何处理?DEV说简单
select * from login order by login_times desc limit N
DBA一看,又要在login_time上建立一个索引。有没有觉得有点问题呢,表上每个字段上都有素引。
关系型数据库的数据存储的的不灵活是问题的源头,数据仅有一种储存方法,那是按行排列的堆表。统一的数据结构意味着你必须使用索引来改变sql的访问路径来快速访问某个列的,而访问路径的增加又意味着你必须使用统计信息来辅助,于是一大堆的问题出现了。
没有索引,没有统计计划,没有执行计划,这是kv数据库。
redis里如何满足以上的需求呢? 对于求新的N条数据的需求,链表的后进后出的特点非常适合。我们在上面的登录代码之后添加一段代码,维护一个登录的链表,控制他的长度,使得里面永远保存的是近的N个登录用户。
#把当前登录人添加到链表里
ret = r.lpush("login:last_login_times", uid)
#保持链表只有N位
ret = redis.ltrim("login:last_login_times", 0, N-1)
这样需要获得新登录人的id,如下的代码即可
last_login_list = r.lrange("login:last_login_times", 0, N-1)
另外,求登录次数多的人,对于排序,积分榜这类需求,sorted set非常的适合,我们把用户和登录次数统一存储在一个sorted set里。
zadd login:login_times 5 1
zadd login:login_times 1 2
zadd login:login_times 2 3
这样假如某个用户登录,额外维护一个sorted set,代码如此
#对该用户的登录次数自增1
ret = r.zincrby("login:login_times", 1, uid)
那么如何获得登录次数多的用户呢,逆序排列取的排名第N的用户即可
ret = r.zrevrange("login:login_times", 0, N-1)
可以看出,DEV需要添加2行代码,而DBA不需要考虑索引什么的。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11