如何从包含 5000 条记录的 Excel 文件插入到 documentDB?
How to insert into documentDB from Excel file containing 5000 records?
我有一个 Excel 文件,最初有大约 200 行,我能够将 excel 文件转换为数据 table 并且所有内容都正确插入了 documentdb .
Excel 文件现在有 5000 行,它在插入 30-40 条记录后没有插入,其余所有行都没有插入到 documentdb
我发现了一些异常,如下所示。
Microsoft.Azure.Documents.DocumentClientException: Exception:
Microsoft.Azure.Documents.RequestRateTooLargeException, message:
{"Errors":["Request rate is large"]}
我的代码是:
Service service = new Service();
foreach(data in exceldata) //exceldata contains set of rows
{
var student = new Student();
student.id= "";
student.name = data.name;
student.age = data.age;
student.class = data.class;
student.id = service.savetoDocumentDB(collectionLink,student); //collectionlink is a string stored in web.config
students.add(student);
}
Class Service
{
public async Task<string> AddDocument(string collectionLink, Student data)
{
this.DeserializePayload(data);
var result = await Client.CreateDocumentAsync(collectionLink, data);
return result.Resource.Id;
}
}
我做错了什么吗?
任何帮助将不胜感激。
更新:
截至 4/8/15,DocumentDB 发布了数据导入工具,支持 JSON 文件、MongoDB、SQL 服务器和 CSV 文件。您可以在这里找到它:http://www.microsoft.com/en-us/download/details.aspx?id=46436
在这种情况下,您可以将 Excel 文件保存为 CSV 文件,然后使用数据导入工具 bulk-import 记录。
原答案:
DocumentDB Collections 每秒配置 2,000 request-units。重要的是要注意 - 限制是根据 request-units 而不是请求来表示的;所以写大文档比写小文档花费更多,扫描比索引查找更昂贵。
您可以通过检查 x-ms-request-charge
HTTP 响应 header 或 ResourceResponse
中的 RequestCharge
属性 来测量任何操作的开销 (CRUD) /FeedResponse
objects SDK返回。
当您耗尽预配的吞吐量时,将抛出 RequestRateTooLargeException。一些解决方案包括:
- 稍作延迟后退,并在遇到异常时重试。建议的重试延迟包含在
x-ms-retry-after-ms
HTTP 响应 header 中。或者,您可以简单地以短暂的延迟批处理请求
- 使用惰性索引来加快摄取速度。 DocumentDB 允许您在 collection 级别指定索引策略。默认情况下,索引在每次写入 collection 时同步更新。这使查询能够遵守与文档读取相同的一致性级别,而不会延迟索引“赶上”。惰性索引可用于在较长时间内分摊索引内容所需的工作。但是需要注意的是,启用惰性索引后,无论为 DocumentDB 帐户配置的一致性级别如何,查询结果最终都会保持一致。
- 如前所述,每个 collection 有 2,000 RU 的限制 - 您可以通过跨多个 collection 和容量单元对数据进行分片/分区来提高吞吐量。
- 删除空 collections 以利用所有配置的吞吐量 - 在 DocumentDB 帐户中创建的每个文档 collection 都根据配置的容量单位 (CU) 的数量分配预留吞吐量容量,并且创建的 collection 数量。单个 CU 可提供 2,000 个请求单元 (RU),最多支持 3 collection。如果只为 CU 创建一个 collection,则整个 CU 吞吐量将可用于 collection。一旦创建了第二个 collection,第一个 collection 的吞吐量将减半并分配给第二个 collection,依此类推。为了最大化每个 collection 的可用吞吐量,我建议 collections 的容量单位数是 1:1.
参考文献:
我有一个 Excel 文件,最初有大约 200 行,我能够将 excel 文件转换为数据 table 并且所有内容都正确插入了 documentdb .
Excel 文件现在有 5000 行,它在插入 30-40 条记录后没有插入,其余所有行都没有插入到 documentdb
我发现了一些异常,如下所示。
Microsoft.Azure.Documents.DocumentClientException: Exception: Microsoft.Azure.Documents.RequestRateTooLargeException, message: {"Errors":["Request rate is large"]}
我的代码是:
Service service = new Service();
foreach(data in exceldata) //exceldata contains set of rows
{
var student = new Student();
student.id= "";
student.name = data.name;
student.age = data.age;
student.class = data.class;
student.id = service.savetoDocumentDB(collectionLink,student); //collectionlink is a string stored in web.config
students.add(student);
}
Class Service
{
public async Task<string> AddDocument(string collectionLink, Student data)
{
this.DeserializePayload(data);
var result = await Client.CreateDocumentAsync(collectionLink, data);
return result.Resource.Id;
}
}
我做错了什么吗? 任何帮助将不胜感激。
更新:
截至 4/8/15,DocumentDB 发布了数据导入工具,支持 JSON 文件、MongoDB、SQL 服务器和 CSV 文件。您可以在这里找到它:http://www.microsoft.com/en-us/download/details.aspx?id=46436
在这种情况下,您可以将 Excel 文件保存为 CSV 文件,然后使用数据导入工具 bulk-import 记录。
原答案:
DocumentDB Collections 每秒配置 2,000 request-units。重要的是要注意 - 限制是根据 request-units 而不是请求来表示的;所以写大文档比写小文档花费更多,扫描比索引查找更昂贵。
您可以通过检查 x-ms-request-charge
HTTP 响应 header 或 ResourceResponse
中的 RequestCharge
属性 来测量任何操作的开销 (CRUD) /FeedResponse
objects SDK返回。
当您耗尽预配的吞吐量时,将抛出 RequestRateTooLargeException。一些解决方案包括:
- 稍作延迟后退,并在遇到异常时重试。建议的重试延迟包含在
x-ms-retry-after-ms
HTTP 响应 header 中。或者,您可以简单地以短暂的延迟批处理请求 - 使用惰性索引来加快摄取速度。 DocumentDB 允许您在 collection 级别指定索引策略。默认情况下,索引在每次写入 collection 时同步更新。这使查询能够遵守与文档读取相同的一致性级别,而不会延迟索引“赶上”。惰性索引可用于在较长时间内分摊索引内容所需的工作。但是需要注意的是,启用惰性索引后,无论为 DocumentDB 帐户配置的一致性级别如何,查询结果最终都会保持一致。
- 如前所述,每个 collection 有 2,000 RU 的限制 - 您可以通过跨多个 collection 和容量单元对数据进行分片/分区来提高吞吐量。
- 删除空 collections 以利用所有配置的吞吐量 - 在 DocumentDB 帐户中创建的每个文档 collection 都根据配置的容量单位 (CU) 的数量分配预留吞吐量容量,并且创建的 collection 数量。单个 CU 可提供 2,000 个请求单元 (RU),最多支持 3 collection。如果只为 CU 创建一个 collection,则整个 CU 吞吐量将可用于 collection。一旦创建了第二个 collection,第一个 collection 的吞吐量将减半并分配给第二个 collection,依此类推。为了最大化每个 collection 的可用吞吐量,我建议 collections 的容量单位数是 1:1.
参考文献: