问题标签 [azure-cosmosdb]

这个问题可能会被表述为“扁平化还是不扁平化？”

如果我将嵌套的 JSON 文档存储在 DocumentDB 集合中，那么查询这些嵌套结构的性能是否与将这些嵌套结构作为平面文档单独存储在单独的集合中一样？

有问题的数据将被写入一次并且（可能）永远不会更新。报告性能位于要求列表的顶部。

一方面，将数据存储在嵌套结构中似乎是利用无模式/无 SQL 技术的“正确”方式。也就是说，我们自然希望在一个地方和上下文中将标题数据与详细数据相关联。但是，一旦我们每分钟写入数千行，同时从 Web 应用程序运行关于该集合的报告，它是否可以扩展并继续执行？

或者，将详细数据展平，将标题数据的相关部分冗余存储在详细信息集合的每一行中会更好吗？作为一名长期的 RDBMS 开发人员/用户，我倾向于不希望冗余存储数据，但我应该放弃这个想法以支持高性能吗？

平面数据结构在 DocumentDB 中的查询效率更高吗？还有多少余量？也就是说，我这样做会放弃什么，如果性能是最重要的（但不是唯一的）优先事项，是否值得？

似乎随机我无法从 DocumentDB 获取文档。我可以调试，让它失败并显示以下消息，然后重试并工作。如果这与我的 MAC 地址有关，我也尝试过从不同的工作站获得相同的结果。

Microsoft.Azure.Documents.UnauthorizedException, message: {"Errors":["在 HTTP 请求中找到的 MAC 签名与计算的签名不同。服务器使用以下字符串进行签名 - 'post\ndocs\nmo1oanohoga=\nwed , 2015 年 2 月 25 日 12:35:57 格林威治标准时间\n\n'"]}

我什至如何去a）报告这个和b）试图弄清楚发生了什么？

我有一个可以使用 azure 门户工具查询的 documentDb 实例：

当我在这样的代码中编写相同的查询时：

我收到此错误：

System.AggregateException：发生一个或多个错误。---> Microsoft.Azure.Documents.NotFoundException：为查询“$resolveFor”指定的值“SELECT * FROM TI WHERE TI.INDEX = 1”无效。在 Microsoft.Azure.Documents.BackoffRetryUtility`1.d__0.MoveNext()

我还有其他可以正常工作的查询。我想知道是否不应该使用“索引”？

提前致谢

嗨，我正在使用 16 个集合插入大约 3-4 百万个 json 对象，每个对象从 5-10k 不等。我使用存储过程来插入这些文档。我有 22 个容量单元。

我的 C# 代码看起来像这样

我面临的问题是在我尝试插入的 400k 文档中，有时文档会丢失而不会出现任何错误。

该应用程序是部署在云上的工作者角色。如果我增加在 documentDB 中插入的线程或实例的数量，那么丢失的文档数量会高得多。

如何找出问题所在。在此先感谢。

可以在 DocumentDB 查询中使用IN语句吗？喜欢：

我不想使用OR，因为有限制（只有 6 个）

使用大多数 Azure 服务，我可以在本地计算机上运行模拟器，例如存储模拟器。这允许我将凭据作为我的天蓝色网站上的应用程序设置存储到我的真实天蓝色存储帐户。在本地，我的 web.config 中有模拟器的凭据。

但是如何使用 Azure DocumentDB 实现同样的安全性呢？我不希望将凭据存储在本地 web.config 中，但同时我需要能够在开发时在本地运行应用程序。据我了解，DocumentDB 没有模拟器？我创建的所有 DocumentDB 的端点和身份验证密钥都相同吗？

那么，总结一下我的问题，在开发和使用 Azure DocumentDB 时处理身份验证密钥/端点的最佳做法是什么？

近年来，Microsoft 提供了一种“NoSQL”键/值存储，称为“表存储”（http://azure.microsoft.com/en-us/documentation/articles/storage-dotnet-how-to-use-表/ )

表存储提供了高性能、可扩展性（通过分区）和相对较低的成本。Tables 的一个主要缺点是只能索引 Partition 和 Row 键 - 因此对值进行查询非常低效。

最近微软宣布了一项新的“NoSQL”服务，称为“DocumentDB”（http://azure.microsoft.com/en-us/documentation/services/documentdb/）

DocumentDB 存储 JSON 对象，而不是存储属性列表（像 Tables 那样）。被索引的整个对象 - 可以基于存储对象的每个属性和任何嵌套属性创建高效查询。

微软表示 DocumentDB 也提供了高性能和可扩展性。

如果是这样 - 为什么有人会在 DocumentDB 上使用表存储？听起来 DocumentDB 提供了与 Tables 相同的功能，但具有其他功能，例如索引任何内容的能力。

如果有人可以在 DocumentDB 和 Table Storage 之间进行比较，我会很高兴，突出每一个的优缺点。

我的文档中有这样的数据结构（请注意，为简洁起见，这是简化的）：

我正在尝试编写一个查询来检索提供accountId的文档在父记录上或contributors数组内：

结果：

如您所见，第一个实体 ( Bruce Banner) 是重复的。如果我删除该JOIN子句，它会正常工作。谁能告诉我这是为什么，以及如何避免重复？

编辑- 为清楚起见，这是我的预期回复：

.createDocument()调用以在集合中插入少于 200 个文档时收到以下错误。它通常开始发生在第 150 个电话左右。我正在使用 Node.js SDK。发生这种情况时，没有其他操作在数据库上运行。

{ code: 429, body: '{"code":"429","message":"Exception: Microsoft.Azure.Documents.RequestRateTooLargeException, message: {\"Errors\":[\"Request rate is large\" ]}，请求URI：rntbd://10.100.136.85:14900/apps/1240113d-9858-49b9-90cb-1219f9e1df77/services/itsupportrequests-ServerService-1/partitions/d7253667-671b-4f4e-ac84-a13b7d3dbf5a/replicas 130701880511768464p\r\nActivityId: 5726e6b5-7955-4b39-b306-4903b9f69b36"}' }

这是我试图为 DocumentDB 实现分页以让所有学生进入第 10 级 A 部分的代码。

它在控制台应用程序中运行良好。

但是，当我尝试在我的 Web 应用程序中执行操作时，在异步调用（即 query.ExecuteNextAsync()）中，该过程正在终止，它甚至没有给出任何异常。

我不明白为什么它在控制台应用程序中执行，而不是在 Web 应用程序中执行。

这有什么问题吗？

或者有什么更好的方法来获得结果？

任何帮助将不胜感激。

提前致谢。