• Database Administration
  • 41.0 Database Design
  • 41.1 Database Connection Pool
  • 41.2 Setting Up PostgreSQL
  • 41.3 Troubleshooting PostgreSQL
  • 41.4 Setting Up MySQL
  • 41.5 Setting Up MariaDB
  • 41.6 Setting Up Oracle
  • 41.7 Setting Up SQL Server (MSSQL)
  • 41.8 AWS IAM Authentication
    • 41.1    Database Connection Pool   
       Table of Contents

    Database Design

    41.0.1Database Design

     

    Smile CDR typically uses two separate databases (i.e. sets of tables) in order to operate. These databases are outlined below. Conceptually these are separate sets of tables with different purposes.

    In a simple installation it is possible for all tables to exist in a single database schema, which will simplify deployment. However, unless you know that your requirements will remain small, it is recommended to create separate database schemas for each set of tables.

    41.0.2Cluster Manager Database

     

    This database is required in order for Smile CDR to operate. A single instance of this database must be shared by all nodes in a cluster. This database is used to store:

    • Node and module configuration for all nodes and modules across the cluster.
    • Runtime metrics about usage and health of various nodes across the cluster.
    • User accounts, including salted-hashed passwords if the Local Inbound Security module is being used. If other security mechanisms such as an external Active Directory are being used then a placeholder entry is still created in the cluster manager database in order to link transactions, audit records, etc. together.
    • Transaction logs stored by the system.
    • Audit logs stored by the system.

    41.0.3FHIR Relational Storage

     

    This database is used to store FHIR resource contents. A typical installation will have one instance of this database, which is shared across all nodes in the cluster. In such a configuration, FHIR clients accessing Smile CDR will see a single endpoint with a single pool of resources.

    However, depending on your specific requirements, you may want to have multiple separate and distinct pools of resources. If this is required, you may want to create multiple FHIR Relational Storage databases – and multiple FHIR Storage (Relational) modules pointing to them.

    See JPA Server Schema for details on the database schema used by the FHIR Storage (RDBMS) module.

    41.0.4FHIR MongoDB (Non-Relational) Storage

     

    This database is used to store FHIR resource contents. A typical installation will have one instance of this database with a collection for each type of resource and a corresponding collection for each resource type's history. This instance is shared across all nodes in the cluster. In such a configuration, FHIR clients accessing Smile CDR will see a single endpoint with a single pool of resources.

  • Database Administration
  • 41.0 Database Design
  • 41.1 Database Connection Pool
  • 41.2 Setting Up PostgreSQL
  • 41.3 Troubleshooting PostgreSQL
  • 41.4 Setting Up MySQL
  • 41.5 Setting Up MariaDB
  • 41.6 Setting Up Oracle
  • 41.7 Setting Up SQL Server (MSSQL)
  • 41.8 AWS IAM Authentication
    • 41.1    Database Connection Pool