Redis教程3--Redis键值设计

tag在互联网应用里尤其多见,首先看下面的关系型数据表:

Book表:


id


name


author


1


The Ruby Programming Language


Mark Pilgrim


2


Ruby on rail


David Flanagan


3


Programming Erlang


Joe Armstrong

Tag表:


tag_name


book_id


ruby


1


ruby


2


web


2


erlang


3

现在用redis将这两张表的数据存起来:

保存Book的数据:


redis 127.0.0.1:6379> incr book_id #用book_id这个key保存book表的id,每次要获得一个新的

#book_id用incr命令自增取得

(integer) 1

#incr命令返回1,则用key为book:1的hash来保存一个book对象,对象属性为hash的field

redis 127.0.0.1:6379> hset book:1 name "The Ruby Programming Language"

(integer) 1

redis 127.0.0.1:6379> hset book:1 author "Mark Pilgrim"

(integer) 1

redis 127.0.0.1:6379> hgetall book:1 #用hgetall命令测试一个,返回hash的所有属性和值

1) "name"

2) "The Ruby Programming Language"

3) "author"

4) "Mark Pilgrim"

redis 127.0.0.1:6379> incr book_id #创建第2个book对象,先incr一个book_id获得新book的id

(integer) 2

redis 127.0.0.1:6379> hset book:2 name "Ruby on rail"

(integer) 1

redis 127.0.0.1:6379> hset book:2 author "David Flanagan"

(integer) 1

redis 127.0.0.1:6379> hgetall book:2

1) "name"

2) "Ruby on rail"

3) "author"

4) "David Flanagan"

redis 127.0.0.1:6379> incr book_id

(integer) 3

redis 127.0.0.1:6379> hset book:3 name "Programming Erlang"

(integer) 1

redis 127.0.0.1:6379> hset book:3 author "Joe Armstrong"

(integer) 1

redis 127.0.0.1:6379> hgetall book:3

1) "name"

2) "Programming Erlang"

3) "author"

4) "Joe Armstrong"

保存Tag的数据,使用集合来存储数据,因为集合可以求交集、并集、差集:


redis 127.0.0.1:6379> sadd tag:ruby 1

(integer) 1

redis 127.0.0.1:6379> sadd tag:ruby 2

(integer) 1

redis 127.0.0.1:6379> sadd tag:web 2

(integer) 1

redis 127.0.0.1:6379> sadd tag:erlang 3

(integer) 1

如果要取得即属于ruby又属于web的书:


redis 127.0.0.1:6379> sinter tag:ruby tag:web

1) "2"

如果要取得属于ruby,但不属于web的书:


redis 127.0.0.1:6379> sdiff tag:ruby tag:web

1) "1"

属于ruby和属于web的书的合集:


redis 127.0.0.1:6379> sunion tag:ruby tag:web

1) "1"

2) "2"

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-11-10 15:30:17

Redis教程3--Redis键值设计的相关文章

浅谈REDIS数据库的键值设计(转)

add by zhj: 关系数据库表的一条记录可以映射成Redis中的一个hash类型,其实数据库记录本来就是键值对.这样,要比本文中的键设计用更少的键,更节省内存,因为每个键除了它的键值占用内存外,还额外占用一定的内存. 原文:http://www.hoterran.info/redis_kv_design 丰富的数据结构使得redis的设计非常的有趣.不像关系型数据库那样,DEV和DBA需要深度沟通,review每行sql语句,也不像memcached那样,不需要DBA的参与.redis的D

浅谈REDIS数据库的键值设计

原文地址:http://www.hoterran.info/redis_kv_design 丰富的数据结构使得redis的设计非常的有趣.不像关系型数据库那样,DEV和DBA需要深度沟通,review每行sql语句,也不像memcached那样,不需要DBA的参与.redis的DBA需要熟悉数据结构,并能了解使用场景. 下面举一些常见适合kv数据库的例子来谈谈键值的设计,并与关系型数据库做一个对比,发现关系型的不足之处. 用户登录系统 记录用户登录信息的一个系统, 我们简化业务后只留下一张表.

