RavenDB 文档建模--琐碎的注意事项--处理无限增长的文档

使用 RavenDB 进行数据建模的一个重大挑战是数据不同的特征和行为会对各种操作成本产生不同的影响，这又反过来影响我们设计和使用模型的方式。从这篇文章开始我将通过4到6篇文章来讲解 RavenDB 文档建模琐碎的注意事项。

处理无限增长的文档

多大的文档才能被成为大文档？多小的文档才能被称为小文档？不同的 NoSQL 数据库给出的答案是不一样的，但是一般来说良好的文档大小范围应该在千字节左右。在 RavenDB 对文档的大小限制是有硬性规定的，不超过2GB，不要觉得着2GB不够用，RavenDB会对 JSON 文档进行压缩处理，因此如果你存储的数据大小在 2GB的话，经过 RavenDB 压缩后所占的空间会非常非常的小。这还只是一个文档的最大的大小，如果我们的业务需要几十个上百个文档呢？因此我们完全不需要担心 RavenDB 无法支持我们的业务数据需求，即使无法支持，你可别忘了 RavenDB 是一个完全兼容分布式，多集群部署的NoSQL数据库。
虽然说 RavenDB 对存储大型文档来说有着天生的优势，但是我们也要考虑一下成本问题，首先我们通过网络读取文档时可能出现传输速度很慢的情况（文档很大），即使我们读取到了文档，因为 RavenDB 的文档都是经过压缩的，我们该如何将压缩后的JSON解析到我们的实体中呢（解析占用的内存必然会比压缩后的JSON占用的内存高）？其次，假如文档很大，那么我们如何才能将数据展示在网页中呢？在使用完这些数据后我们该如何让GC回收它呢？这些都是我们需要考虑的问题。
以下是开发人员在实际开发中总价的方法：只要以千字节为单位衡量文档大小是有意义的，就可以了。RavenDB 在遇到过大的文档时会在 Studio 中生成警告，但对系统的行为和性能没有任何影响。
出现大文档常见的原因有两个：

1. 包含多个非常到大的字段：
   这种原因一般会出现在二进制数据和大文件的情况下。对于这种情况我们要考虑这些大量的数据是否必须存储在文档中，是否可以独立成一个外部文档，我们可以使用 RavenDB 提供的附件功能，将这些超大的数据/文件作为附件附加到文档中。

TIP：RavenDB 附近是没有大小限制的，在加载文档时我们无法访问。

2. 包含大小不受限制的集合：
   这种原因经常出现在文档必须包含大量数据字段的情况，一般我们会采用将文档按照业务拆分为多个小文档来解决这个问题，在使用时将这些小文档再合并成一个大文档。例如在订单系统中，不可能在页面上展示所有的订单，我们会根据年或月来拆分订单（比如某东的订单页面），这样我们就得到了如下文档：

文档	说明
order/zhangsan	用户zhangsan全部订单简略信息
order/zhangsan/202101	用户zhangsan2021年1月的订单
order/zhangsan/202102	用户zhangsan2021年2月的订单

这么拆分订单后，我们可以快速查询某人某段时间的订单的所有信息。当然这种方式是以时间为基础来进行拆分的，如果文档无法用时间来拆分该怎么办呢？那么，我们可以自定义拆分规则，还以订单文档为例，将订单拆按照100的倍数拆分，就会行程如下的文档：

文档	说明
order/zhangsan	用户zhangsan全部订单简略信息
order/zhangsan/1	用户zhangsan 第1个到第100个订单
order/zhangsan/2	用户zhangsan 第101个到第200个订单

这两种方法我们都可以使用 ​ Include ​ 将某用户的部分订单查询出来。