CUDB maintains views to support flexible data organization. If an LDAP user has an LDAP view assigned to it, then it can access the data through that view. Each view has its LDAP schema loaded into the CUDB, where entries are composed by mapping attributes from the default view, resulting in the building of a custom DIT. Each view has a mapping file, which describes how the view entries are composed from the attributes contained by the default view.

The LDAP Data Views function allows access to the data in different data structures through the LDAP interface.

All the attributes that are reachable through views should be already defined in the default view.

Once a user with an assigned view establishes a new LDAP bind, all the following LDAP operations are performed against the LDAP view selected for this user. LDAP data views are not available for export and import procedures, or for notifications. Notifications must be configured according to core DIT distinguished names and attributes, and data in SOAP messages is, likewise, identified by its core DIT distinguished names and attributes. Users having no view assigned will see the PL and DS data through the default LDAP tree. For users that have a view set through configuration, the given LDAP schema of that view will apply.

For more information on LDAP views, refer to CUDB LDAP Data Views.

CUDB is exposed as an LDAP DIT to applications. CUDB provides a basic LDAP DIT to be extended by applications to store and query their data.

Normally, applications place their data under the predefined CUDB branches, but they can also create their own branches under the DIT root entry. For more details on the CUDB LDAP basic DIT, refer to CUDB LDAP Data Access and CUDB LDAP Interwork Description.

CUDB provides a typical LDAP core schema and a CUDB-specific LDAP schema with object classes and attributes that are used in the predefined entries that build the LDAP basic DIT. These attributes and the object classes can also be used by applications for their own entries.

Applications can also provide their own schema files that define specific object classes and attributes to be used by the applications data. Schemas containing object classes and attributes common to several applications are also supported, provided that object classes and attribute definitions are not repeated in different LDAP schemas.

CUDB provides tools that automatically and transparently perform a translation between LDAP schema elements and the internal database structures used by CUDB to support the LDAP schemas required. The schemas provided by applications must comply with some requirements to be usable by these tools. Refer to CUDB Application Schema Update for more details.

LDAP schemas are typically provided during CUDB system installation, but new LDAP schemas can also be included once the system is up and running. With certain limitations, CUDB also offers the option of updating existing LDAP schemas, once an application has been integrated in CUDB. For more details on schema update, refer to CUDB Application Schema Update.

For more information about LDAP schemas, refer to CUDB LDAP Data Access.

Identities are special types of entries in CUDB that are applied to locate subscribers using network identifiers (such as MSISDN, IMSI, and so on) by means of the LDAP alias mechanism. Refer to CUDB LDAP Interwork Description for more details about identities.

Identities must be defined at installation or schema update time. A container for each type of identity is created automatically under a CUDB specific branch at installation and schema update time under a CUDB-specific branch. As identities are normally shared by different applications, it is required that a common LDAP schema containing the attributes and object classes used by identities is provided for all applications. Refer to CUDB Application Schema Update for more details about identities definition.

For more information about identities, refer to CUDB LDAP Data Access.

CUDB contains two types of storage layers in which applications place their data: the Processing Layer Database (PLDB) and the Data Store Unit Groups (DSGs).

• The PLDB is an indexing database replicated in certain nodes of all CUDB sites for the data stored in the DSGs. It also stores the complete set of subscriber identities. The PLDB may as well be used to store certain data which does not have massive size (for example common subscriber profiles) and is not related to one specific subscriber.

  Note:

  The PLDB does not offer the level of scalability provided by the DSGs. Therefore, it is recommended to study carefully what is stored in the PLDB, so that its capacity is not exceeded in a specific deployment.

• The DSGs are partitions of the subscribers database. Each DSG holds the data for a group of subscribers. Subscribers are distributed at provisioning time in the DSGs available in the system. Depending on the level of redundancy of the system one or more replicas of each DSG, called Data Store (DS) Units are present in the CUDB system. Each DS is assigned to a CUDB node.

  Note:

  To retrieve the data for a specific subscriber, a hop may be needed from the CUDB node where the request arrived to the node that contains the DS master replica where the data are stored.

Data that require extra performance in retrieval and is not massive in size is a good candidate to store in the PLDB. This is because the application FEs always access to a node that hosts a PLDB replica, and therefore no hops to other CUDB nodes are required when accessing PLDB data.

