CosmosDB应该像文档数据库还是图形数据库一样建模？

Question

我看到CosmosDb既可以支持图形查询，也可以支持更传统的SQL查询 - 但是我对于哪种底层模式在集合级别最好而感到困惑。如果我要在MongoDb或SQL Server或Neo4j中建模，我会有非常不同的模式。此外 - 似乎我可以使用更传统的类似SQL的语法进行查询 - 这使得它对于正确或有效的内容感到困惑。有时，使一些易于查询的东西并不意味着人们应该认为这是一个有效的查询。

CosmosDb在它的核心是一个文档数据库，我应该相应地对它进行建模 - 或者它是一个非常不同的野兽。

示例用例

这是一个例子 - 假设我有：

1. 用户个人资料
2. 多种帖子类型（照片，博客，问题）
3. 用户可以喜欢照片
4. 用户可以对照片，博客，问题进行评论

使用sql数据库我会有表：

• 简档
• 照片
• 博客
• 问题

并连接具有参照完整性的表以支持操作：

• photoLikes
• blogComments
• photoComments
• questionComments

使用图表数据库

我只有相同的核心表

• 简档
• 照片
• 博客
• 问题

只需为喜欢和评论创建图形关系类型 - 依靠代码业务逻辑来强制执行您不喜欢博客的规则等。

使用像MongoDb

这样的文档数据库

同样，我可能有相同的核心表

• 简档
• 照片
• 博客
• 问题

评论将是每个下面的子集合 - 并且会有一个问题，我们是否希望将喜欢作为嵌入式集合保存在每个配置文件下或照片下...我们将不得不增加并同步一个类似的计数到另一个集合（取决于用例，我们也可以创建一个类似的集合）。评论将作为嵌入式集合隐藏在每张照片，博客或问题下，并且没有自己的顶级集合。

所以我的问题是：

我们如何在CosmosDB中对此架构进行建模？我们应该像MongoDb这样的传统文档数据库对其进行建模，还是可以访问图形查询，从而为我们提供额外的自由，例如不必为“喜欢？”等操作重新规范化字段。

Answer 1

Azure Cosmos DB数据库引擎旨在完全与模式无关。 容器（可以是图形，文档集合或表）是与任意用户生成的内容无关的模式容器，它在摄取时自动编入索引。我建议阅读“使用Azure DocumentDB进行模式识别索引” - http://www.vldb.org/pvldb/vol8/p1668-shukla.pdf，这与Cosmos DB中的内容相同，以便更好地理解详细信息。

Answer 2

  

我们如何在CosmosDB中对此架构进行建模？我们应该像MongoDb这样的传统文档数据库对其进行建模，还是可以访问图形查询，从而为我们提供额外的自由，例如不必为“喜欢？”等操作重新规范化字段。

当您开始在Azure Cosmos DB中建模数据时，您需要考虑： 1.您的应用程序是读取重量还是重写？ 2.您的应用程序如何查询和更新数据？等 即可。通常，非规范化数据模型可以提供更好的读取性能，规范化可以提供更好的写入性能。

This article通过示例解释了如何为NoSQL数据库建模文档数据，并分享了使用嵌入数据模型，规范化数据模型和混合数据模型，应该会有所帮助。