Smile CDR v2024.08.PRE
On this page:
   7.5    Chained Searching and Sorting
  • FHIR Storage (Relational)
  • 7.0 FHIR Storage (Relational) Module
  • 7.1 Resource Storage Mode
  • 7.2 Performance Tuning
  • 7.3 Lucene Indexing
  • 7.4 Performance and Caching
  • 7.5 Chained Searching and Sorting
  • 7.6 MegaScale
    •    Table of Contents

    MegaScale

    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
    • $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.

       7.5    Chained Searching and Sorting
  • FHIR Storage (Relational)
  • 7.0 FHIR Storage (Relational) Module
  • 7.1 Resource Storage Mode
  • 7.2 Performance Tuning
  • 7.3 Lucene Indexing
  • 7.4 Performance and Caching
  • 7.5 Chained Searching and Sorting
  • 7.6 MegaScale