CUDB determines automatically if a certain LDAP entry is stored in the PLDB or in DSGs based on the position the entry has in the LDAP DIT. For details on which LDAP branches are stored in the PLDB and which LDAP branches are stored in DSGs, refer to CUDB LDAP Interwork Description.

For more information on how data is distributed in CUDB, refer to CUDB LDAP Data Access.

As stated previously, CUDB provides tools that automatically and transparently perform a translation between LDAP schema elements and the internal database structures used by CUDB to support the LDAP schemas required. Refer to CUDB Application Schema Update for further details.

For optimizing the storage space, the following information is provided regarding the mapping performed by CUDB from LDAP types into internal database types:

• For each entry in the LDAP DIT (of type other than identity) CUDB holds a row in a master table that contains the Distinguished Name (DN) of the entry among other data. Therefore, the longer the DN, the more space is taken by the entry in the database.

• For each identity entry, CUDB holds a row in a table in the PLDB for each identity type holding the values for the identity attributes (but not the complete DN).

• For each object class defined in any schema file, CUDB uses one table that holds one row for each LDAP entry containing that object class. If none of the attributes of the object class has a value for the entry, no row is present in the object class table. Therefore, it is recommended, to optimize the space occupied by data, to group attributes used together by the application (when one of these attributes is present all of them in the object class are present) in the same object classes.

• Each object class table contains a key column for each row and one column for each single-attribute belonging to the object class. Multi-value attributes are stored in separate tables (one for each pair of object classes or attributes) and CUDB uses one row of these latter tables for each multi-value attribute value.

The mapping of LDAP attribute types into internal database types performed by CUDB tools is shown in Table 1.

CUDB offers the possibility of storing Binary Large Objects (BLOBs). Attributes of BLOB type are defined at installation time together with the storage support option, Random Access Memory (RAM) or the disk storage system, for them on a per LDAP attribute basis. Refer to CUDB Binary Large Object Attributes Management for more details on how BLOBs are configured.

The decision on whether a certain BLOB attribute is to be kept on the disk storage system or in RAM must take into consideration both performance and storage capacity requirements. BLOB attributes on the disk storage system have higher access time than BLOBs in memory, but leave more main memory available for other data to be stored.

In order to make full use of the optimization provided by search indexes, the following conditions must be fulfilled.

• Condition 1: The search must be subtree or one level.

• Condition 2: The search filter must contain at least one indexed attribute.

• Condition 3: The indexed attribute in the filter is inside an equalityMatch, greaterOrEqual, or lessOrEqual filter.

• Condition 4: The equalityMatch, greaterOrEqual, or lessOrEqual part of the filter is either by itself in the filter, or it is part of an outermost AND term.

Search subtree and onelevel operations with filters that do not fulfill all the conditions above can still benefit from some, although lower level, optimization if the filter contains at least one indexed attribute in it.

The following examples show a set of LDAP filters for LDAP subtree or onelevel search operations for a CUDB system in which attributes IMSI and IMSICHO are configured as indexed attributes.

'(IMSICHO=3333333)'

'(!(IMSICHO=999)'

'(|(IMSICHO=333)(IMSICHO=999) 

'(IMSI>=3333)'

'(&(IMSI>=3333)(IMSI<=4000))'

'(!(&(IMSI>=3333)(IMSI<=4000)))'

'(&(IMSI>=3333)(IMSICHO=4000))'

'(&(CSP=3)(IMSICHO=4000))'

'(|(CSP=3)(&(IMSICHO=4000)(IMSI=4000)))'

'(IMSI=333*)'

To configure Search Indexes, refer to CUDB System Administrator Guide.

Adding search indexes has an impact in the space taken by each LDAP entry in CUDB. For each search index a new column is added to the CUDB table that contains the DNs for each entry. If the entry has a value for the indexed attribute, the value is stored in this table and in the table that holds all the attributes of the entry. Attributes with value take double space if they are indexed. Depending on the type of the indexed attribute, a small overhead may be taken to hold the length, even if the entry does not have a value for the specific attribute.

CUDB subtree optimized searches are configured by YAML files on a per LDAP user basis. To configure subtree search optimization, refer to the Optimized Subtree Searches section of CUDB System Administrator Guide.