Storage Concept

Data in AspenTech Inmation is stored in MongoDB based Data Stores. All persisted data, even the AspenTech Inmation log, is archived in a similar and standard MongoDB document database.

MongoDB Primer

MongoDB is a source-available, NoSQL database that provides support for JSON-styled, document-oriented storage systems. NoSQL (Not only SQL) databases are non tabular, and store data differently than relational tables. That being said, it isn’t a huge obstacle to move from SQL thinking to NoSQL.

Table 1. Simplified SQL to NOSQL Comparison
SQL/RDBMS MongoDB

Database

Database

Tables

Collections

Rows

Documents

Columns

Fields

Data Store Concept

Quite simply a AspenTech Inmation Data Store is a unique MongoDB database and collection (aka a collection of documents). Different Data Store types exist to accommodate different data types.

Each Data Store (or MongoDB database) may exist on it’s own MongoDB Instance or more likely exist beside other AspenTech Inmation Data Stores on a given MongoDB instance. Note: Implementation of Security, Authentication, &/or a Replica Set is done at the MongoDB instance level. see MongoDB Deployment

System Data Stores

System Data Stores exist at the System level. AspenTech Inmation is completely Object Oriented and the highest level parent object is the System object. These Data Stores may be configured to some extent, but generally speaking must always exist as part of the System. We may, for example, configure a non-standard database name.

Table 2. System Data Store Overview
System Data Store Data Type Default db Name

Time Series - Production

VQT

History

Time Series - Test

VQT

HistoryTest

Event

Event

Events

Logging

Log

Log

Production Tracking

Batch

ProductionTracking

Custom

n/a (schema-less)

<user defined>

File

File

Files

Audit Trail

Audit Trail

AuditTrail

Custom Data Stores

Custom Data Stores unlock a massive amount of flexibility for a AspenTech Inmation system designer or integrator. Using Custom Data Stores we may archive data from different objects into whatever MongoDB instances & databases we desire.

Table 3. Custom Data Store Overview
Custom Data Store Data Type Default Database Name

Custom Time Series

VQT

<user defined>

Custom Event

Event

<user defined>

Custom Production Tracking

Batch

<user defined>

Global GxPC Concept

The Global GxPC system structure relies on one large Global Master-Core system with many distributed Local-Core systems.

To store all data, that is generated by a large Master / Local-Core deployment, multiple MongoDB databases need to be used. Typically, each Core has at least one MongoDB instance that it can use to store data. Furthermore multiple custom datastores need to be used to store different types of data, and to scale the data appropriately between MongoDB instances of the Master- and Local-Cores. The built-in datastores of the System object play a less important role. See Custom Data Stores

For the GXPC platform, the standard for the MongoDB Deployment will be a PSS Replica Set.

Over time, the amount of data that is created by the global system (Master- and Local-Cores) will increase. Additional Replica Sets can be created, and custom datastores can be assigned to the new Replica Sets. This allows to follow a horizontal scaling strategy.