Using MongoDB to store proof of play and other time series data

From 2.1 the CMS can be configured to use MongoDB to store Proof of Play statistics and other time series data.

MongoDB is enabled via the settings.php file in the CMS installation. If Docker has been used settings.php will not be accessible, however, it is possible to create a settings-custom.php file in the /custom mount point. The below Configuration can be added to that file instead.

Configuration

Please ensure you have Xibo version 2.1.0 or later before enabling MongoDB. You will also need to have a working MongoDB instance with a user and database created.

Add a new variable called $timeSeriesStore to your settings file. The variable should be a function which returns a \Xibo\Storage\MongoDbTimeSeriesStore created with your MongoDB connection details.

$timeSeriesStore = function() {
    return new \Xibo\Storage\MongoDbTimeSeriesStore([
        'host' => 'mongo',
        'port' => '1234',
        'database' => 'db_name',
        'username' => 'user',
        'password' => 'password'
    ]);
};

Mongo Indexes

We recommend adding an index to the stat collection in your MongoDB database. To do this from the console, make sure you have your database selected and then:

db.stat.ensureIndex({ "start": -1, "end" : -1, "type": 1}, {background: true})

Migrating

Unless your CMS is a brand new installation you will likely have existing proof of play data which you want to move into MongoDB in a controlled fashion. Xibo provides a migration task to achieve this.

You can enable this task on the CMS Tasks page.

We have provided a set of default options for the task which you may want to adjust according to your environment. The default options intend to provide a slow and steady migration of your existing data.

The options available are:

  • killSwitch (0 or 1 to completely disable processing)
  • numberOfRecords (how many to process each time)
  • numberOfLoops (how many loops to do per task run)
  • pauseBetweenLoops (how long to wait between each loop)
  • optimiseOnComplete (issue an OPTIMIZE TABLE stat after truncating)
  • configOverride (an optional path to a JSON file containing overrides for all of the above settings)

If you already use the StatsArchiver task it will be disabled during migration to prevent conflicts.

Nothing will be deleted from the stat table in the MySQL database until the migration has completed.