Differences

This shows you the differences between two versions of the page.

--- big_data_service:best_practice [2022/11/17 16:19] – su
+++ big_data_service:best_practice [2022/11/17 16:22] (current) – [What to do if you are approaching advised limits?] su
@@ Line 48: / Line 48: @@
 Exceeding these limits may lead to issues index corruption. For Alarm Analysis, this could manifest in the loss of monthly blocks of data.
-==== What to do if you are approaching advised limits? ====
+===== What to do if you are approaching advised limits? =====
+Most of the options below require specialist knowledge of elasticsearch. Consult with the Intelligent Plant team if unsure how to proceed.
-Most of the options below require specialist knowledge of elasticsearch. Consult Intelligent Plant if unsure of best strategy.
-**Data Source Configuration**
-Change data index settings that determine how data is stored. IP Historian exposes index type and sharding properties.
+**Data Source Configuration** \\
+Change data index settings that determine how data is stored. IP Historian exposes index type and sharding properties. \\
 NB. Modifying these settings on a live system is not advised.
+**Scale Up** \\
-**Scale Up**
 Increase server RAM and allocating more to the Big Data process.
-**Scale Out**
+**Scale Out** \\
 Introduce more elasticseach nodes on dedicated infrastructure.
-**Data Archiving**
+**Data Archiving** \\
 Either remove old data, or migrate old data to another App Store Connect instance dediated to archiving.
-**Data Consolidation**
+**Data Consolidation** \\
+Re-index smaller data nodes together. For instance, consolidate Alarm Analysis monthly indices into single (one shard) indices. \\
-Re-index smaller data nodes together. For instance, consolidate Alarm Analysis monthly indices into single (one shard) indices.
 NB. The new index would need alias names of all the indices replaced in order to support application function.