标签: azure-cosmosdb

我最近通过以下链接在 Visual Studio 2015 中创建了一个应用程序：https : //azure.microsoft.com/en-in/documentation/articles/documentdb-dotnet-application/

但是当我构建解决方案时，它显示了以下错误：

值不能是null。
参数名称：uriString
第71行：public static void Initialize()
第72行：{
第73行：client = new DocumentClient(new Uri(ConfigurationManager.AppSettings["https://<db-name>.documents.azure.com:443/"]), ConfigurationManager.AppSettings["<db-key>"]);
第74行：CreateDatabaseIfNotExistsAsync().Wait();
第75行：CreateCollectionIfNotExistsAsync().Wait();

源文件：C:\Users\BHAVIN PATEL\Documents\Visual Studio 2015\Projects\documentdb-dotnet-todo-app-master\src\DocumentDBRepository.cs 行：73

我已Web.config在 Azure 中创建的 DocumentDB 应用程序的应用程序文件中插入了 URI 和主键/辅助键。

有人可以解释我如何配置Azure cosmosDB不那么昂贵吗？3天30€？这是一个用户很少的小型测试环境.

在后端,我只看到它将花费一些美分......

这是我的成本概述:

我有大约18个系列,但都只有kbits大.它是js cms的后端数据库:http://keystonejs.com/

azure中一个集合的示例缩放:

我正在使用CosmosDB（以前是DocumentDB）进行调查，我们目前使用MongoDB，因此我试图将MongoAPI用于CosmosDB。

我已经在azure中创建了一个CosmosDB部署，创建了一个集合，并指定了“ / rateId”分区键。

据我从Microsoft的文档了解，此分区键应与我插入的每个文档中的一个属性相关，因此我试图插入一个基本文档，如下所示：

{
    "rateId": "test.1",
    "val": "test2"
}

但是，当我尝试插入此内容（通过Mongo C＃驱动程序或通过MongoChef）时，出现错误“文档不包含分片键”。

我已经尽我所能地尝试了此方法，并且每次都因该错误而被拒绝。我是在误解这是怎么工作的，还是做错了什么？

Microsoft Cosmos DB包括DocumentDB API,Table API等.我有大约10 TB的数据,并希望有一个快速的键值查找(很少更新和写入,大多数是读取).添加Microsoft Cosmos DB的链接:https: //docs.microsoft.com/en-us/azure/cosmos-db/

1. 那么我该如何在DocumentDB API和Table API之间做出选择呢？
2. 或者我应该何时选择DocumentDB API？我什么时候应该选择Table API？
3. 使用DcoumentDB API存储10 TB数据是一个好习惯吗？

我有一个活动项目,一直使用C#,实体框架和SQL Server.但是,随着NoSQL备选方案日益增加的可行性,我正在研究将项目转换为使用MongoDB的所有影响.

很明显,主要的过渡障碍是由于"无架构".什么暗示对于像C#语言的一个很好的总结发现这里的官方MongoDB的文档.以下是最有用的相关段落(粗体添加):

仅仅因为MongoDB是无模式的并不意味着您的代码可以处理无模式文档.最有可能的是,如果您使用的是静态类型语言(如C#或VB.NET),那么您的代码就不灵活,需要映射到已知的模式.

架构可以通过多种不同方式从应用程序的一个版本更改为下一个版本.

你如何处理这些取决于你自己.有两种不同的策略:编写升级脚本.在使用文档时逐步更新文档.最简单的策略是编写升级脚本.关系数据库(SQL Server,Oracle)和MongoDB之间的这种方法实际上没有区别.确定需要更改的文档并进行更新.

或者,在大多数关系数据库中不支持,是增量升级.我们的想法是,您的文档在使用时会得到更新.从未使用的文档永远不会更新.因此,您需要注意一些明确的陷阱.

首先,针对一半文档是版本1而一半文档是版本2的架构的查询可能会出错.例如,如果重命名元素,则查询将需要测试旧元素名称和新元素名称以获取所有结果.

其次,任何增量升级代码必须保留在代码库中,直到所有文档都已升级.例如,如果有文档的3个版本,[1,2和3]并且我们将升级代码从版本1移除到版本2,那么仍然作为版本1存在的任何文档都是不可升级的.

用于在SQL生态系统中管理/创建此类初始化或升级脚本的工具非常成熟(例如,实体框架迁移)

虽然在NoSQL世界中有类似的工具和自制脚本可用于此类升级(尽管有些人认为不应该这样),但似乎对"何时"和"如何"运行这些升级脚本的共识较少.有些建议在部署之后.不幸的是,这种方法(当不与增量更新一起使用时)可能会在尝试读取C#模型已更改的现有数据时使应用程序处于不可用状态.

如果

" 最简单的策略是编写升级脚本. "

对于像C#这样的静态.NET语言来说,它是真正最简单/推荐的方法,是否存在用于这些语言的NoSql数据库中代码优先模式迁移的现有工具？或NoSql生态系统没有到那个成熟点？

如果您不同意MongoDB的建议,那么什么是更好的实现,您能否提供一些参考/示例,说明我在哪里可以看到正在使用的实现？

我是 Cosmos Db 的新手，想了解如何删除/更新文档集合中的子文档。

如果我有一个文件：

{ "Id": "1234", "Name": "foo", "Items": [ { "Id": "abcd", "Age": 35, "Claims": [ { "Name": "email", "Value": "foo@bar.com" } ] } ] }

我如何能：

1）在文档的Items列表中添加一个项目。

2) 从 Items 列表中删除现有的 Item

3) 将项目 upsert 到文档中的项目列表

