承认这一点我有点尴尬,但我在概念化如何在非关系世界中构建数据时遇到了麻烦。特别是考虑到大多数文档/KV 存储的功能略有不同。
我想从一个具体的例子中学习,但我找不到任何人讨论你将如何构建,例如,使用 CouchDB/Redis/MongoDB/Riak/etc 的博客。
有几个我认为很重要的问题:
- 哪些数据应该被非规范化(例如标签可能与文档一起存在,但用户呢)
- 文档之间如何链接?
- 创建聚合视图的最佳方法是什么,尤其是需要排序的视图(例如博客索引)
首先,我认为您希望从列表中删除 redis,因为它是键值存储而不是文档存储。Riak 也是一个键值存储,但您可以将它作为像Ripple这样的库的文档存储。
简而言之,使用文档存储对应用程序进行建模需要弄清楚:
您希望在另一个文档中存储(嵌入)哪些数据。如果该文档仅属于一个文档,那么将其存储在另一个文档中“可能”是一个不错的选择。
{ article : { comments : [{ content: 'yada yada', timestamp: '20/11/2010' }] } }
您要考虑的另一个警告是嵌入文档的大小有多大,因为在 mongodb 中,嵌入文档的最大大小为 5MB。
{ article: { tags: ['news','bar'] } }
{ user: { role_ids: [1,2,3]}}
这是关于使用文档存储进行建模的简要概述。祝你好运。
决定哪些对象应该是独立的,哪些应该作为其他对象的一部分嵌入,主要是平衡读/写性能/工作量的问题——如果一个子对象是独立的,更新它意味着只更改一个文档,但是在读取父对象时你只有 ids 并且需要额外的查询来获取数据。如果嵌入了子对象,那么当您阅读父文档时,所有数据都在那里,但进行更改需要找到使用该对象的所有文档。
文档之间的链接与 SQL 没有太大区别——您存储一个用于查找适当记录的 ID。关键区别在于,不是过滤子表以按父 ID 查找记录,而是在父文档中有一个子 ID 列表。对于多对多关系,您将在两边都有一个 id 列表,而不是在中间有一个表格。
不同平台的查询功能差异很大,因此对于如何解决这个问题没有明确的答案。但是,作为一般规则,您通常会在编写文档时设置视图/索引,而不是像使用 SQL 那样仅存储文档并稍后运行临时查询。
几周前,Ryan Bates 制作了一个关于 mongoid 的截屏视频,他使用了一个博客应用程序示例:http ://railscasts.com/episodes/238-mongoid这可能是您入门的好地方。