现在存文章内容用hash类型：
post:$post_id title, content ... comment:$comment_id content, date, status posts: $post_id, $comment_id
存了一个hash类型的posts来表示关系，可能是还是没摆脱关系型数据库。
这种“一对多”的模式，如何在redis上更合理……更redis的体现出来. 应该如何设计这里
ringa_lee
NoSQL很少能完整的支持Join功能，所以在NoSQL里一般用denormalized form存储展开后的关系，因此这个关系不再是“多对一”，而是“一对多”。
你可以用集合类型存储子文档，比如Redis里的list或set，MongoDB里的sub-document等。
对于NoSQL，有一个简单的原则，就是把有关联的东西放在一起，比如文章和评论，注意，如果有可能，尽量把文章和评论的所有属性包括内容放在一起，而不是只在文章的记录中存储评论的id。 这样做的好处很明显，你只需要一次读操作就可以获取这篇文章相关的所有数据，无论怎样进行数据切分也不会把文章和它相关的东西分开到不同的物理机，这样可以极大的提高后台的可缩放性。 当然这样的设计并不总是适合你的应用，比如文章和作者之间的关系也许就没办法完全的denormailize，所以你需要仔细考虑数据展现的方式和流程，来决定到底该如何组织数据。
总之，NoSQL不是万灵药，它在提供更高的灵活性、可缩放性和性能的同时，也把原来的黑盒数据库简化成了白盒存储引擎，你需要自己在各个因素之间找到最适合的平衡点，这个工作确实需要很多经验和对业务的深入理解。
当然，如果数据量很小，这都不是事儿。
用list？
用set不就可以吗，把comments的id放在一个 post_id : set 里。
NoSQL很少能完整的支持Join功能，所以在NoSQL里一般用denormalized form存储展开后的关系，因此这个关系不再是“多对一”，而是“一对多”。
你可以用集合类型存储子文档，比如Redis里的list或set，MongoDB里的sub-document等。
对于NoSQL，有一个简单的原则，就是把有关联的东西放在一起，比如文章和评论，注意，如果有可能，尽量把文章和评论的所有属性包括内容放在一起，而不是只在文章的记录中存储评论的id。
这样做的好处很明显，你只需要一次读操作就可以获取这篇文章相关的所有数据，无论怎样进行数据切分也不会把文章和它相关的东西分开到不同的物理机，这样可以极大的提高后台的可缩放性。
当然这样的设计并不总是适合你的应用，比如文章和作者之间的关系也许就没办法完全的denormailize，所以你需要仔细考虑数据展现的方式和流程，来决定到底该如何组织数据。
总之，NoSQL不是万灵药，它在提供更高的灵活性、可缩放性和性能的同时，也把原来的黑盒数据库简化成了白盒存储引擎，你需要自己在各个因素之间找到最适合的平衡点，这个工作确实需要很多经验和对业务的深入理解。
当然，如果数据量很小，这都不是事儿。
用list？
用set不就可以吗，把comments的id放在一个 post_id : set 里。