A smaller index is mostly a schema decision. Each of the levers below trades a little query capability for a lot of disk, and you choose which ones you can afford to give up.
01 · The levers, and what each one costs you
| Change | What you gain | What you give up |
|---|---|---|
Use int instead of tint | A plain integer field takes less space than a trie integer. | Range queries on that field get slower. |
| Drop stored fields you do not display | Stored content is often the largest part of an index. | You fetch those values from your own database after Solr returns the ids. |
omitNorms="true" on text fields | Removes the length normalization data. | Short and long documents stop being scored differently on that field. |
omitPositions="true" on text fields | Removes term positions. | No phrase matching on that field. |
| Use NGram fields sparingly | NGrams multiply the number of terms, and the disk with it. | Substring matching, which a normal text field usually covers well enough. |
| Remove stop words at index time | The, and, of and friends stop being indexed at all. | Exact phrases that depend on those words. |
02 · Audit before you tune
Go through your fields one by one
The question for each is simple: will I ever search, filter, facet or sort on this? If not, it does not need to be indexed, and often does not need to be stored.
Stored fields are the usual culprit
A field that only exists to be displayed can live in your own database. Solr returns the ids, you fetch the rest.
Every byte counts at scale
On a large index these decisions are the difference between fitting your plan and paying for the next one up.
Out of disk on a running index?
You can add disk to your plan at any time, pro-rated to the day, or send us the index name and we will tell you which fields are taking the space.