Redis 笔记与总结5 Redis 常用命令之 键值命令 和 服务器命令 && 高级应用之 安全性 和 主从复制

Redis 提供了丰富的命令对数据库和各种数据库类型进行操作,这些命令可以在 Linux 终端使用. 1. 键值相关命令: 2. 服务器相关命令 键值相关命令 ① keys 命令 返回满足给定 pattern 的所有 key. [例] 127.0.0.1:6379> keys * 1) "time" 2) "list4" 3) "list1" 4) "email" 5) "age" 6) "

Redis 常用命令之-----键值命令

欢迎大家加入 459479177QQ群进行交流 键值命令 这里就不介绍方法与描述啦,自己看例子 1.keys 查看key 127.0.0.1:6379> keys * 1) "skey2" 2) "skey1" 3) "name" 4) "zkey1" 127.0.0.1:6379> keys s* 1) "skey2" 2) "skey1" 2.del删除key 127.0

Redis教程03——Redis 发布/订阅(Pub/Sub)

Pub/Sub 订阅,取消订阅和发布实现了发布/订阅消息范式(引自wikipedia),发送者(发布者)不是计划发送消息给特定的接收者(订阅者).而是发布的消息分到不同的频道,不需要知道什么样的订阅者订阅.订阅者对一个或多个频道感兴趣,只需接收感兴趣的消息,不需要知道什么样的发布者发布的.这种发布者和订阅者的解耦合可以带来更大的扩展性和更加动态的网络拓扑. F为了订阅foo和bar,客户端发出一个订阅的频道名称: SUBSCRIBE foo bar 其他客户端发到这些频道的消息将会被推送到所有订

redis教程(二)-----redis事务、记录日志到redis、分布式锁

redis事务 Redis 事务可以一次执行多个命令, 并且带有以下两个重要的保证: 批量操作在发送 EXEC 命令前被放入队列缓存. 收到 EXEC 命令后进入事务执行,事务中任意命令执行失败,其余的命令依然被执行. 在事务执行过程,其他客户端提交的命令请求不会插入到事务执行命令序列中. 一个事务从开始到执行会经历以下三个阶段: 开始事务. 命令入队. 执行事务. 示例: //根据multi开启事务redis 127.0.0.1:6379> MULTI OK redis 127.0.0.1:6

redis教程(三)-----redis缓存雪崩、缓存穿透、缓存预热

缓存雪崩 概念 缓存雪崩是由于原有缓存失效(过期),新缓存未到期间.所有请求都去查询数据库,而对数据库CPU和内存造成巨大压力,严重的会造成数据库宕机.从而形成一系列连锁反应,造成整个系统崩溃. 解决方案 加锁排队 一般并发量不是特别多的时候,使用最多的解决方案是加锁排队. public object GetProductListNew() { const int cacheTime = 30; const string cacheKey = "product_list"; const

redis插入单个较大的键值

1.前言: 在linux的命令行界面或者是进入到redis数据库中,在插入较大的键值时,由于命令行界面对于字符个数的限制,都不能完全将redis的键值粘贴上去,这个时通过shell脚本比较容易实现 2.涉及的文件 redis.sh  #执行插入键值的脚本 redis.txt  #存放键值数据的文件 3.注意 在复制redis键值数据到redis.txt文件中的时候注意空格 4.执行插入脚本redis.sh #!/bin/bash #name: redis.sh #Author: lipc #Da

实现键值对存储(三):Kyoto Cabinet 和LevelDB的架构比较分析

译自  Emmanuel Goossaert (CodeCapsule.com) 在本文中,我将会逐组件地把Kyoto Cabinet 和 LevelDB的架构过一遍.目标和本系列第二部分讲的差不多,通过分析现有键值对存储的架构来思考我应该如何建立我自己键值对存储的架构.本文将包括: 1. 本架构分析的意图和方法 2. 键值对存储组件概览 3. Kyoto Cabinet 和LevelDB在结构和概念上的分析 3.1 用Doxygen建立代码地图 3.2 整体架构 3.3 接口 3.4 参数化