如何从Azure的数据副本湖加快宇宙DB

我使用Azure的数据工厂从Azure的数据存储湖的数据复制到宇宙DB的集合。我们将在数据湖中有几千个JSON文件，每个JSON文件都是大约。 3 GB。我正在使用数据工厂的复制活动，并且在初始运行时，使用默认设置将一个文件加载到集群设置为10000 RU/s和数据工厂需要3.5小时。现在我已经将它扩展到50000 RU/s，将cloudDataMovementUnits设置为32，并将writeBatchSize设置为10以查看它是否提高了速度，并且同一文件现在需要2.5小时才能加载。加载成千上万个文件的时间仍将长久存在。如何从Azure的数据副本湖加快宇宙DB

有没有办法以更好的方式做到这一点？

来源

2017-08-09 Magnus Johannesson

你是说你试图将单个文档加载到大小为GB的Cosmos中？宇宙中文件的最大尺寸是2MB –

不，如果我不清楚，对不起。每个文件都包含数百万个JSON文档。JSON文档包含位置数据，我们需要进行空间计算，这就是我们选择Cosmos DB的原因。 –

的底线是，试图复制数百万的JSON档案需要一定的时间。如果它是有组织的GB数据，你可以用更短的时间批量传输而不是数百万个不同的文件。

我不知道，如果你打算从数据湖经常转移这种类型的文件，但一个好的策略可以写专门做一个应用程序。使用Microsoft.Azure.DocumentDB客户端库，您可以轻松创建一个管理您的传输的C＃Web应用程序。

这样，您就可以自动这些转让，油门他们，安排它们，等你也可以托管在一个虚拟机或应用服务这个应用程序，从来没有真的要想一想。

来源

2017-08-11 18:44:36

我们计划进一步对这些数据进行计划，日常加载，但是我正在考虑使用数据工厂进行此操作。实施它的应用程序似乎更复杂，并需要更多的维护。与数据工厂相比有什么优势？ –

我会说数据工厂是一个不错的选择。为自定义应用提供类似的灵活性。但是，我试图做的主要观点是，这不是一个你想要做的小事，它应该被正确地设计和思考。 –

你说你要插入的3Gb每批处理文件JSON文件的“百千万”。当问这种类型的问题时，这种精确度的缺失是没有帮助的。

让我们运行每个文件1000万个文档的数字。

该表示每JSON文档，这意味着相当多的每文档字段的索引在每个CosmosDb插入件300个字节。
如果每个插入成本为10 RU，那么在您的预算10,000 RU每秒插入速率为1000 x 3600（每小时秒数）=每小时插入360万个插件。
所以你3.5小时的观察中插入代表假设千万的文档数据的3 Gb是您购买的CosmosDb吞吐量高度一致。

本文https://docs.microsoft.com/en-us/azure/data-factory/data-factory-copy-activity-performance说明了DataLake到CosmosDb云水槽执行相对于其他选项不佳。我想这种糟糕的表现可以归因于CosmosDb的默认索引 - 所有政策。

你的应用程序是否需要一切索引？在执行批量插入操作时，CommosDb Cloud Sink是否使用较不严格的最终一致性？

你问，有没有更好的办法？链接的MS文档中的性能表显示Data Lake到Polybase Azure数据仓库的性能高出20,000倍。

最后一个想法。第二个测试增加的并发性是否会触发CosmosDb限制？ MS性能文档警告有关监视这些事件。

来源

2017-08-12 11:14:10 camelCase

每个文件中有5-10百万个文件，所以你的估计是相当不错的。我试过减少索引量，但没有得到任何性能改进，所以我不认为Cosmos DB是瓶颈。我们也在使用最终的一致性。不，我在增加并发时没有看到任何限制。 –

@Magnus：一个有趣的更新。你没有提到关键分区，尽管你在第二个测试时以50,00 RU表示你已经声明了一个分区键。 10k和50k RU之间的有限性能增益会让我质疑您的分区键值在您的源数据文件中是如何均匀分散的？我们可以从其他CosmosDb设置限制中推断10k RU是每个物理分区的合理最大查询吞吐量，因此如果您的输入数据在分区密钥上排序不佳，则可能会使单个物理分区最大化。 – camelCase

但是，如果我正在最大化一个分区，不应该看到一些限制吗？我不。我使用的分区键具有6000个不同的值，数据应该均匀分布在这些键值上。 –

如何从Azure的数据副本湖加快宇宙DB

回答

相关问题