Choosing Between Summary Indexing and Data Model Acceleration in Splunk

Decision and constraints

You need to reduce latency for a reporting search that runs repeatedly (e.g., a daily sales summary). The choice must fit within available indexer storage, keep maintenance overhead low, and work with your Splunk version.

Comparison of supported options

Feature	Summary Indexing	Data Model Acceleration
How it works	Stores pre‑aggregated results in a separate index via the collect command.	Builds .tsidx files on the indexer for fields defined in a data model.
Version support	All Splunk versions.	Available from Splunk 6.2+.
Setup effort	Requires a scheduled saved search that writes to the summary index.	Enabled in the Data Model manager; acceleration runs automatically.
Control over granularity	Full control – you decide what fields and time buckets to store.	Limited to the fields and hierarchies defined in the data model.
Storage impact	Duplicates data; adds to license usage if the summary index exceeds licensed volume.	Adds .tsidx files; usually smaller than a full summary index but still consumes indexer disk.

Trade‑offs

Summary Indexing gives you explicit control over aggregation granularity and retention, which can be useful when you need custom roll‑ups or long‑term trends. The downside is the extra ETL complexity: you must create and maintain a scheduled search, monitor for gaps, and manage license consumption caused by duplicated data.

Data Model Acceleration is simpler to enable – just tick the acceleration box in the Data Model manager – and it keeps a link to the raw data, so you can still drill down. However, acceleration only speeds up searches that use fields defined in the model, and the build process can consume noticeable CPU and I/O on the indexer, potentially affecting concurrent searches during peak loads.

Implementation steps

Summary Indexing example

1. In Splunk Web, go to Settings → Indexes → New Index. Create an index named summary_sales (or another name that fits your naming convention). Ensure you have the admin role or equivalent.
2. Create a saved search that computes the aggregation you want to accelerate. For example:

index=sales sourcetype=access_combined | stats count by _time span=1h, product_id, region

1. Edit the saved search, add the collect command to write results to the summary index:

| collect index=summary_sales addtime=true marker="summary_sales_"

1. Set the schedule to run nightly (or at whatever frequency matches your reporting needs).
2. Optionally enable Summary Indexing in the search properties to let Splunk handle back‑fill for missing periods.

Data Model Acceleration example

1. Ensure you have a data model that covers the fields you need (e.g., a sales_model with objects Sales containing product_id, region, price).
2. In Splunk Web, navigate to Settings → Data Models, locate your model, and click Edit.
3. In the Acceleration tab, toggle Enable Acceleration, choose a Summary Range (e.g., 1 month), and save.
4. Splunk will begin building .tsidx files on the indexers; monitor progress in the Data Model manager.

Validation and verification

Summary Indexing validation

1. Run the original search over a recent time range (e.g., last 24 hours) and note the Scan Count and Execution Time from the Job Inspector.
2. Run the equivalent search against the summary index:

index=summary_sales marker="summary_sales_" | stats count by _time span=1h, product_id, region

1. Compare the result counts; they should match (within any expected rounding).
2. Check the Job Inspector again – you should see a lower scan count and shorter execution time for the summary‑based search.

Data Model Acceleration validation

1. Open the Data Model manager (Settings → Data Models) and verify that the model shows an Accelerated status with a completion percentage.
2. Run a search that uses the accelerated model:

| datamodel sales_model Sales | stats count by product_id, region

1. Inspect the Job Inspector; the scan count should reflect use of the .tsidx summary data rather than scanning raw events.
2. On an indexer, you can verify the presence of acceleration data by checking the size of the tsidx files under $SPLUNK_HOME/var/lib/splunk/defaultdb/db/ for the relevant buckets (this is a diagnostic step, not a performance guarantee).

Limitations and practical checks

• Summary indexing increases license usage if the summary index exceeds your licensed daily volume. Monitor the summary_sales index size via the Indexing Volume dashboard and set alerts if growth deviates from expectations.
• Data model acceleration can add noticeable CPU load during the build phase, especially on busy indexers. Review the Search Activity: Instance view for spikes in mpush or msearch processes while acceleration is running, and consider limiting the summary range or scheduling builds during off‑peak hours.
• Both techniques require validation after any change to the underlying data (e.g., new sourcetype, altered field extraction). Re‑run the verification steps to confirm that accelerated results remain correct.