Databases
Redis拥有与关系型数据库一样的基础概念。典型的使用场景就是将一个应用的所有数据归在一起，以与其他应用的数据区分开。
Redis中的数据库用数字作为标示符，默认数据库的标示为0。使用下面的命令选择具体的数据库：select
Commands, Keys and Values
在Redis中，key可以包含strings, hashes, lists, sets, sorted sets, bitmaps以及hyperloglogs。但就目前来说，知道key看起来像 "users:leto" 就够了。其中leto是用户名，冒号没有任何特殊含义，但就Redis而言，使用分隔符是一种常见的组织key的方式。
value可以是任何东西，字符串、数字、或序列化后的对象（例如：xml、json或其他格式）。多数情况下，Redis会把它们当字节数组对待，而不会关心它们具体是什么。
往Redis存入一个键值对：
set# 示例set users:leto '{"name": "leto", "planet": "dune", "likes": ["spice"]}'
根据key读取值：
get users:leto
Querying
Redis不支持对值进行查询，比如查询居住在dune星球上的用户。因为Redis从不需要去读取或理解存储的值，所以值才可以是任何东西。记住这点有助于我们在这个新世界中将心思放在考虑如何建模上。
Memory and Persistence
Redis是内存持久存储（in-memory persistent store）。说到持久化，默认情况下，Redis根据有多少key已经变化来决定是否需要对数据库做快照并保存至磁盘。你可以为它配置这样的快照策略：如果X个key发生了变化，就每Y秒保存一次数据库。默认策略为，如果1000个或更多的key发生了变化，就每60秒保存一次快照；如果9个或更少的key发生变化，就每15分钟做一次。
除了定时快照存储，Redis还可以运行在append模式(append mode)。任何时候，只要key发生了变化，磁盘上一个只可追加的(append-only)文件就会被更新。在一些情况下，丢失60秒的数据以换得性能是可接受的，因为可能会发生硬件或软件失败。但在一些情况下，这样的丢失又是不可接受的。Redis给我们提供了这些选择。第三种选择就是让slave节点去做持久化工作。
说到内存，Redis将所有数据保持在内存中。这就意味着运行Redis的成本比较高，毕竟RAM仍然是服务器硬件中最昂贵的部分。
一些开发者已经对数据会占用多小的空间失去了感觉，莎士比亚的所有作品大概占用5.5M，压缩后降至2。至于可伸缩性(scaling)，其他方案趋向受限于IO或CPU(IO- or CPU-bound)。哪个限制 (RAM or IO) 将需要你扩展出更多的机器实际上取决于你数据的类型和你正在任何存储和查询它。除非你正在存储大的多媒体文件，否则保存数据在内存中很可能不是什么问题。对于那些这一点确实是个问题的应用，你可能需要使用IO-bound的方案，而非memory-bound。
此外，还可考虑对存储数据进行压缩或解压缩，以处理时间换取RAM。
Redis虽然支持虚拟内存，但是这个特性被Redis开发者看做是一个失败，不赞成使用该特性。