現在存文章內容用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 裡。