首页 文章

将数据湖中的18GB csv文件复制到DocumentDB后，它在DocumentDB中显示100 GB为什么？

提问于
浏览 次
0

我使用azure数据工厂的复制活动将大约18 GB的csv文件从data lake store复制到documentDB . 它共有1个月的数据 . 我使用ADF的复制活动一次复制了5天的数据 . 加载25天数据后，我收到错误“超出'文档'的存储配额 . ”我可以看到，在documentDB中，它显示该集合的大小为100GB . 我没有得到DocumentDB中18GB数据如何变为100GB . 我在DocumentDB中有分区键和默认索引策略 . 我知道因为索引它会增加一点点的大小 . 但我并没有期待这么多 . 我不确定我在这里做错了什么 . 我对documentDB没有多少经验，在搜索这个问题时，我没有得到任何答案，所以在这里发布这个问题 .

我尝试将另一个1.8 GB的小数据从数据湖存储复制到另一个集合中的文档数据库 . 它显示了documentDB中大约14 GB的大小 .

所以这意味着documentdb拥有的数据多于实际数据 . 请帮助理解为什么它在documentdb中的大小比数据湖存储中的实际大小多5到7倍 .

csv azure azure-data-factory azure-data-lake azure-cosmosdb

2 回答

  • -1

    根据我的经验，索引占用了空间，但这个问题的主要原因是数据以 json 的形式存储在documentdb中 .

    {
    "color": "white",
    "name": "orange",
    "count": 1,
    "id": "fruit1",
    "arr":[1,2,3,4],
    "_rid": "F0APAPzLigUBAAAAAAAAAA==",
    "_self": "dbs/F0APAA==/colls/F0APAPzLigU=/docs/F0APAPzLigUBAAAAAAAAAA==/",
    "_etag": "\"06001f2f-0000-0000-0000-5989c6da0000\"",
    "_attachments": "attachments/",
    "_ts": 1502201562
}

    如果您观察到json数据，您会发现它们都是 key-values ，因为json架构较少 . 占用空间需要这些键值（每个字母1个字节） .

    JSON还会生成非常人类可读的字符，例如 [ ] ,{ }, : 等 . 这些特殊字符也占用空间 .

    另外，documentdb会生成System属性占用空间，例如_rid，_self，_etag，_ts . 你可以参考official document .

    如果可能，更短的键可以有效地节省空间，比如使用n1而不是name1 .

    希望它能帮到你 .

    回复于
  • 1

    这是一个常见的“问题”，具有分层的自描述格式，如XML，JSON，YAML等 .

    首先，如果您采用具有固定架构的“关系格式”或没有元数据的格式（如CSV）并用JSON表示，您现在将架构信息分解为Jay解释的每个键/值属性 .

    此外，如果您随后存储该文档，通常用于存储它的所谓文档对象模型将原始文本大小爆炸2到10倍（取决于键的长度，文档的复杂性等） .

    因此，建议除非您确实需要XML，JSON等提供的半结构化格式，否则您应该考虑将存储恢复为结构化格式（如表格） .

    回复于

相关问题