You may already have noticed that we have given the documentation on the various supported databases a complete makeover. But we’re not done yet! We’re continuously working on enhancing this, to make the documentation as thorough as possible. In this blog post, we want to provide you with a clear overview of the new structure of the databases documentation, enabling you to effortlessly navigate the DataMiner Docs.
The databases documentation now aligns with the different system data storage architectures supported by the DataMiner platform. One of those is the upcoming Storage as a Service (STaaS), which will relieve you of the burden of maintaining the databases yourself. All the scaling and complexity will be handled for you. Once STaaS becomes available, we highly recommend this choice of setup, as it eliminates the hassle of having to manually configure your data storage setup.
As STaaS will be a true game-changer, we have dedicated an entire section of the databases documentation to it. Over time, this will expand as more and more information gets added by DataMiner experts.
Intrigued by this easy way to manage your data storage? Learn more about the perks of Storage as a Service in the run-up to the release.
In addition to STaaS, there are three main setup choices available to meet your specific requirements:
- Dedicated clustered storage, which includes a Cassandra-compatible database service and an indexing database. This is currently the recommended DataMiner setup.
- Storage per DMA, i.e. a separate Cassandra database for each DMA in a DMS, or a MySQL database in older DataMiner versions. Note that MySQL is considered deprecated as of DataMiner 10.3.
- An indexing database per DMS, which is required on top of storage per DMA to leverage the full strength of DataMiner. While you can use storage per DMA without indexing, you’ll be missing out on many great features. More on this below!
To help you find your way, the structure of the database configuration documentation now reflects these three main options. It also contains two additional sections with information that comes in handy no matter which storage setup you choose: common database settings, including e.g. TTL overrides, and optional database configuration, which includes the setup of an offload database.
Configuring dedicated clustered storage
To configure a dedicated clustered storage setup effectively, you’ll need both a Cassandra-compatible database service and an indexing database, also known as a Search Cluster. This configuration can be deployed on premises, in the cloud, or a combination of both.
In the dedicated clustered storage configuration section of the documentation, you can find instructions from start to finish on installing, configuring, and maintaining the Cassandra-compatible database service and the indexing database. Both are essential for completing the configuration of a dedicated clustered storage.
You are probably already familiar with the Cassandra Cluster setup, but starting from DataMiner 10.3.0/10.3.3, we also support Amazon Keyspaces Service on AWS.
To complete your setup with a Search Cluster, you can use an Elasticsearch database, but you can also opt for an OpenSearch database or use Amazon OpenSearch Service on AWS, both supported as from DataMiner 10.3.0/10.3.3.
Configuring storage per DMA
This second section of the database configuration documentation revolves around configuring storage per DMA. By default, when you install a new DataMiner System, a Cassandra database per DMA is configured. In legacy DataMiner Systems, typically a MySQL database is used as the general database. However, we highly recommend that you migrate to Cassandra if you are still using an SQL database.
Configuring a Cassandra database per DMA will give you access to additional DataMiner features. To unlock all available features, we recommend deploying an indexing database as well.
Configuring an indexing database per DMS
In this third section of the database configuration documentation, you can find all instructions and information needed to deploy, configure, and maintain the Elasticsearch indexing database. It is only when you deploy an indexing database in addition to your Cassandra database per DMA that you will have access to transformational features such as DOM, SRM, and GQI.
Has your curiosity been piqued? Learn how to unleash the power of data with the DataMiner Generic Query Interface!
Go take a look!
Now that you know where to find everything, it’s the perfect time for you to explore the revamped databases documentation.
Notice any missing information? We are constantly expanding and improving the documentation, and you can help us by leaving feedback in the form of a GitHub issue or proposing your changes with a pull request. You’ll earn some DevOps points in the bargain!