Smile CDR v2024.08.PRE
On this page:

7.6.1MegaScale
Trial

 
MegaScale is a new feature. It has a number of limitations and will not be suitable for many use cases. See Limitations below.

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.

7.6.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.

MegaScale Architecture

7.6.3Limitations
Trial

 

This section lists the known limitations on this feature.

7.6.3.1Partition Styles

7.6.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.

7.6.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.

7.6.3.4Cross-Partition Searching

Search requests will only include results from a single database.

7.6.3.5Cross-Partition References

If Cross-Partition References are enabled, it will be possible to create references that cross partition and database boundaries. In a MegaScale-enabled repository, these references rely on a soft-reference that is stored in the source partition that redirects the server to the target partition.

These references may be used for _include processing, but do not support chained searches or _revinclude processing.

7.6.4Configuration
Trial

 

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

On the FHIR Storage (RDBMS) module:

On the FHIR Endpoint module:

7.6.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.