About databases
DataMiner supports multiple different system data storage architectures.
Each DataMiner System requires its own system data storage. This data storage serves as a repository for configuration data, historical parameter information, and alarm data.
| self-hosted | Skyline-hosted (SaaS) | all features available | scalable | easy installation | automatic backups | effortless maintenance | |
|---|---|---|---|---|---|---|---|
| Storage as a Service (STaaS) | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | |
| Dedicated clustered storage | ✔️ | ✔️ | ✔️ | ||||
| Storage per DMA without indexing | ✔️ | ||||||
| Storage per DMA with indexing | ✔️ | ✔️ |
With Storage as a Service (STaaS) on dataminer.services, you do not need to maintain the databases yourself, and all the scaling and complexity is taken care of for you.
If you prefer to host and manage the DataMiner storage yourself, you can configure a dedicated clustered storage setup, using a Cassandra-compatible database service and an indexing database (i.e. a Search Cluster).
Instead of a dedicated clustered storage setup, it is also possible to use storage per DMA (with Cassandra or MySQL), though this is not recommended. If you are still using a legacy setup with MySQL, we highly recommend migrating to Cassandra, as MySQL is no longer supported as of DataMiner 10.3. If you are using a setup with Cassandra, we also highly recommend adding an indexing database to make sure you have access to features such as DOM and SRM.
If you host the DataMiner storage yourself, you can also configure an additional offload database, for example to produce reports without interfering with the live DataMiner System. Additional databases can also be configured, for example for DataMiner Inventory & Asset Management.
Note
When the main database is offline, file offloads are used to store write/delete operations. You can configure a limit for the file size of these offloads in the file DBConfiguration.xml.