redis可以存储比较复杂的json类型数据嘛，并且可以根据json k，v 进行查询？

这个需求看起来应该是更适合用 MongoDB 解决。

目前用的是mongodb，考虑到数据不需要永久保存，而mongodb是内存映射存储，考虑使用redis，对redis，不了解。

redis 的集合都是平的

但是用 ohm 在语言层面处理嵌套数据

http://soveran.github.com/ohm/

json对象可以存在redis-hash里面, 但是value只能是字符串, 你可以在应用层做一些工作, 比如把value变成另外一个redis-hash的key...

谢谢各位，看了一些资料觉得还是可以做到的。

@ergatea MongoDB可以根据数据量作cap

我还是感觉你在谈PostgreSQL的强项。

我的需求比较特殊，redis吸引我的是性能和EXPIRE
posts =［{'slug':'hash','body':json,'...':'...'},{},{}］
数据中body是json文件不需要持久存储，基于文件，我不打算存储
mongodb store ［{'slug':'hash','...':'...'},{},{}］
redis store hset('post:user:slug:hash' body pickle.dumps(json))

不知道是否准确理解了你的问题。

单层的 key-val 结构可以直接用 redis hash 存储 object-id: [key: val, key: val, ...]
多层的 key-val 结构，可以把 key 压平，继续存在 redis hash 里 object-id: [key: val, keyl1.keyl2: val, ...] 根据 redis 的文档，这种结构在 key 的数量很大（超过 255 个以上，有相关配置）时效率开始下降。
层次更多以及 key 的数量不一定的结构，可以参考 full-text-index 的反向索引方案 object-id: [key, key, ...] key: [object-id, object-id, ...] 这等于是自己用逻辑实现了索引。

redis 这类 low level 东西的限制是：只能按 key 来查，没有 key 查询效率就很糟糕。这是坏事（不理解的话，就觉得不好用），同时也是好事（这种限制，显式地表达了索引逻辑，即，没建索引就查询不了）。