本页面介绍了在 Cloud Healthcare API 中存储大批量 FHIR 数据的选项。
导入 FHIR 资源
使用 fhirStores.import
方法将 FHIR 资源从 Cloud Storage 加载到 Cloud Healthcare API。在将数据加载到空 FHIR 存储区而不对其他应用造成干扰时,此方法的效果最佳。
如需调用 fhirStores.import
,请参阅使用 Cloud Storage 导入和导出 FHIR 资源。
在决定是否使用 fhirStores.import
方法时,请考虑以下属性。如果 fhirStores.import
不适合您的应用,请考虑使用 fhir.executeBundle
方法加载数据。如需了解如何调用 fhir.executeBundle
,请参阅使用 FHIR 包管理 FHIR 资源。
fhirStores.import
方法对 FHIR 资源资源没有限制。如果您的 FHIR 软件包超出了 50 MB 的大小上限,请使用fhirStores.import
而不是fhir.executeBundle
。使用
fhirStores.import
可避免执行大型 FHIR 包的复杂性,例如:- 将 FHIR 软件包分解为更小的软件包
- 管理多个软件包时间表
- 管理可在资源或软件包级别重试的暂时性错误
通常,这些优势大于使用软件包的优势。
输入中的每个资源都必须包含由客户端提供的 ID。不论 FHIR 存储区中的
enableUpdateCreate
设置如何,每个资源都使用所提供的 ID 进行存储。无论 FHIR 存储区上的
disableReferentialIntegrity
设置如何,导入过程都不会强制执行参照完整性。不强制执行参照完整性后,您可以导入具有任意依赖项的资源,而无需考虑分组或排序。如果输入数据包含无效参照,或者某些资源无法导入,则 FHIR 存储区的状态可能违反参照完整性。如果具有给定 ID 的资源已在存储区中,则该资源的最新版本会被覆盖,而不创建新的历史版本。不论 FHIR 存储区上的
disableResourceVersioning
设置如何,它都会被覆盖。如果导入期间发生暂时性故障,则成功导入的资源可能会被覆盖多次。除非输入数据包含多个 ID 相同但内容不同的有效资源,否则导入操作具有幂等性。在这种情况下,导入完成后,存储区中仅有一个包含每个 ID 的资源,但重复条目可以包含任何版本的内容。例如,如果导入具有相同 ID 的 100 万个资源,则只会在存储区中写入一个资源。
操作结果计数器不会将重复 ID 计为错误。输入中的每个资源都计为一次成功。这可能会导致成功计数大于 FHIR 存储区中的资源数量。在导入由
Patient-everything
生成的捆绑包中整理的数据时,通常会发生这种情况,其中每个捆绑包都包含其自己的资源副本(例如Practitioner
),该资源可能由许多患者资源引用。如果某些资源因解析错误等原因而无法导入,则系统不会回滚已成功导入的资源。例如,如果 100 项资源中有 5 项无法导入,其余 95 项资源将导入 FHIR 存储区。
使用
BUNDLE
格式时,导入方法会拒绝Bundle.type
为history
.的软件包。导入方法不会对批量或事务软件包应用软件包处理语义。与fhir.executeBundle
不同的是,事务软件包不会作为单个事务执行,且不会重写软件包内部引用。该软件包被视为Bundle.entry.resource
中提供的要被写入的资源集合,将忽略Bundle.entry.request
。例如,这可以让您导入由 FHIR 搜索或Patient-everything
操作生成的搜索集软件包。
使用 FHIR 软件包
如需简要了解 FHIR 软件包,请参阅 FHIR 软件包。
何时使用 FHIR 软件包
在决定是否使用 fhir.executeBundle
方法存储 FHIR 资源时,请考虑以下特征和优势:
- 如果费用过高(就结算费用或网络带宽而言),要构建流水线在 Cloud Storage 中存储数据,然后使用
fhirStores.import
导入数据,请使用fhir.executeBundle
。 - 执行捆绑包时,可以强制执行事务完整性。
- 执行捆绑包时,可以强制执行 FHIR 配置文件验证。
- 如果您需要在 FHIR 创建、更新或删除操作时发送 Pub/Sub 通知,请使用
fhir.executeBundle
。使用fhirStores.import
导入 FHIR 资源时,系统不会发送 Pub/Sub 通知。 - 如果必须处理特定 FHIR 资源的时间是以秒为单位或几分钟,请使用
fhir.executeBundle
。如果必须处理特定 FHIR 资源的时间是几小时或几天,请使用fhirStores.import
。 - 如果您的 Google Cloud 项目有许多现有的长时间运行的操作 (LRO) 执行其他任务,您可能会发现,使用
fhir.executeBundle
优于fhirStores.import
时性能更好。 如果管理
fhirStores.import
操作的应用没有针对以下各项的良好策略,请使用fhir.executeBundle
:- 处理批量错误
- 处理部分 FHIR 资源或整个批次的故障
何时不使用 FHIR 软件包
在确定是否使用 fhir.executeBundle
存储 FHIR 资源时,请考虑以下限制:
捆绑包采用相同的配额和结算方式,就像在捆绑包内部执行的操作一样。例如,如果某个捆绑包中有 10 个
POST
操作、5 个GET
操作和 1 个DELETE
操作,则捆绑包的配额和结算方式与这些操作是单独执行的。因此,旨在降低配额限制和 FHIR 操作费用并不是使用软件包而不是
fhirStores.import
的理由。大型事务捆绑包更有可能出现事务冲突,导致数据争用和失败的操作。如需了解这些问题发生的原因以及如何解决这些问题,请参阅防止
429 Resource Exhausted operation_too_costly
错误。您可以使用批量捆绑包来实现和维护高数据吞吐量,从而帮助您避免数据争用。但是,批量捆绑包不具备事务一致性功能(例如引用完整性)
如果捆绑包较大,即使它是批量捆绑包,您也可能会看到数据吞吐量降低。如需了解详情,请参阅避免大型事务包。