我使用 azure 数据工厂的复制活动将大约 18 GB csv 文件从数据湖存储复制到 documentDB。其总共1个月的数据。我使用 ADF 的复制活动一次复制了 5 天的数据。加载 25 天数据后，出现错误"超出'文档'的存储配额"。我可以看到在 documentDB 中它显示该集合的大小为 100GB。我不明白 18GB 数据如何在 DocumentDB 中变成 100GB。我在 DocumentDB 中有分区键和默认索引策略。我知道由于索引，它会稍微增加大小。但我没想到这么多。 我不确定我在这里是否做错了什么。我对documentDB没有太多经验，在搜索这个问题时，我没有得到任何答案，所以在这里发布这个问题。
我尝试将另一个 1.8 GB 的小数据从数据湖存储复制到另一个集合中的文档数据库。它显示了 documentDB 中大约 14 GB 的大小。
所以这意味着 documentdb 的数据比实际数据多。请帮助理解为什么它在 documentdb 中显示的大小几乎是数据湖存储中实际大小的 5 到 7 倍。
根据我的经验，索引占用空间，但此问题的主要原因是数据以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数据，你会发现它们都是键值，因为json没有模式。需要这些键值来占用空间(每个字母 1 个字节(。
JSON还会生成非常人类可读的字符，例如[ ] ，{ }，：等。这些特殊字符也占据了空间。
此外，documentdb 会生成占用空间的系统属性，例如 _rid，_self，_etag，_ts。您可以参考官方文件。
如果可能的话，较短的键可以有效地节省空间，例如使用 n1 而不是 name1。
希望对您有所帮助。
这是分层的自描述格式(如XML，JSON，YAML等(的常见"问题"。
首先，如果您采用具有固定架构的"关系格式"或没有元数据(如 CSV(的格式并以 JSON 表示它，您现在将架构信息分解为每个键/值属性，如 Jay 解释的那样。
此外，如果随后存储该文档，则用于存储该文档的所谓文档对象模型通常会将原始文本大小爆炸 2 到 10 倍(取决于键的长度、文档的复杂性等(。
因此，建议是，除非您确实需要XML，JSON等提供的半结构化格式，否则应考虑将存储恢复为结构化格式，例如表。