在过去的几天里，我一直在为自己(和其他一些人)开发一个非常简单的网络服务，它允许我跟踪我读过的书以及我阅读它们的时间。虽然存储用户和书籍(标题+作者+将来可能更多的数据)相对简单，因为它们可以存储为带有键user:username和book:uniqueID的哈希值> 事实证明，分别存储哪些用户阅读哪些书籍以及何时阅读是更具挑战性的。
我最初的计划是为用户 (user:username:readbooks) 提供一个排序集，该集使用时间戳作为分数(用于用户阅读该书的时间)和每本书的唯一 ID作为值。这种方法的问题是我无法存储用户读过两次书的信息(因为集合中不能有重复的值)。这也意味着为了跟踪一本书的读者，我必须将它们添加到第二组 readersof:bookID。
我当前的方法不是直接将图书 ID 存储在集合 user:username:readbooks 中，而是以 uniqueReadingEventId.bookId 的形式存储值，但是问题是，如果我删除一本书(而不是唯一的阅读事件)，我必须迭代readersof:bookID集合中的每个用户，迭代user:username中的每个值:readbooks 并删除与 x.bookId 匹配的值，这看起来效率有点低。此外，我可能想找到读过两本或以上共同书籍的用户。
因此，我的问题有两个:是否有更简单的方法在 Redis 中构建我的数据，或者我的数据是否可以更好地构建到不同的 NoSQL 系统？我真的很想继续使用 Redis，因为我喜欢它的 API，但是因为它是一个个人项目，所以我使用什么并不重要。
最佳答案
除非您出于某种原因需要非常高的吞吐量，否则 Redis 听起来并不是正确的选择。听起来您想要存储大量文档级信息，并且高吞吐量和数据结构都不是您所关心的。对我来说，仅仅使用 SQL 就令人尖叫。您的数据非常示意性 - 从您所说的来看，SQL 确实没有理由不能最好且最简单地适合您的用例。如果您热衷于使用 NoSQL，那么像 Mongo 这样的更通用的用例数据库之一也可以很好地发挥作用。
Redis 作为持久性数据库，专门用于需要高吞吐量、数据结构有用，并且您不介意支付将所有内容保存在内存中而不是便宜得多的硬盘空间的额外成本的情况。 Redis 适合很多场景，但您的场景不是其中之一。
关于nosql - 在Redis中存储双向关系数据，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/20451682/