扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
这篇文章将为大家详细讲解有关Redis数据库常见的键值设计有哪些,小编觉得挺实用的,因此分享给大家做个参考,希望大家阅读完这篇文章后可以有所收获。
创新互联主要从事网站设计制作、成都网站制作、网页设计、企业做网站、公司建网站等业务。立足成都服务安平,10年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:18980820575用户登录系统
记录用户登录信息的一个系统,我们简化业务后只留下一张表。
关系型数据库的设计
mysql>select*fromlogin;
+---------+----------------+-------------+---------------------+
|user_id|name|login_times|last_login_time|
+---------+----------------+-------------+---------------------+
|1|kenthompson|5|2011-01-0100:00:00|
|2|dennisritchie|1|2011-02-0100:00:00|
|3|JoeArmstrong|2|2011-03-0100:00:00|
+---------+----------------+-------------+---------------------+
user_id表的主键,name表示用户名,login_times表示该用户的登录次数,每次用户登录后,login_times会自增,而last_login_time更新为当前时间。
REDIS的设计
关系型数据转化为KV数据库,我的方法如下:
key表名:主键值:列名
value列值
一般使用冒号做分割符,这是不成文的规矩。比如在php-adminforredis系统里,就是默认以冒号分割,于是user:1user:2等key会分成一组。于是以上的关系数据转化成kv数据后记录如下:
Setlogin:1:login_times5
Setlogin:2:login_times1
Setlogin:3:login_times2
Setlogin:1:last_login_time2011-1-1
Setlogin:2:last_login_time2011-2-1
Setlogin:3:last_login_time2011-3-1
setlogin:1:name”kenthompson“
setlogin:2:name“dennisritchie”
setlogin:3:name”JoeArmstrong“
这样在已知主键的情况下,通过get、set就可以获得或者修改用户的登录次数和最后登录时间和姓名。
一般用户是无法知道自己的id的,只知道自己的用户名,所以还必须有一个从name到id的映射关系,这里的设计与上面的有所不同。
set"login:kenthompson:id"1
set"login:dennisritchie:id"2
set"login:JoeArmstrong: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数据库无啥区别。一个通过btreepk,一个通过hash,效果都很好。
假设有如下需求,查找最近登录的N个用户。开发人员看看,还是比较简单的,一个sql搞定。
select*fromloginorderbylast_login_timedesclimitN
DBA了解需求后,考虑到以后表如果比较大,所以在last_login_time上建个索引。执行计划从索引leafblock的最右边开始访问N条记录,再回表N次,效果很好。
有哪些常见Redis数据库键值的设计
过了两天,又来一个需求,需要知道登录次数最多的人是谁。同样的关系型如何处理?DEV说简单
select*fromloginorderbylogin_timesdesclimitN
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)
另外,求登录次数最多的人,对于排序,积分榜这类需求,sortedset非常的适合,我们把用户和登录次数统一存储在一个sortedset里。
zaddlogin:login_times51
zaddlogin:login_times12
zaddlogin:login_times23
这样假如某个用户登录,额外维护一个sortedset,代码如此
#对该用户的登录次数自增1
ret=r.zincrby("login:login_times",1,uid)
那么如何获得登录次数最多的用户呢,逆序排列取的排名第N的用户即可
ret=r.zrevrange("login:login_times",0,N-1)
可以看出,DEV需要添加2行代码,而DBA不需要考虑索引什么的。
TAG系统
tag在互联网应用里尤其多见,如果以传统的关系型数据库来设计有点不伦不类。我们以查找书的例子来看看redis在这方面的优势。
关系型数据库的设计
两张表,一张book的明细,一张tag表,表示每本的tag,一本书存在多个tag。
mysql>select*frombook;
+------+-------------------------------+----------------+
|id|name|author|
+------+-------------------------------+----------------+
|1|TheRubyProgrammingLanguage|MarkPilgrim|
|1|Rubyonrail|DavidFlanagan|
|1|ProgrammingErlang|JoeArmstrong|
+------+-------------------------------+----------------+
mysql>select*fromtag;
+---------+---------+
|tagname|book_id|
+---------+---------+
|ruby|1|
|ruby|2|
|web|2|
|erlang|3|
+---------+---------+
假如有如此需求,查找即是ruby又是web方面的书籍,如果以关系型数据库会怎么处理?
selectb.name,b.authorfromtagt1,tagt2,bookb
wheret1.tagname='web'andt2.tagname='ruby'andt1.book_id=t2.book_idandb.id=t1.book_id
tag表自关联2次再与book关联,这个sql还是比较复杂的,如果要求即ruby,但不是web方面的书籍呢?
关系型数据其实并不太适合这些集合操作。
REDIS的设计
首先book的数据肯定要存储的,和上面一样。
setbook:1:name”TheRubyProgrammingLanguage”
Setbook:2:name”Rubyonrail”
Setbook:3:name”ProgrammingErlang”
setbook:1:author”MarkPilgrim”
Setbook:2:author”DavidFlanagan”
Setbook:3:author”JoeArmstrong”
tag表我们使用集合来存储数据,因为集合擅长求交集、并集
saddtag:ruby1
saddtag:ruby2
saddtag:web2
saddtag:erlang3
那么,即属于ruby又属于web的书?
inter_list=redis.sinter("tag.web","tag:ruby")
即属于ruby,但不属于web的书?
inter_list=redis.sdiff("tag.ruby","tag:web")
属于ruby和属于web的书的合集?
inter_list=redis.sunion("tag.ruby","tag:web")
简单到不行阿。
从以上2个例子可以看出在某些场景里,关系型数据库是不太适合的,你可能能够设计出满足需求的系统,但总是感觉的怪怪的,有种生搬硬套的感觉。
尤其登录系统这个例子,频繁的为业务建立索引。放在一个复杂的系统里,ddl(创建索引)有可能改变执行计划。导致其它的sql采用不同的执行计划,业务复杂的老系统,这个问题是很难预估的,sql千奇百怪。要求DBA对这个系统里所有的sql都了解,这点太难了。这个问题在oracle里尤其严重,每个DBA估计都碰到过。对于MySQL这类系统,ddl又不方便(虽然现在有onlineddl的方法)。碰到大表,DBA凌晨爬起来在业务低峰期操作,这事我没少干过。而这种需求放到redis里就很好处理,DBA仅仅对容量进行预估即可。
关于“Redis数据库常见的键值设计有哪些”这篇文章就分享到这里了,希望以上内容可以对大家有一定的帮助,使各位可以学到更多知识,如果觉得文章不错,请把它分享出去让更多的人看到。
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流