Beehive 3 – What’s new?
Beehive 3 released
Logo Beehive 3Beehive 3 offers various improvements for managing the Operational Data Store (ODS) in terms of performance, stability, maintenance and administration.
Fast Load cycle
The key to improved performance is an optimized and less restrictive load strategy. Therefor the way changed data takes into the final ODS stage has been redesigned. Outdated data can now be linked more efficiently to the valid time frame. The optimized load processing between the staging area (STG) and the final ODS stage (GDP) leads to an extensive improvement of performance within the linking of outdated records, particularly in case of high data volume that needs to be changed.
All processing areas influencing performance (keys, indexes, etc.) have been reduced to a minimum without negative impact on performance when querying the data. For stability and performance reasons, key tables, used to enable constraint checks, have been dropped from the load cycle and are not supported any more. Therefor detailed logging mechanisms describe the completeness of the current Beehive load cycle, giving information whether a load has finished successfully or not. If necessary, data constraint checks can be implemented manually by user exits after the load cycle has finished.
Maintenance
The Oracle partitioning option becomes now available in the ODS stage, making the ODS more flexible than before. The embedded use of partitioning assures high performance when processing large data volumes, high maintainability of the ODS stage and gives even faster access to actual and historized data. By range-partitioning of the ODS (by valid-to date), the GDP-tables become easy to maintain, independent from their volume. Admins become able to archive legacy data and separate it from the active ODS by splitting off partitions until a defined date.
Monitoring
The FLink Monitoring view offers new functionalities for maintenance and administration. Beehive 3 jobs can be started, stopped, aborted or restarted. Logs can be archived in order to clean up operational log tables from old load cycle entries. Failed tasks can be skipped in order to complete a Beehive 3 cycle, if tasks failed and are not necessarily to be loaded.
Querying data
An important factor when building the new Beehive Release 3 has been the preservation of the existing ODS structure to maintain the migration effort as low as possible. Certainly, minor changes do appear on optimal data request.
The partitioning of the ODS area demands a modification of indexing, so that existing requests have to be slightly changed to allow for the new subscription. Though, the reorganization of the requests also means a simplification of the queries on the ODS during request for validity periods, as well as a higher performance at data access.