I set up a dashboard for the marketing team to track analytics using a pivot command. I have about 25 dashboards which have to search through massive amounts of data and the performance is poor. I'm trying to set up a summary index to index this data every hour to enhance search performance. When I enable a summary index I'm getting
This search cannot be accelerated. I'm assuming this is due to not having the
si on my transformation command. Can anyone help me with this? Below is my search
| pivot RTGSearchAnalytics Hits count(Hits) AS "Count of Hits" SPLITROW SEARCH_TERMS_OUT AS Terms SPLITCOL REGION FILTER SITE is rtgAdults FILTER IS_BOT is false FILTER UserLocation is External SORT 0 SEARCH_TERMS_OUT ROWSUMMARY 1 COLSUMMARY 1 NUMCOLS 0 SHOWOTHER 1 | sort 0 - ALL
Summary Indexing are 2 totally different things that don't necessarily overlap. Additionally, whereas
acceleration is relatively easy and either can or can't be done, configuring and exploiting a Summary Index is a multi-stage process and can be quite complicated, especially the first time. I am certain that you should not be attempting to enable Summary Index so that is really what your problem is. Read in detail about Summary Index and you will see that this is not the solution that you think you are attempting:
as for the answer here, I want to know why acceleration and summary indexing are different? I also met the same question. I want to learn more.
You need to read the documentation in the link that I posted in my answer. They are completely different solutions.
Let me go into more detail as to the difference.
Replaces this question:
Is there *possibly* a match for my data in this bucket?
With this question:
Is there definitely a match for my data in this bucket?
Astronomical increases in performance are possible (but, if you do it wrong, things can actually be slower).
Admin must manually preform backfill.
Drilldown to raw data no longer works (must do Advanced dashboard programming to force it to switch back to raw data).
Is somewhat fragile and requires reactive housekeeping (many things can cause SI data outages).
Is sensitive to TimeZone and the user who runs the "Populating Search".
Has a minor "every-hour" impact to Indexers and consumes a small amount of disk space but no license.
Speeds up searches by replacing huge amounts of raw data with much smaller amounts of aggregate ("summarized") data in the Summary Index.
Requires a Admin to reverse-engineer the desired end-usage of the data in order to construct an appropriate "Populating Search" to do this conversion.
Requires that all existing KO uses of the raw data be manually converted (e.g. saved searches, macros, dashboard panels) to pull data from the SI instead of raw data.