我目前正在与一个将CosmosDB作为后端存储实现的开发人员团队合作,并且我对如何真正使用它有一些疑问。
我知道文档应该是平面结构,但这到底是什么意思?
当数据确实是相互关联的并且非常相互依赖时,这种设计是否正确,还是更适合使用SQL数据库?
零售产品
{
"RetailProductId": "123",
"FriendlyName": "TestRetailProduct",
"WholeSaleProductId": "100"
}
批发产品
{
"WholeSaleProductId": "100",
"ProviderID": "112233445566",
"PhysicalItemsIds": ["1000", "2000", "3000"]
}
提供商
{
"ProviderId": "112233445566",
"Description": "ProviderA"
}
还有更多来自RetailProduct或WholeSaleProduct的文档链接,但这只是一个概述。
正在存储这样的数据,对于像CosmosDB这样的数据库来说,这是一种很好的做法
答案 0 :(得分:1)
也许这不是一个绝对的答案,仅供参考。实际上,您的数据格式并不限制您选择的数据库,这两个数据库各有利弊。
关系数据库,例如SQL数据库:
关系数据库擅长处理高度结构化的数据,并为ACID(原子性,一致性,隔离性和持久性)事务提供支持。使用SQL查询可以轻松地存储和检索数据。该结构可以快速扩展,因为无需修改现有数据即可添加数据非常简单。
但是,关系数据库的最大弱点是其最大优势的体现。尽管他们在处理结构化数据方面表现出色,但对非结构化数据却很难。
非关系型数据库,例如cosmosdb:
文档存储非常灵活。他们可以很好地处理半结构化和非结构化数据。用户无需在设置过程中知道将存储什么类型的数据,因此当事先不清楚要输入什么类型的数据时,这是个不错的选择。
NoSQL数据库能够合并任何类型的数据,而不会失去其任何扩展能力,并允许用户实时进行更改。
另外,成本也是要考虑的因素。您可以检查以下线程:Did anyone run any comparison between Azure SQL cost vs DocumentDB/CosmosDB cost?。
我认为,如果您的数据几乎总是结构化的,则业务逻辑是高度耦合的,那么我建议使用sql数据库。如果您的数据仅是部分结构,并且数据格式更灵活并且更易于水平扩展,则建议您使用Cosmos db。
希望它对您有帮助。