db_cachedb Module

Vladut-Stefan Paiu

   OpenSIPS Solutions

Edited by

Vladut-Stefan Paiu

   Copyright © 2013 www.opensips-solutions.com
     __________________________________________________________

   Table of Contents

   1. Admin Guide

        1.1. Overview

              1.1.1. The idea
              1.1.2. OpenSIPS Modules
              1.1.3. External Libraries or Applications

        1.2. Exported Parameters

              1.2.1. cachedb_url (str)

        1.3. Examples of Usage

              1.3.1. Distributed Subscriber Base

        1.4. Current Limitations

              1.4.1. CacheDB modules integration
              1.4.2. Extensive Testing Needed
              1.4.3. CacheDB Specific 'schema' and other
                      incompatibilities

   List of Examples

   1.1. Set cachedb_url parameter
   1.2. OpenSIPS CFG Snippet for using DB_CACHEDB

Chapter 1. Admin Guide

1.1. Overview

1.1. Overview

1.1.1.  The idea

   The db_cachedb module will expose the same front db api,
   however it will run on top of a NoSQL back-end, emulating the
   SQL calls to the back-end specific queries. Thus, any OpenSIPS
   module that would regularily need a regular SQL-based database,
   will now be able to run over a NoSQL back-end, allowing for a
   much easier distribution and integration of the currently
   existing OpenSIPS modules in a distributed environment.

1.1.2. OpenSIPS Modules

   The following modules must be loaded before this module:
     * At least one NoSQL cachedb_* module.

1.1.3. External Libraries or Applications

   The following libraries or applications must be installed
   before running OpenSIPS with this module loaded:
     * None.

1.2. Exported Parameters

1.2.1.  cachedb_url (str)

   The URL for the CacheDB back-end to be used. It can be set more
   than one time.

   Example 1.1. Set cachedb_url parameter
...
modparam("db_cachedb","cachedb_url","mongodb:mycluster://127.0.0.1:27017
/db.col")
...

1.3. Examples of Usage

1.3.1.  Distributed Subscriber Base

   In order to achieve such a setup, one would have to set the
   db_url parameter of the auth_db module to point to the
   DB_CACHEDB URL.

   Example 1.2. OpenSIPS CFG Snippet for using DB_CACHEDB
loadmodule "auth_db.so"
modparam("auth_db", "load_credentials", "$avp(user_rpid)=rpid")

loadmodule "db_cachedb.so"
loadmodule "cachedb_mongodb.so"
...
modparam("db_cachedb","cachedb_url","mongodb:mycluster://127.0.0.1:27017
/my_db.col")
modparam("auth_db","db_url","cachedb://mongodb:mycluster")
...

   With such a setup, the auth_db module will load the subscribers
   from the MongoDB cluster, in the 'my_db' database, in the
   'subscriber' collection.

   The same mechanism/setup can be used to run other modules (
   like usrloc, dialog, permissions, drouting, etc ) on top of a
   cachedb cluster.

1.4. Current Limitations

1.4.1.  CacheDB modules integration

   Currently the only cachedb_* module that implements this
   functionality is the cachedb_mongodb module, so currently you
   can only emulate SQL queries to a MongoDB instance/cluster.
   There are plans to also extend this functionality to other
   cachedb_* backends, like Cassandra and CouchBase.

1.4.2.  Extensive Testing Needed

   Since there are many OpenSIPS modules that currently use the DB
   interface, it wasn't feasible to test all scenarios with all
   modules, and there still might be some incompatibilities. The
   module was tested with some regularily used modules ( like
   usrloc, dialog, permissions, drouting ), but more testing is
   very much welcome, and feedback is appreciated.

1.4.3.  CacheDB Specific 'schema' and other incompatibilities

   Since the NoSQL backends do not usually have a strict schema
   involved, we do not provide scripts for creating such schemas,
   since the insertion ops will trigger the dinamically creation
   of the schema and info. Still, a specific data collection needs
   to be present, and that is the equivalent of the 'version'
   table from the SQL. Since most modules check the version table
   at the module setup, it's the user's responsability to setup
   such a 'version' collection in the respective NoSQL back-end.
   For example, for the MongoDB cluster, 'version' is a reserved
   keyword, so one would have to change the default version table
   that OpenSIPS uses ( via the 'db_version_table' global
   parameter ) and then manually insert the version number with
   something like db.my_version_table.insert({table_version :
   NumberInt(5), table_name : "address"})
