Cloud Healthcare API FHIR 搜索实现具有出色的扩缩能力和性能，同时仍遵循 REST 的准则和限制以及 FHIR 规范。为了帮助实现这一点，FHIR 搜索具有以下属性：
搜索总量是返回最后一页之前的估算值。
fhir.search方法返回的搜索结果包括搜索总数（Bundle.total属性），即搜索中的匹配项总数。总搜索次数为返回搜索结果最后一页之前的估算值。随搜索结果的最后一页返回的搜索总数是该搜索中所有匹配项的准确总和。搜索结果提供有向前分页的功能。如果有更多要返回的搜索结果，响应将包含用于获取下一页结果的分页网址 (
Bundle.link.url)。
基本用例
FHIR 搜索为以下用例提供了解决方案：
如需了解这些用例的可能解决方案，请参阅以下部分。
依序浏览
您可以构建一个低延迟应用，可让用户按顺序浏览结果页面，直到找到所需的匹配项。如果匹配项的数量足够小，用户可以逐页浏览所需匹配项，该解决方案可行。如果您的用例需要用户一次向前导航或向后导航，请参阅导航到附近的页面。
此解决方案无法提供准确的搜索总数，直到返回最后一页结果为止。但是，它可以提供每个结果页面的大致搜索总量。虽然后台进程可能需要准确的搜索总量，但一般的搜索总量通常足以满足人类用户的需求。
工作流
以下是此解决方案的示例工作流：
应用调用
fhir.search方法，该方法会返回搜索结果的第一页。如果有更多结果要返回，响应中就会包含分页网址 (Bundle.link.url)。响应还包含搜索总计 (Bundle.total)。如果要返回的结果数超过初始响应数，则搜索总计只是一个估算值。 如需了解详情，请参阅分页和排序。该应用会显示搜索结果页面、下一页搜索结果（如果有）以及搜索总数。
如果用户想要看到下一页结果，可以点击链接，这样就会调用分页网址。如果要返回更多结果，则响应中会包含新的分页网址。响应中还包含搜索总计。如果要返回更多结果，这是更新后的估算值。
该应用会显示新的搜索结果页面、下一页搜索结果（如果有）的链接，以及总搜索次数。
系统会重复执行前两个步骤，直到用户停止搜索或返回最后一页结果。
最佳实践
选择合适的页面大小，以供用户轻松阅读。根据您的使用场景，每页可包含 10 到 20 个匹配项。页面越短，加载速度越快，页面上的链接过多可能让用户难以管理。您可以使用 _count 参数控制页面大小。
处理一组搜索结果
您可以使用分页网址连续调用 fhir.search 方法来获取一组搜索结果。如果搜索结果数量足够少，您可以继续操作，直到没有要返回的页面为止，从而获得一整套结果。准确的搜索结果总数会包含在最后一页结果中。获取搜索结果后，您的应用可以读取这些结果并执行所需的任何处理、分析或聚合。
请注意，如果您有大量的搜索结果，可能无法在实际的时间内获取最后一页搜索结果（以及准确的搜索总计）。
工作流
以下是此解决方案的示例工作流：
应用会调用
fhir.search方法，该方法会返回搜索结果的第一页。如果有更多结果要返回，响应中就会包含分页网址 (Bundle.link.url)。如果要返回更多结果，应用会调用上一步中的分页网址，转到下一页搜索结果。
应用重复执行上一步，直到没有要返回的结果或达到了其他预定义的限制。如果您到达搜索结果的最后一页，则搜索总数是准确的。
应用会处理搜索结果。
应用可以执行以下操作：
- 请等待系统收到所有搜索结果，然后再处理数据。
- 处理每次连续调用
fhir.search时收到的数据。 - 设置某种限制，例如返回的匹配项数量或经过的时间量。达到上限后，您可以处理数据，但无法处理数据，也无法执行其他操作。
设计选项
以下是一些可能会缩短搜索延迟时间的设计选项：
设置较大的页面。根据您的用例，使用
_count参数设置较大的网页大小（例如 500 到 1000）。使用较大的网页会增加每次网页提取的延迟时间，但可能会加快整体抓取过程，因为需要进行的网页抓取会减少，以获取整个搜索结果集的过程。限制搜索结果。如果您只需要准确的搜索总数（不需要返回资源内容），请将
fhir.search方法的_elements参数设置为identifier。与请求返回完整 FHIR 资源相比，这可能会缩短搜索查询的延迟时间。如需了解详情，请参阅限制搜索结果中返回的字段。
需要预提取和缓存的用例
除了使用分页网址连续调用 fhir.search 方法这种简单机制之外，您可能还需要获得其他功能。一种可能的做法是，在您的应用与 FHIR 存储区之间构建一个缓存层，该层可以在预提取和缓存搜索结果的同时维护会话状态。
应用可以将搜索结果分组成 10 或 20 个匹配的小“应用页面”。然后，应用可以根据用户的选择，以直接、非连续的方式快速向用户提供这些小型应用页面。如需查看此类工作流的示例，请参阅导航到附近的页面。
转到附近的页面
您可以构建一个低延迟解决方案，使用户能够遍历大量搜索结果，直到找到要查找的内容。可以扩容到几乎无限的匹配项数量，同时保持较低的延迟，并导致资源消耗相对增加。用户可以直接导航到搜索结果的页面，最多可从当前页面向前或向后浏览一定数量的网页。您可以为每个结果页提供估算的总搜索次数。此设计与 Google 搜索的设计类似，仅供参考。
工作流
图 1 显示了此解决方案的示例工作流。通过这种工作流，每当用户选择要查看的结果页面时，该应用都会提供附近页面的链接。在这种情况下，应用提供从所选页面最多向后 5 页和从所选页面向前最多 4 页的链接。为使这四个正向网页可供查看，当用户选择某个结果页时，应用会预提取另外 40 个匹配项。
图 1. 应用将搜索结果分组为经过缓存并可供用户使用的“应用页面”。
图 1 展示了这些步骤：
用户在应用前端输入搜索查询，并启动以下操作：
应用调用
fhir.search方法来预提取搜索结果的第一页。_count参数设置为 100 可使响应的页面大小相对较小，从而使得响应速度相对较快。如果要返回更多结果，响应中会包含分页网址 (Bundle.link.url)。响应还包含搜索总计 (Bundle.total)。如果要返回更多结果，则搜索总计是一个估算值。如需了解详情，请参阅分页和排序。应用将响应发送到缓存层。
在缓存层中，应用将响应中的 100 个匹配归入 10 个应用页面，每个页面包含 10 个匹配项。应用页面是应用可以向用户显示的一小段匹配项。
应用会向用户显示应用页面 1。应用页面 1 包含应用页面 2-10 的链接以及估算的搜索总量。
用户点击指向其他应用页面（在此示例中为应用页面 10）的链接，并启动以下操作：
应用会使用之前预提取时返回的分页网址来调用
fhir.search方法，以便预提取下一页的搜索结果。将
_count参数设为 40 即可从用户的搜索查询中预取接下来的 40 个匹配项。40 个匹配项针对的是应用可供用户使用的接下来 4 个应用页面。应用将响应发送到缓存层。
在缓存层中，应用将响应中的 40 个匹配项组合成四个应用页面，每个 10 个匹配项。
应用会向用户显示应用页面 10。应用页面 10 包含指向应用页面 5-9（从应用页面 10 向后移植的五个应用页面）的链接以及指向应用页面 11-14（从应用页面 10 向前的四个应用页面）的链接。“应用”页面 10 中还包含估算的搜索总量。
只要用户想要继续点击指向应用页面的链接，就可以一直持续下去。请注意，如果用户从当前应用页面向后导航，并且您已经缓存了附近的所有应用页面，则可以根据您的用例选择不执行新的预提取。
此解决方案既快速又高效，原因如下：
- 预提取，甚至是较小的应用页面可以快速处理。
- 缓存的搜索结果可以减少对同一结果进行多次调用的需要。
- 无论搜索结果的数量如何扩缩，该机制都会保持快速。
设计选项
根据您的使用场景，您可以考虑以下设计选项：
应用页面大小。您的应用页面可以包含超过 10 个适合您用例的匹配项。请注意，较小的页面加载速度较快，而网页上的链接过多可能难以管理。
应用页面链接的数量。在此建议的工作流中，每个应用页面会返回 9 个指向其他应用页面的链接：5 个直接从当前应用页面向后指向应用页面的链接，4 个从当前应用页面直接指向的页面的链接。您可以根据自己的用例调整这些数字。
最佳做法
仅在必要时使用缓存层。如果您设置了缓存层，请仅在您的用例需要它时使用它。对于不需要缓存层的搜索，应该绕过它。
缩减缓存大小。为了节省资源，您可以清除旧搜索结果，同时保留用于获取结果的网页网址，从而缩减缓存大小。然后，您可以根据需要调用页面网址来重构缓存。请注意，多次调用同一分页网址的结果可能会随着时间的推移而发生变化，因为 FHIR 存储区中的资源会在后台创建、更新和删除。是否清除缓存、如何完全清除以及多久清除缓存一次，这取决于您的使用场景。
针对特定搜索完全清除缓存。为了节省资源，您可以从缓存中完全移除非活跃搜索的结果。建议您先将非活跃状态时间最长的搜索内容移除。请注意，如果完全清除的搜索重新生效，则可能会导致错误状态迫使缓存层重新开始搜索。
转到任意页面
如果您希望用户能够转到搜索结果中的任意网页，而不仅仅是当前网页附近的网页，则可以使用与导航到附近的网页中所述的缓存层类似的缓存层。不过，如需允许用户导航到搜索结果的任何应用页面，您需要预取和缓存所有搜索结果。如果搜索结果数量相对较少，这是可以实现的。如果搜索结果中数量过多，不切实际或无法预提取所有结果。即使搜索结果数量不多，预取这些结果所花费的时间也可能比用户预期等待的时间合理。
工作流
设置与导航到附近的页面类似的工作流，但具有以下关键区别：应用会继续在后台预提取搜索结果，直到返回所有匹配项或达到其他某个预定义的限制。
以下是此解决方案的示例工作流：
应用调用
fhir.search方法，从用户的搜索查询中预提取搜索结果的第一页。如果有更多结果要返回，响应中就会包含分页网址 (Bundle.link.url)。响应中还包含搜索总量 (Bundle.total)。如需返回更多结果，这是一个估算值。应用将来自响应的匹配项分成 20 个匹配的应用页面，并将其存储在缓存中。应用页面是应用可以向用户显示的一小段匹配项。
应用会向用户显示第一个应用页面。应用页面包含指向缓存应用页面和估计的搜索总数的链接。
如果需要返回更多结果，应用会执行以下操作：
- 调用从上一个预提取返回的分页网址，以获取下一页搜索结果。
- 将响应中的匹配项分组成每个应用 20 个匹配的页面，并将其存储在缓存中。
- 使用新预提取和缓存的应用页面的新链接刷新用户当前查看的应用页面。
应用重复执行上一步，直到没有要返回的结果或达到了其他预定义的限制。系统会返回准确的搜索结果，并将其显示在搜索结果的最后一页。
当应用在后台预取和缓存匹配内容时，用户可以继续点击指向缓存页面的链接。
设计选项
根据您的使用场景，您可以考虑以下设计选项：
应用页面大小。您的应用页面如果包含适合您用例的匹配项，则包含的匹配项数量不得超过 20 个。请注意，较小的页面加载速度较快，而网页上的链接可能过多，导致用户难以管理。
刷新搜索总计。当您的应用在后台预提取搜索结果并缓存搜索结果时，您可以循序渐进地向用户显示更准确的搜索总数。为此，请将您的应用配置为执行以下操作：
根据设定的时间间隔，从缓存层中的最新预提取数据中获取搜索总数（
Bundle.total属性）。这是目前搜索总值的最佳估算值。向用户显示搜索总量，表明这是估算值。根据您的用例确定此刷新的频率。识别缓存层中的搜索总数何时准确。也就是说，搜索总量来自搜索结果的最后一页。在到达搜索结果的最后一页时，应用会显示搜索总计，并向用户表明搜索总计准确无误。然后，应用将不再从缓存层获取搜索总计。
请注意，如果存在大量匹配，后台预提取和缓存可能无法在用户完成搜索会话之前到达搜索结果的最后一页（以及准确的搜索总数）。
最佳做法
删除所含资源中的重复数据。如果您在预提取和缓存搜索结果时使用了
_include和_revinclude参数，建议您在每次预提取后对缓存中包含的资源进行去重。这样可以减少缓存大小，从而节省内存。 将匹配结果归入不同的应用页面时，请向每个应用页面添加适当的资源。如需了解详情，请参阅在搜索结果中包含其他资源。为预提取和缓存设置限制。如果搜索结果中数量过多，不切实际或无法预提取所有结果。我们建议您为要预提取的搜索结果数量设置限制。这样可以将您的缓存保持在可控的范围内，并且有助于节省内存。例如，您可以将缓存大小限制为 10000 或 20000 个匹配项。或者，您可以限制要预提取的页面数量，或设置在达到预提取限额后的时间限制。施加的限制类型和实施方式取决于您的设计决策。如果在返回所有搜索结果之前已达到上限，请考虑向用户说明这一点，包括计算搜索总数仍然是一个估算值。
前端缓存
应用前端（例如网络浏览器或移动应用）可以提供某种缓存的搜索结果，作为在架构中引入缓存层的替代方案。此方法可通过利用 AJAX 调用并存储搜索结果和/或分页网址，提供导航到上一页或导航历史记录中任何页面的导航。此方法具有以下优势：
- 与缓存层相比，它可以节省大量资源。
- 可伸缩性更高，因为它可以在许多客户端上分配缓存工作。
- 可以更轻松地确定何时不再需要缓存资源，例如，当用户关闭标签页或离开搜索界面时。
一般最佳实践
以下是适用于本文档中所有解决方案的最佳实践。
针对小于 _count 值的网页进行规划。在某些情况下，搜索内容可能会返回包含的匹配数少于您指定的
_count的网页。例如，如果您指定的页面大小特别大，可能会出现这种情况。如果搜索返回的页面小于_count值，并且您的应用使用缓存层，您可能需要确定：(1) 在应用页面上显示的结果比预期少，或者 (2) 再提取一些结果以获得完整的应用页面。如需了解详情，请参阅分页和排序。重试可重试的 HTTP 请求错误。您的应用应该知道可重试的 HTTP 请求错误（例如
429或500），并在收到这些错误后重试。
评估您的使用场景
实现导航到任何页面、获取准确的搜索总数和更新估计的总数等功能会增加应用的复杂性和开发成本。这些功能还会增加延迟时间并增加使用 Google Cloud 资源的货币费用。我们建议您仔细评估您的用例，确保这些功能的价值是合理的。您需要考虑以下事项：
前往任意页面。用户通常不需要导航到特定网页（即当前网页的许多网页）。在大多数情况下，导航到附近的页面就足够了。
准确的搜索总数。随着创建、更新和删除 FHIR 存储区中的资源，搜索总计可能会发生变化。因此，在返回时（即在搜索结果的最后一页），准确的搜索总数是准确的，但随着时间的推移，它可能会变得不再准确。因此，对于您的应用而言，准确的搜索总计值可能有限。