Cosmos DB 数据应该如何构建

Question

我目前正在与一个开发团队合作，将 CosmosDB 实现为后端存储，我对它的实际用途有一些疑问。

我知道这些文档应该是扁平结构的，但这到底是什么意思？

当数据确实是相关的并且彼此非常依赖时，这种设计是否正确，或者 SQL 数据库是否更适合？

零售产品

{
    "RetailProductId": "123",
    "FriendlyName": "TestRetailProduct",
    "WholeSaleProductId": "100"
}

批发产品

{
    "WholeSaleProductId": "100",
    "ProviderID": "112233445566",
    "PhysicalItemsIds": ["1000", "2000", "3000"]
}

提供者

{
    "ProviderId": "112233445566",
    "Description": "ProviderA"
}

RetailProduct 或 WholeSaleProduct 还链接了更多文档，但这只是为了提供概述。

像这样存储数据，被认为是像 CosmosDB 这样的数据库的良好实践

Answer 1

也许这里不是绝对的答案，仅供您参考。实际上，您的数据格式并不限制您选择哪种数据库，两种数据库都有其优缺点。

\n

关系型数据库如SQL数据库：

\n

关系数据库擅长处理高度结构化的数据，并提供对 ACID（原子性、一致性、隔离性和持久性）事务的支持。使用 SQL 查询可以轻松存储和检索数据。该结构可以快速扩展，因为添加数据而不修改现有数据很简单。

\n

然而，关系数据库的最大弱点正是其最大优势的镜像。尽管他们擅长处理结构化数据，但他们却很难处理非结构化数据。

\n

非关系数据库，例如 Cosmos DB：

\n

文档存储非常灵活。它们可以很好地处理半结构化和非结构化数据。用户在设置过程中不需要知道将存储什么类型的数据，因此，当事先不清楚将传入什么类型的数据时，这是一个不错的选择。

\n

NoSQL 数据库能够合并任何类型的数据，而不会失去任何扩展能力，并允许用户实时进行更改。

\n

另外，成本也是一个需要考虑的因素。您可以查看此帖子：Comparison Between Azure SQL cost vs DocumentDB/CosmosDB cost。

\n

在我看来，如果你的数据几乎都是结构化的，业务逻辑是高度耦合的，那么我建议使用SQL数据库。如果你的数据只是部分结构化，并且数据格式更灵活且更容易水平扩展，我建议你使用 Cosmos DB。

\n