将 SQL 结构移植到 NoSQL MongoDB 或 CouchDB

Question

我正在尝试弄清楚您如何在 CouchDB 或 MongoDB 这样的文档存储系统中设计数据存储。

我不再在查询中使用 JOIN，而是坚持搜索具有符合我标准的某些索引的行。例如，我可能会查找最近的 cmets (ORDER BY date) 或所有活跃用户 (WHERE status = 1)。换句话说，我的搜索逻辑都是基于存储在 RAM 中的索引 int 列。

转到 NoSQL，似乎没有任何索引 - 所以我试图找出这些数据库过滤结果而不手动查看每一行。 更新：不知何故我错过了这个：http://vivu.tv/portal/archive.jsp?flow=783-586-4282&id=1270584002677

至于设计，使用将包含所有 cmets 的帖子存储为一个文档的示例在逻辑上似乎并不合理。您如何找到最近的 cmets？或者如何找到某个用户的 cmets？

我可以去哪里学习如何转换架构（以及我的思维方式），以便我可以使用这些文档数据库构建应用程序？

更新： 我猜我只是没有花足够的时间浏览 MongoDB 网站。 The documentation 似乎涵盖了大部分需要的东西，比如使用索引来过滤结果，就像在 sql 中一样。 http://www.mongodb.org/display/DOCS/SQL+to+Mongo+Mapping+Chart 和 http://rickosborne.org/download/SQL-to-MongoDB.pdf 也正是我所需要的。

Answer 1

其实与其说没有索引，不如说没有默认索引。如果不创建索引，使用 SQL 搜索会很慢。对于大多数 NoSQL 系统，如果您不创建索引，则根本不会发生搜索。用于索引的方法取决于您使用的特定系统 - 有时您使用搜索引擎来索引文档，有时它为每个可能的值存储一组 id。

我自己不同意将 cmets 存储在 post 文档中 - 将 cmets 作为由 post id 索引的单独文档更加灵活。但是，如果碰巧您不关心那些其他查询（并且您的平台支持部分更新），则单个文档是最简单的解决方案 - 正确的结构完全取决于您想用它做什么。

您不会找到任何通用的转换模式的方法，因为没有单一的正确答案。我认为最好的方法是考虑应用程序而不是数据 - 如果您的 sql 博客应用程序正在读取多个表并创建一个帖子对象，您知道您可能应该有一个帖子文档。

除了运行查询之外，您还应该尝试考虑其他解决方案，以利用 NoSQL 平台中的功能 - 例如，使用 redis，我会将最近的 cmets 实现为一个列表，每次添加评论时都会更新和修剪该列表。实际上，它是一个非常专业的索引 - 比检查系统中每条评论的日期要高效得多，并且当您无需担心更新架构时添加更多键/数据类型不是问题。