在过去的几天里，我一直在为自己（以及其他一些人）提供一个非常简单的网络服务，让我能够跟踪我读过的书以及我读过的书。虽然存储用户和书籍（标题+作者+未来可能更多的数据）相对简单，因为它们可以存储为具有密钥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，但是因为它是一个个人项目，所以我使用的并不重要。
答案 0 :(得分：2)
除非您出于某种原因需要非常高的吞吐量，否则听起来Redis不是正确的选择。听起来您想存储大量文档级信息，高吞吐量和数据结构都不是您的主要关注点。对我来说只是使用SQL而尖叫。您的数据非常原理 - 从您所说的内容来看，SQL实际上没有理由不适合您的用例。如果您与使用NoSQL的想法结合在一起，那么像Mongo这样的更通用的用例数据库之一也可以很好地运行。
Redis作为持久性数据库专门用于需要高吞吐量，数据结构很有用的情况，并且您不介意花费额外的成本将所有内容保存在内存而不是更便宜的HD空间。有很多场景Redis非常适合，但你的不是其中之一。