1. BDB Module
Sippy Software, Inc.
Copyright © 2006 Sippy Software, Inc.
__________________________________________________________________
1.1. Overview
1.1.1. Design of DBD Engine
1.2. Dependencies
1.2.1. External libraries or applications
1.3. Exported parameters
1.3.1. describe_table (string)
1.4. Constrains and limitations
1.5. Installation and running
1.5.1. Using BDB With Basic SER Configuration
1.1. Overview
The SER (SIP Express Router) supports several different persistent
storage backends (flatfile, dbtext and several SQL servers). However,
in certain cases those existing backends don't satisfy conditions.
Particularly, SQL server-based backends typically provide good
performance and scalability, but at the same time require considerable
efforts to configure and manage and also have significant memory and
on-disk footprint, while simpler storage backends (flatfile, dbtext)
are lighter and simpler to setup and manage, but scale poorly and don't
provide sufficient performance. For certain types of applications (i.e.
embedded SIP applications, SIP load balancing farms etc), different
solution that would combine some of the non-overlapping properties of
those two existing classes of backends is necessary.
Berkeley DB is widely regarded as industry-leading open source,
embeddable database engine that provides developers with fast,
reliable, local persistence with almost zero administration.
1.1.1. Design of DBD Engine
The dbtext database system architecture:
* A database is represented by a directory in the local file system
where BDB environment is located.
Note
When using BDB driver in SER, the database URL for modules must be
the path to the directory where the BDB environment is located,
prefixed by "bdb://", e.g., "bdb:///var/db/ser". If there is no "/"
after "bdb://" then "CFG_DIR/" (the OS-specific path defined at
SER's compile time) is inserted at the beginning of the database
path automatically. So that, either an absolute path to database
directory, or one relative to "CFG_DIR" directory should be
provided in the URL.
* The individual tables internaly are represented by binary files
inside environment directory.
Note
The BDB driver uses BTree access method.
On-disk storage format has been developed to be as simple as
possible, while meeting performance requirements set forth above.
It is not compatible with on-disk format of any other BDB-based DB
engine (e.g. MySQL's BDB table handler).
1.2. Dependencies
1.2.1. External libraries or applications
The next libraries or applications must be installed before running SER
with this module:
* Berkeley DB 4.X
1.3. Exported parameters
1.3.1. describe_table (string)
Define the table and its structure. Each table that will be used by
other modules has to be defined. The format of the parameter is:
table_name:column_name_1(column_type_1)[column_name_2(column_type_2)[..
. column_name_N(column_type_N)]]
The names of table and columns must not include white spaces.
The first column in definition is used as index.
Between name of table and name of first column must be ":".
Between two columns definitions must be exactly one white space.
Type of column has to be enclosed into parentheses.
Supported column types are:
* int
* float
* double
* string
* str
* datetime
* blob
* bitmap
1.4. Constrains and limitations
Use of indexes:
* Effective SELECT, UPDATE and DELETE operations on a structured
storage that contains any more or less decent number of records are
impossible without using some kind of indexing scheme. Since
Berkley DB is relatively simple storage engine it provides only
basic support for indexing, nearly not as rich as usually expected
by an average SQL user. Therefore, it has been decided to limit
number of indexes supported to one per table. This is sufficient
for most of the uses in the SER (for example: usrloc, auth_db etc).
* SELECT/UPDATE/DELETE records matching criteria. Due to its
simplicity, Berkley DB only supports exact match on indexed field.
In order to support <, >, <= and >= operations mandated by the SIP
DB API it is necessary to fall back to sequental scan of the index
values, which obviously has significant negative impact on
performance. Fortunately those advanced records matching criterias
are not required neither by the usrloc module nor by auth_db
module.
* BDB driver uses index only if key column appears in search clause
at least once and records matching operator associated with it is
'='.
* It is not allowed to set index value to NULL or an empty string.
* It is not allowed to update index value. The DELETE followed by
INSERT should be used instead.
BDB driver does not support db_raw_query() method.
BDB driver does not support ORDER BY clause of db_query() method.
1.5. Installation and running
Compile the module and load it instead of mysql or other DB modules.
Example 1. Load the bdb module
...
loadmodule "/path/to/ser/modules/dbb.so"
...
modparam("module_name", "db_url", "bdb:///path/to/bdb/database")
...
Example 2. definition of the standard version table
...
modparam("bdb", "describe_table", "version:table_name(str) table_version(int)")
...
1.5.1. Using BDB With Basic SER Configuration
Here are the definitions for tables used by usrloc module as well as a
part of basic configuration file to use BDB driver with SER. The table
structures may change in future releases, so that some adjustment to
example below may be necessary. That example corresponds to SER v0.9.4
According to the configuration file below, the table files will be
placed in the //var/db/ser/ directory.
The table version should be populated manually before the SER is
started. To do this version.dump file located in the directotry of BDB
driver sources and db_load utility from Berkeley BD distribution should
be used as follows:
Example 3. Population of version table
$ db_load -h /var/db/ser -f version.dump version
Example 4. Configuration file
# ---------- global configuration parameters ------------------------
# [skip]
# ---------- module loading -----------------------------------------
loadmodule "/usr/local/lib/ser/modules/usrloc.so"
loadmodule "/usr/local/lib/ser/modules/bdb.so"
# ---------- module-specific configuration parameteres --------------
modparam("usrloc", "db_mode", 2)
modparam("usrloc", "timer_interval", 3)
modparam("usrloc", "db_url", "bdb:///var/db/ser")
modparam("bdb", "describe_table", "version:table_name(str) table_version(int)")
modparam("bdb", "describe_table", "location:username(str) domain(str) contact(st
r) i_env(int) expires(datetime) q(double) callid(str) cseq(int) method(str) flag
s(int) user_agent(str) received(str)")
modparam("bdb", "describe_table", "aliases:username(str) domain(str) contact(str
) i_env(int) expires(datetime) q(double) callid(str) cseq(int) method(str) flags
(int) user_agent(str) received(str)")
# ---------- request routing logic ----------------------------------
# [skip]