Fatal编程技术网
  • join/
  • Join 交叉连接集合和GroupBy CosmosDB Javascript API

Join 交叉连接集合和GroupBy CosmosDB Javascript API

join azure-cosmosdb

Join 交叉连接集合和GroupBy CosmosDB Javascript API,join,azure-cosmosdb,cosmos,document-based-database,Join,Azure Cosmosdb,Cosmos,Document Based Database,我正在CosmosDB的Javascript API中寻找一个解决方案，您可以在两个文档集合之间执行内部/外部连接 我失败了 据我所知，Javascript存储过程在一个集合中运行，不能访问/引用另一个集合中的数据 如果上述情况属实，那么以关系方式设计的应用程序的数据源将如何处理？如果业务需要立即查询，收集p以下数据： 在给定时间范围内，在特定区域内迁移到新产品产品的所有协议/合同。如果有大约5个集合包含与此查询相关的所有信息，我将如何进行此查询 有什么指导吗 更新 客户 协议 零售产品 批发商

我正在CosmosDB的Javascript API中寻找一个解决方案，您可以在两个文档集合之间执行内部/外部连接

我失败了

据我所知，Javascript存储过程在一个集合中运行，不能访问/引用另一个集合中的数据

如果上述情况属实，那么以关系方式设计的应用程序的数据源将如何处理？如果业务需要立即查询，收集p以下数据： 在给定时间范围内，在特定区域内迁移到新产品产品的所有协议/合同。如果有大约5个集合包含与此查询相关的所有信息，我将如何进行此查询

有什么指导吗

更新

客户

协议

零售产品

批发商产品：

{
    "id": "d054dae5-173d-478b-bb0e-7516e6a24476",
    "ProductName": "Data 100",
    "ProviderLiabilities": []
}
在上面，我添加了一些示例文档

关系：

  • Agreement.CustomerId指向Customer.id的链接
  • Agreement.RetailProductVersionInstance.RetailProductVersionId链接 零售商品id
  • RetailProduct.ThrightaleProductId链接到批发商Product.id
如何在CosmosDB中编写Javascript存储过程来执行这4个集合之间的连接？

简单的回答是，您不能通过Cosmos DB中的SQL在不同集合之间执行连接

通常，这类问题的解决方案是多个查询或不同的模式。在您的场景中，如果您可以在不复制数据的情况下将模式反规范化为一个集合，那么就很容易了

如果您提供您的模式，就有可能提供更全面的答案

--编辑1--

对于需要在同一集合+分区键上执行多个操作的操作，存储过程是唯一合适的候选对象。这使它们适用于大容量插入/删除/更新、事务（至少需要读写）和其他一些事情。它们不适用于CPU密集型的东西，而适用于通常受网络延迟限制的IO。它们不可能用于跨分区或跨集合场景。在这些情况下，您必须以独占方式从远程客户端执行操作

在您的例子中，这是一个相当简单的
2+2N
单独读取，其中
N
是产品的数量。你需要先阅读协议。然后您可以并行地查找客户和产品记录，然后您可以最后查找批发记录，因此您应该有
3s+C
的延迟，其中
s
是给定读取请求的平均持续时间，
C
是执行加入/发出请求/etc的一些恒定CPU时间

值得考虑的是，您是否可以将RetailProduct和WholeSale product合并到一个记录中，其中WholeSale包含数组中的所有RetailProduct，或者作为单独的文档，由批发id进行分区，并使用一个众所周知的id在单独的文档中包含批发产品信息。这将使您的延迟减少三分之一。如果您采用按批发id分区的思想，您可以为共享批发id的任何记录编写一个查询，这样您将获得
2+log（N）
读取，但有效延迟相同。对于该策略，您将在协议中存储“批发商ID+产品ID”的复合索引。需要担心的一个问题是，它复制了批发+产品的关系，但只要这种关系没有改变，我不认为有什么需要担心的，它为信息查找提供了一个很好的优化。

简短的回答是，您无法通过Cosmos DB中的SQL在不同集合之间执行联接

