Question

我有Orm Frameworks的经验，我开始了解NoSql数据库解决方案的结构。我将继续研究基于对象模型的一些示例。

我有以下文档模型，我想想一些场景处理。

使用少量标签保存帖子
显示包含帖子数的标签列表
更新标记

public class Post
{
    public string Title { get; set; }
    public List<Tag> Tags { get; set; }
}

public class Tag
{
    public string Name { get; set; }
}

关于我的情景，我脑子里几乎没有问题。

Post class是一个将与标签一起保存的文档。在RDBMS中，Tag和Post有多对多的关系，但据我所知，它在NoSql中没有任何关系，因此post对象与整个成员一起保存。因此，显示带有post count方案的标记列表将导致整个帖子项中的大量查询在每个查询中付出一些努力，所以在这种情况下，我不会失去NoSql功能的所有好处吗？

更新标签名称不会导致一些复杂的工作？我必须查询整个帖子项并发现它有该标签名称并更新它。顺便说一下，它需要多文档事务和长进程，因此失败将导致我的数据库不一致，因为在NoSql中不支持多文档事务，那么我该如何处理呢？

我并不是想对RDBMS（Sql）系统展示NoSql的缺点。我只是想了解我的想法是否正确，这种情况与否，可能会有一些我错过的东西或者看起来很糟糕的东西并不像我想的那样糟糕。我需要可扩展性，这就是我对NoSql解决方案感兴趣的原因。

Answer 1

首先，NoSQL只是一个流行语，涵盖了许多不同的数据库类型，如键值存储，文档存储，图形数据库等......请参阅http://nosql-database.org/以获取不同类型和实现的列表。这些系统中的一些还具有交易保证，例如，对于你的情况，邮政被完全写入数据库。

我现在将专注于键值存储，因为它们似乎是一个非常突出的NoSQL实例。

关于你的第一个问题：你是对的，不会像RDBMS中的外键一样使用严格的关系，但你只需要保留一个与帖子实例关联的标签列表：

| pid | title | tags
|  1  | foo   | sql, rdbms
|  2  | bar   | sql, acid
...

对于按标记查询，您有一个所谓的倒置索引（http://en.wikipedia.org/wiki/Inverted_index），它为您提供了一个标记的所有文档ID：

| tag   | pids
| sql   | 1, 2
| rdbms | 1
| acid  | 2

这使得计算帖子非常容易。

更新标记名称实际上并不复杂，如果您对数据有基于地图限制的访问权限，那么您可以例如使用简单的作业（伪代码）将标签'Sql'更新为'SQL'：

map:    IF post.tag contains('Sql') THEN emit(post)

reduce: in post.tag: replace('Sql' by 'SQL')
        write(post)

但我不认为，重命名标签是常见的事情。 Brewer在CAP定理（http://en.wikipedia.org/wiki/CAP_theorem）中说明了漫长的处理时间和不一致性的问题，它基本上说你不能同时具有一致性，可用性和分区容忍度，并且你必须交易at至少有一个是另外两个。在您的情况下：如果您希望对标记进行一致的更新（这样就不会读取两个文档，其中一个标记为'Sql'而另一个文档已经是'SQL），则必须将表锁定为其他文档读者，因此你没有可用性。

最后的想法：如果你想构建一个高度可用，良好的扩展平台，你不希望以关系的方式思考太多。

CRUD场景的NoSql更新机制

1 个答案: