Alessandro Marin · Apr 17, 2018 2m read

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


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.



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.



0 1 315 2


There is one other mapping that might be useful to add in this architecture: The ^DeepSee.Listing global can be mapped to the APP-CACHE database, as described here. A large amount of data can be written to ^DeepSee.Listing if listings or plugins are run on cells containing many facts, and this global does not need to be journaled - listing queries will be rerun every time the listing in question is viewed.