应该如何构造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

也许这不是一个绝对的答案，仅供参考。实际上，您的数据格式并不限制您选择的数据库，这两个数据库各有利弊。

关系数据库，例如SQL数据库：

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

但是，关系数据库的最大弱点是其最大优势的体现。尽管他们在处理结构化数据方面表现出色，但对非结构化数据却很难。

非关系型数据库，例如cosmosdb：

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

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

另外，成本也是要考虑的因素。您可以检查以下线程：Did anyone run any comparison between Azure SQL cost vs DocumentDB/CosmosDB cost?。

我认为，如果您的数据几乎总是结构化的，则业务逻辑是高度耦合的，那么我建议使用sql数据库。如果您的数据仅是部分结构，并且数据格式更灵活并且更易于水平扩展，则建议您使用Cosmos db。

希望它对您有帮助。