Differences

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

--- big_data_service:best_practice [2022/11/17 15:50] – [Sharding] 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.
-If you are concerned about the health of your elasticsearch instance - contact support@intelligentplant.com for guidance.
+===== 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.
+**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** \\
+Increase server RAM and allocating more to the Big Data process.
+**Scale Out** \\
+Introduce more elasticseach nodes on dedicated infrastructure.
+**Data Archiving** \\
+Either remove old data, or migrate old data to another App Store Connect instance dediated to archiving.
+**Data Consolidation** \\
+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.