Starting with the release of Strategy ONE (March 2024), dossiers are also known as dashboards.
Platform Analytics repository size may be observed increase rapidly with advanced statistics enabled.
There might be extreme cases when customer move the pgdata folder to a NAS drive and create a soft link, and then experience abnormal scenarios such as Platform Analytics Consumer is taking hours to startup or data intermittent not submitted into the Platform Analytics Warehouse access_transactions table.
Below are some tips to retain Platform Analytics repository at a reasonable size
- Frequently used OOTB purge data methodology.
- Delete fact or deleted items in batch.
Refer to Product Manual below:
https://www2.microstrategy.com/producthelp/Current/PlatformAnalytics/en-us/Content/purge_platform_analytics_wh.htm
- Delete data for specific users with platform-analytics-data-cleanup script.
You can delete data for specific users, across all tables in the Platform Analytics warehouse, by running the data cleanup script. Refer to Product Manual below:
https://www2.microstrategy.com/producthelp/Current/PlatformAnalytics/en-us/Content/delete_user_data.htm
- Vacuum with Database Administration Tool.
Whenever rows in a PostgreSQL table are updated or deleted, dead rows are left behind. Vacuum gets rid of them so that space can be reused. Refer to Product Manual below:
https://www2.microstrategy.com/producthelp/Current/InstallConfig/en-us/Content/repository_administration.htm
- Customer should allocate ~85 GB for Kafka logs, and .001 * (# of transactions / 1000) GB for transaction data in PA Warehouse for basic statistics.
If advanced statistics are enabled, allocate ~160 GB for Kafka logs and .005 * (# of transactions / 1000) GB for transaction data in PA Warehouse. An additional ~3 GB is needed to store lookup information for metadata objects. The storage requirements will scale with time and transaction volume, and how much historical data is kept in the warehouse.
Refer to below Knowledge Base Article for Storage Utilization suggestion for kafka logs.
Capacity Planning for Platform Analytics
- Refer to the OOTB Platform Analytics Project Dossier>Database Capacity Planning dossier, to get Database overview, Table overview include Row number, Table Size, Index Size, Transaction information such as Daily commits, Daily disk reads, and Trend Analysis.
- The index is observed take quite a lot of space, and access_transactions is heavily indexed because it's critical to the performance of joining and filtering all of the tables that relate through access_transaction (lu_object, lu_account, fact_action_cube_cache, etc.).
- It is not recommended to drop index as it may wind up in a situation where they are caused by the lack of indexes. Customer could consider dropping Usher-related indexes as a place to start in some urgent scenario to make room.
- In high-throughput environment customer might involve their DBA to tune some of the more advanced settings of their Postgres database regarding auto vacuum and analyze.
NOTE: Host pgdata to physical drive instead of a split network host such as NAS. There is a new feature to validate NAS storage with Platform Analytics in the long term. For the short term, there can certainly be performance implications/complexities added there without knowing how customer's NAS is configured.
