RDBMS库表与Redis模型间的一种映射方式
| Key | Value | 备注 | |
| 类型 | 取值说明 | ||
| Tab:id | STRING | 整数字符串 | 表主键tab_id取值来源 Key名规则：表名称：id 初始值为0，每次新增记录前调用INCR命令加1 |
| Tab:tab_id值 | HASH | 列名/列值HASHMAP | 主表每条记录除主键以外其他列值存储结构 Key名规则：表名称：记录主键值 |
| emp_id | ename | mgr_id |
| 1 | SMITH | 8 |
| 2 | ALLEN | 8 |
| 3 | SALESMAN | 7 |
| Key名称 | Value值 |
| emp:id | 3 |
| emp:1 | { ename=” SMITH”, mgr_id=”8” } |
| emp:2 | { ename=” ALLEN”, mgr_id=”8” } |
| emp:3 | { ename=” SALESMAN”, mgr_id=”7” } |
| Key | Value | 备注 | |
| 类型 | 取值说明 | ||
| Tab:indices:col_idx:col_idx值 | SET | 所有col_idx列值等于Key中col_idx值的记录的主键值集合 | 表非唯一索引列col_idx对应的键值对 Key名规则：表名称：idices:索引列名称:索引列数值 这样的键值对可能存在多个，每个索引列取值对应一个 |
| emp_id | ename | mgr_id |
| 1 | SMITH | 8 |
| 2 | ALLEN | 8 |
| 3 | SALESMAN | 7 |
| Key名称 | Value值 |
| emp:id | 3 |
| emp:1 | { ename=” SMITH”, mgr_id=”8” } |
| emp:2 | { ename=” ALLEN”, mgr_id=”8” } |
| emp:3 | { ename=” SALESMAN”, mgr_id=”7” } |
| emp:indices:mgr_id:7 | ( 3 ) |
| emp:indices:mgr_id:8 | ( 1, 2 ) |
| Key | Value | 备注 | |
| 类型 | 取值说明 | ||
| Tab:uniques:col_uniq | HASH | col_uniq列值/对应记录主键值 | 表非唯一索引列col_idx对应的键值对 Key名规则：表名称：uniques:索引列名称 |
| emp_id | ename | |
| 1 | SMITH | foo@gmail.com |
| 2 | ALLEN | bar@163.com |
| 3 | SALESMAN | zoo@hotmail.com |
| Key名称 | Value值 |
| emp:id | 3 |
| emp:1 | { ename=” SMITH”, email=” foo@gmail.com” } |
| emp:2 | { ename=” ALLEN”, email =” bar@163.com” } |
| emp:3 | { ename=” SALESMAN”, email =” zoo@hotmail.com” } |
| emp:uniques:email | { foo@gmail.com = “1”, bar@163.com = “2”, |
| zoo@hotmail.com = “3” |
年前一段时间，在内存数据库选型上，还在Aerospike与Redis两者间游移不定。因为Redis毕竟业界已经有很多成功案例，而且国内互联网大佬们BAT也在使用，网上资源也很丰富；而Aerospike刚刚开源，在应用案例与技术资源这两方面是一穷二白。
在游移的这段时间，也看了不少Redis的网上技术文档和一些ORM开源实现，对关系数据库（RDBMS）表与Redis模型间的映射方式简单总结了下，记录在这里备忘。
由于Redis只是简单的Key-Value（键-值）存储系统，没有RDBMS中表与索引概念，要在Redis中实现原有数据库表模型的访问方式，必须有一种模型的转换方法，即模型间的映射方式，将RDBMS中的表与索引概念转成Redis Key-Value对象。
后面的映射方式说明中，有个前提假设是：关系数据库模型使用非业务含义数值序列做为主键。这可能与实际不符合，需根据情况进行调整。采用数值做为主键，主要目的是节省Redis模型索引数据的内存占用，内存能省点是点儿，地主家也没有余粮啊。
Redis模型中所有Key-Value的创建维护，包括对应RDBMS表索引的Key-Value创建和维护，以及唯一索引的唯一性保证，都是由应用程序自身完成，Redis只负责数据保存。
表模型
另外，Redis模型中所有Key-Value的创建和维护，包括对应于RDBMS库表索引的Key-Value创建和维护，以及唯一索引的唯一性保证，都要由应用程序自身来完成，Redis只负责数据的存储。
表模型
RDBMS表模型
Redis模型
上图中的RDBMS模型转换成Redis模型，各Key-Value键值说明如下：
举例
例如：表emp的数据及转换成Redis模型的数据如下：
非唯一单列索引模型
RDBMS表模型
表在列col_idx上建有非唯一索引。
Redis模型
上图模型中的RDBMS索引转换成Redis模型，索引相关Key-Value键值说明如下：
举例
例如：表emp在mgr_id上建有非唯一索引,表数据及转换成Redis模型的数据如下：
唯一单列索引模型
RDBMS表模型
表在列col_uniq上建有唯一索引。
Redis模型
上图模型中的RDBMS索引转换成Redis模型，索引相关Key-Value键值说明如下：
举例
例如：表emp在email上建有唯一索引,表数据及转换成Redis模型的数据如下：
（非）唯一多列组合索引模型
RDBMS表模型
表在列col_idx1、col_idx2上建有非唯一组合索引，
在列col_uniq1、col_uniq2上建有唯一组合索引。
Redis模型
上图模型中的索引转换成Redis模型，索引相关Key-Value键值说明如下：
|
Key |
Value |
备注 |
|
|
类型 |
取值说明 |
||
|
Tab:indices:col_idx1:col_idx1值:col_idx2:col_idx2值 |
SET |
所有符合索引列值条件的记录的主键值集合 |
表非唯一索引列col_idx1、col_idx2对应的键值对 Key名规则：表名称：idices:索引列1名称:索引列1数值:索引列2名称:索引列2数值: 这样的键值对可能存在多个，每组索引列取值对应一个 |
|
Tab:uniques:col_uniq1:col_uniq2 |
HASH |
col_uniq1列值、col_uniq2列值组合/对应记录主键值 |
表非唯一索引列col_uniq1、col_uniq2对应的键值对 Key名规则：表名称：uniques:索引列1名称:索引列2名称 |
其实（非）唯一多列组合索引是没有必要的，可用在组合索引中各列上建立非唯一单列索引的方式替代，因为非唯一单列索引使用的是SET（集合），所有在组合索引上的条件查询可转化成集合的运算来实现：SUNION、SDIFF、SINTER等
关联关系（一对多/一对一）
RDBMS表模型
Redis模型
父表不需要特殊处理，将子表关联父表的parent_id列做为非唯一索引处理，参见非唯一单列索引模型。