通常，这类问题的解决方案是多个查询或不同的模式。在您的场景中，如果您可以在不复制数据的情况下将模式反规范化为一个集合，那么就很容易了

如果您提供您的模式，就有可能提供更全面的答案

--编辑1--

对于需要在同一集合+分区键上执行多个操作的操作，存储过程是唯一合适的候选对象。这使它们适用于大容量插入/删除/更新、事务（至少需要读写）和其他一些事情。它们不适用于CPU密集型的东西，而适用于通常受网络延迟限制的IO。它们不可能用于跨分区或跨集合场景。在这些情况下，您必须以独占方式从远程客户端执行操作

在您的例子中，这是一个相当简单的
2+2N
单独读取，其中
N
是产品的数量。你需要先阅读协议。然后您可以并行地查找客户和产品记录，然后您可以最后查找批发记录，因此您应该有
3s+C
的延迟，其中
s
是给定读取请求的平均持续时间，
C
是执行加入/发出请求/etc的一些恒定CPU时间

值得考虑的是，您是否可以将RetailProduct和WholeSale product合并到一个记录中，其中WholeSale包含数组中的所有RetailProduct，或者作为单独的文档，由批发id进行分区，并使用一个众所周知的id在单独的文档中包含批发产品信息。这将使您的延迟减少三分之一。如果您采用按批发id分区的思想，您可以为共享批发id的任何记录编写一个查询，这样您将获得
2+log（N）
读取，但有效延迟相同。对于该策略，您将在协议中存储“批发商ID+产品ID”的复合索引。需要担心的一个问题是它会复制t 
{
    "id": "ee1094bd-16f4-45ec-9f5e-7ecd91d4e729",
    "CustomerId": "d02e6668-ce24-455d-b241-32835bb2dcb5"
    "RetailProductVersionInstance": 
    [
                {
        "id": "8ce31e7c-7b1a-4221-89a3-449ae4fd6622",
        "RetailProductVersionId": "ce7a44a4-7e49-434b-8a51-840599fbbfbb",
        "AgreementInstanceUser": {
            "FirstName": "Luke",
            "LastName": "Pothier",
            "AgreementUserTypeId": ""
        },
        "AgreementInstanceMSISDN": {
            "IsoCountryDialingCode": null,
            "PhoneNumber": "0839263922",
            "NetworkOperatorId": "30303728-9983-47f9-a494-1de853d66254"
        },
        "RetailProductVersionInstanceState": "IN USE",
        "IsPrimaryRetailProduct": true,
        "RetailProductVersionInstancePhysicalItems": [
            {
                "id": "f8090aba-f06b-4233-9f9e-eb2567a20afe",
                "PhysicalItemId": "75f64ab3-81d2-f600-6acb-d37da216846f",
                "RetailProductVersionInstancePhysicalItemNumbers": [
                    {
                        "id": "9905058b-8369-4a64-b9a5-e17e28750fba",
                        "PhysicalItemNumberTypeId": "39226b5a-429b-4634-bbce-2213974e5bab",
                        "PhysicalItemNumberValue": "KJDS959405"
                    },
                    {
                        "id": "1fe09dd2-fb8a-49b3-99e6-8c51df10adb1",
                        "PhysicalItemNumberTypeId": "960a1750-64be-4333-9a7f-c8da419d670a",
                        "PhysicalItemNumberValue": "DJDJ94943"
                    }
                ],
                "RetailProductVersionInstancePhysicalItemState": "IN USE",
                "DateCreatedUtc": "2018-11-21T13:55:00Z",
                "DateUpdatedUtc": "2020-11-21T13:55:00Z"
            }
        ]
    }
    ]
}

{
    "id": "ce7a44a4-7e49-434b-8a51-840599fbbfbb",
    "FriendlyName": "Data-Package 100GB",
    "WholeSaleProductId": "d054dae5-173d-478b-bb0e-7516e6a24476"
}

{
    "id": "d054dae5-173d-478b-bb0e-7516e6a24476",
    "ProductName": "Data 100",
    "ProviderLiabilities": []
}