虽然有一些方法可以完成，但没有简单或标准的方法可以将XBRL文件拆分成较小的部分。您可以将事实批次复制到单独的文件中，但是这样做时，需要确保您还复制了事实的引用上下文和单元定义。由于上下文和单元可能会在引用它们的事实之前或之后出现，因此这变得棘手，因此您可能需要在多个流解析中进行操作。

如果您自己生成数据，建议您查看xBRL-CSV。这是一个新规范，适用于以更紧凑的形式表示大型的，基于记录的XBRL数据集。我相信Arelle对此有初步支持。

首先让我从数据库角度（与XBRL无关）给出一般性评论。

处理大量数据时，在数据管理中通常会确实将输入拆分为位于同一目录中的多个较小文件（每个文件最多100 MB）。这通常是针对大型数据集执行的，文件名在同一目录中带有递增的整数。这样做有实际原因，这使得将数据集复制到其他位置变得更加容易。

但是，我不确定是否存在以这种方式拆分XBRL实例的公共标准（即使对于引擎开发人员而言，这样做相对容易实现和实现：只需对事实进行分区并写入一个分区即可每个文件在传递闭包中仅包含上下文和单位-这实际上是对完成方式的标准化）。

但是，对于流友好的查询（例如过滤，投影，计数，转换为），通常仍然可以使用有限的内存（例如16GB甚至更少）来读取非常大的文件（50 GB以及更多）。其他格式，等等。

就XBRL而言，诀窍在于构建文件的方式使其可以以流方式读取，如pdw所述。我建议查看以下XBRL International的正式文档[1]，该文档现在是候选推荐，它说明了如何创建可以以流方式读取的XBRL实例：

[1] https://specifications.xbrl.org/work-product-index-streaming-extensions-streaming-extensions-1.0.html

如果引擎支持这一点，则实例的大小没有理论限制，除了磁盘的容量以及查询在流过时查询需要在内存中保留多少中间数据（例如，将某个查询汇总到一个分组查询中，就需要跟踪其键和相关计数。与可以完成的操作相比，50GB相对较小。我仍然希望根据确切的用例，至少要花一两位数字的分钟数。

我不确定Arelle目前是否支持流媒体。今天，大多数XBRL处理器都会在内存中实现该实例，但是我希望那里会有一些XBRL处理器可以实现流扩展。

最后，我第二点建议减少输入的大小（例如使用CSV语法）可以同时提高速度和内存占用。 50G XBRL实例可能以正确的格式存储在少于50G的内存中，而表（CSV）是实现此目的的一种很好的方法。话虽这么说，但也要记住，磁盘上使用的语法不必与内存中的数据结构匹配，只要外部行为不变，任何引擎都可以自由设计它认为合适的方式。>