Engine Technology

The HBMP technology

Board version 9.x introduces a new database technology, named HBMP: Hybrid Bitwise Memory Patterns. This new database technology uses new internal algorithms for managing multidimensional data, which make a much larger utilisation of RAM. The new Board database engine maps at bit-level (Bitwise calculations) into Memory the multidimensional data compressed (Memory Patterns).

With its engine, the meta-data (entities definitions, cube definitions..), the entities and entity members and the addressing of the multidimensional space, are always kept on the server's RAM memory. This grants considerably higher performance but requires adequate sizing of the hardware running the Board Server. The RAM used by Board version 9.x is remarkably higher than for prior versions and it is now mandatory to run Board Server on a 64-bit edition of Microsoft Windows operating system.

 

HBMP is not just another in-memory database technology. It is conceived to maximise performance thanks to the benefits of the new in-memory computing techniques however it is designed to overcome the functional and practical limitations of other in-Memory solutions existing today on the market which are fundamentally scalability and support of write-back.

 

The new HBMP format also greatly improves data compression, particularly for cubes at daily level. After the conversion from dtbx to hbmp format, the size of the Board database can decrease of a factor ranging from 3 to 10 times.

 

The HBMP engine grants unmatched data scalability thanks to the Hybrid feature.

The Hybrid characteristic is an important capability that allows the Board database administrator to choose between

- loading all data fully in-Memory: the database data dictionary, the bitmaps and the cubes data.

- or load all in memory except the cube data: all the database data dictionary and the bitmaps are in memory, but leave the raw cube data (the bm3 files) to disk. This option reduces RAM requirements and grants very high scalability because the amount of RAM needed for a loading in memory a database will depend only on the size of the multidimensional space mapping and will not be proportional to the amount of measures or transactions loaded. Though this option can save a huge amount of memory and grants scalability as no other in-memory technique can, it affects performance only by 15% to 20% because most of the query processing is anyhow performed in-memory (all the computation of what data to fetch and where) and requires a disk access only at the very end of the process chain. Moreover the Hybrid mode still allows the administrator to selectively define per each single Board cube (or measure) if it should be managed fully in-memory or not therefore the cubes which are more frequently used can be configured fully in-memory for best performance while the lesser frequently used cubes can be left on disk and will be loaded only on demand.