DeepSee: Databases, Namespaces, and Mappings - Part 4 of 5

The following post outlines a more flexible architectural design for DeepSee. As in the previous example, this implementation includes separate databases for storing the DeepSee cache, DeepSee implementation and settings, and synchronization globals. This example introduces one new databases to store the DeepSee indices. We will redefine the global mappings so that the DeepSee indices are not mapped together with the fact and dimension tables.

Example 3: Fully flexible architecture

Databases

In addition to the databases defined before in the intermediate example, the Analytics server introduces the APP-INDEX database storing the indices, whereas the APP-FACT database only storing the fact and dimension tables. The reason to split indices from fact tables is that indices can possibly be big in size, and the block size for APP-FACT can be changed to improve performance.

As in the previous example, enabling journaling for fact table and indices is optional. Please read the note in the previous post for a more extensive discussion.

Global Mappings

The following screenshot shows the mappings for the implementation example above. The mapping for the ^DeepSee.Index global has been changed to be stored in the newly created APP-INDEX database. As in the intermediate example the mappings for the ^DeepSee.Fact* and ^DeepSee.Dimension* globals are still used to stored fact and dimension tables to the APP-FACT database. The query log and the last MDX query are optionally stored together with the DeepSee cache.

Comments

This example of architecture is the most flexible but requires creating five databases per namespace. As in the second example the DeepSee cache is mapped to a dedicated database with journaling disabled, and the synchronization globals are mapped to APP-DSTIME.

Mapping fact tables and indices allows DeepSee implementation and settings to be stored in a dedicated journaled database (i.e. APP-DEEPSEE), which can be easily used to restore the DeepSee implementation. Creating a separate database for indices is optional since in many cases it is sufficient to store the corresponding globals together with the fact tables in APP-FACT.

The last post of this series will contain a summary and list of databases used in our three examples.