14.5.1MegaScale

Trial

MegaScale is a mechanism for storing virtually unlimited amounts of data in a single FHIR server. It uses multiple database instances to create discrete pools of data which are logically separate, but are managed under a single Smile CDR FHIR Storage (RDBMS) module.

In its simplest terms, a MegaScale-enabled server can be thought of as a multitenant repository where each tenant is hosted in a separate database instance.

Using this strategy can be helpful in cases such as:

• The total amount of data to be stored exceeds the natural limit of a single instance of the database technology being used
• Data needs to be kept physically separate due to privacy or legal rules.

14.5.2Architecture

Trial

In MegaScale mode, one or more FHIR Endpoint modules are combined with a single FHIR Storage (RDBMS) module. Incoming FHIR requests include a tenant identifier which maps to a particular partition, which then specifies the target database. This architecture is shown in the diagram below.

14.5.3Limitations

Trial

This section lists the known limitations on this feature.

14.5.3.1Partition Styles

• Only the Request Tenant (REQUEST_TENANT) mode may be used as a Request Partition Selection Mode.

14.5.3.2FHIR Interactions

The following FHIR interactions have been tested:

• Create/Update
• Search
• $reindex – It is possible to reindex a single partition by providing the tenant name in the URL (e.g. /P1/$reindex), or all partitions using _ALL as the tenant name (e.g. POST /_ALL/$reindex).
• $validate
• $expunge – Expunge everything is verified to work, and will only expunge everything for a single MegaScale database at a time.
• $delete-expunge – Delete expunge is verified to work, and will only delete and expunge for a single MegaScale database at a time.

No other features, operations, or interactions have been tested or are expected to work with MegaScale.

14.5.3.3Transaction Bundles

Processing Transaction Bundles that span multiple databases is NOT supported. You must ensure that all updates within a single Bundle target a single MegaScale database. This is true for REQUEST_TENANT partitioning mode, but may not be true for other partition modes like Patient-Id partitioning or custom partitioning solutions.

14.5.3.4Cross-Partition Searching

Search requests will only include results from a single database.

14.5.4Configuration

Trial

To enable MegaScale mode, the following settings must be set.

On the FHIR Storage (RDBMS) module:

• Partitioning Enabled must be set to true.
• Configure Database connection details
  • These will be the connection details for the DEFAULT partition.
• At least one partition must be created. See Seeding Partitions.
• Partition Selection Mode must be set to either REQUEST_TENANT or REQUEST_HEADER.
• MegaScale Enabled must be set to true.
• A Connection Provider Interceptor must be set (see below).

On the FHIR Endpoint module:

• If using REQUEST_TENANT partition selection mode, Tenant Identification Strategy must be set to URL_BASED.

14.5.5Connection Provider Interceptor

Trial

MegaScale connection details are supplied using a Java Smile CDR Interceptor using the STORAGE_MEGASCALE_PROVIDE_DB_INFO pointcut.

See Example: MegaScale Connection Provider to see how this pointcut can be used. This example is also available in the Interceptor Starter Project.