4) 向项目列表中的现有项目添加/删除索赔值？

提前致谢。

我有一个Azure Cosmos数据库,我需要删除此订阅中的所有资源.有没有办法从门户网站下线备份？

使用 Cosmos DB for MongoDB API（版本 3.4），以下查找查询与方法游标排序的组合似乎行为不正确：

db.test.find({"field1": "value1"}).sort({"field2": 1})

如果满足以下所有条件，则会发生错误：

• 默认索引策略被丢弃 - 无论之后是否使用 createIndex() 创建了自定义索引。
• find() 查询不返回任何文档（Find(filter).Count() == 0）
• 定义排序顺序的排序文档仅包含一个字段。这个字段是否存在或已被索引并不重要。在排序文档中使用两个字段会返回 0 个命中，这是正确的行为。

如果满足以下所有条件，也会发生错误：

• 默认索引策略被丢弃
• find() 查询返回一个或多个文档
• Sort 文档只包含一个字段。此字段尚未编入索引。

错误信息：

排除指定 order-by 项对应的索引路径。

该故障仅在使用 CosmosDB 时发生，使用本机 MongoDB (mongoDB Atlas, v4.0) 时其行为正确。

使用具有 MongoDB 3.4 线路协议（预览功能）的 Azure Cosmos DB for MongoDB API。MongoDB C#/.NET 驱动程序和 mongo shell 都会出现此问题。

此外，该问题仅出现在 find() 中。包含 $match 和 $sort 的等效聚合管道行为正确。

再生产

1. 使用“Azure Cosmos DB for MongoDB API”创建 Azure Cosmos DB 帐户。启用 MongoDB 3.4 预览功能（3.2 版尚未测试）。
2. 创建一个新的数据库
3. 创建一个新的集合，定义一个分片键 …

如果转到https://portal.azure.com，打开我们的 Azure Cosmos DB 帐户 (1) --> 数据资源管理器 (2) --> 单击用户 (3) --> 单击新建 SQL 查询：

Azure 将打开一个文本框以输入查询：

我发现 Cosmos DB 不允许使用 DELETE 代替 SELECT: /sf/answers/3383744171/，所以我应该这样做：

SELECT * FROM c DELETE c
SELECT * FROM c DELETE *

但是我的任何尝试都奏效了。

我有一个 API (.NET Core 2.2)，它使用 SDK v3.5.0 从 Cosmos DB 检索文档。目前，由于对 Cosmos DB 的请求超时，一些请求会引发异常 - 响应是408 状态代码。值得一提的是，90% 的请求都被成功处理。

使用遥测记录 API 的活动，我注意到在依赖项表（记录对 Cosmos DB 的每个请求）中，持续时间超过 60 秒的请求是由名为“创建/查询文档”的命令发起的。这些是属于超时的请求。

另一方面，所有其他请求都使用“查询文档”命令，该命令在 < 5 秒内响应并且请求成功完成。为了分享更多上下文，我在下面详细说明了错误堆栈跟踪、一般规范以及我如何查询文档。

堆栈跟踪

    Microsoft.Azure.Cosmos.CosmosException : Response status code does not indicate success: 408 Substatus: 0 Reason: (Microsoft.Azure.Cosmos.CosmosException : Response status code does not indicate success: 408 Substatus: 0 Reason: (Microsoft.Azure.Documents.RequestTimeoutException: GatewayStoreClient Request Timeout. Start Time:1/30/2020 4:18:00 AM; Total Duration:00:01:05.0332130; Http Client Timeout:00:01:05; Activity id: 7498789a-8e09-4c3e-96a6-31c32e4dc2d7; Inner Message: The …